There's this link that references USB-HID specifically at 750 characters per second. I can't find other references to USB HID rates, and the HID protocol is semi-flexible (i.e. it's really fucking hard to implement NKRO on HID, since HID keyboard protocol specifies 6KRO in boot mode; but you're free to implement an alternate HID protocol once your keyboard's out of boot mode).
Thanks for the hint to look at the USB-HIB standard (1.1) in which even high-speed devices are limited to 64KB/s. That's interesting info. Does the USB hardware + operating system on most computers actually enforce that?
OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole
1-2 second delay is an expected human-facing turn-around: this actually happens on most modern systems. I pointed it out and then theorized eliminating that rate limit entirely, instead relying on the limits of the HID keyboard protocol at 750 characters per second, which is the faster measurement and thus can be taken as a worst case.
You don't actually seem to be addressing my argument here, perhaps you misunderstood? It's clear to me what you did, my argument was that doing what you did made no sense given the "1-2 second delay" you state, and given that datum, your characterizing Windows as "retarded" for not distinguishing between 750 char/s and the much faster network, was illogical.
Your naivety about the average entropy in a typical 8 character password is striking.
We're talking about theoretical password complexity here, not dictionary attacks.
Yes, I am capable of reverse engineering your math. You err, though. "We're talking about..."? No, you're talking about...
I'm not quite getting this. You dismiss the possibility that weak passwords are used, so that hardware password attacks are dismissable, but at the same time address the problem that these same non-weak passwords aren't strong enough to withstand network password attacks without lock-outs? Yes, I suppose there is some real-life situations in which that's true, but why would you rag on Microsoft for trying (in what I agree is not a reasonable way) to cover other possible situations (and, given their user base, much more probable ones)?