Pressing enter will submit the current written password in the prompt. If the user is using that to wake the screen, probably the password field is empty so you're submiting a wrong password which might lock your account for a while if you have several failed attempts already
Windows should be smart enough to know an empty password doesn't meet the password complexity requirements or is of length zero and not count it against the 'bad password count'.
> Windows should be smart enough to know an empty password doesn't meet the password complexity requirements or is of length zero and not count it against the 'bad password count'.
All that logic sounds like a recipe for introducing a side channel attack into the system. Much better to keep things simple.
What kind of side channel exists if the behavior is: if password is required, zero length input is always invalid. This seems kind of like basic UX. I mean I wouldn't expect the password field to validate against the password complexity requirements exactly, just that zero length input is probably a mistake.
Windows has managed to maintain an amazing amount of backwards compatibility. Sometimes that means decisions that seem odd at surface level. I would not be surprised if there is some corner case where changing the current behavior means something else breaks.
If anything, I would guess it's some silly outdated but codified ISO standard that propagated far and wide and entered contractual obligations, like passwords needing to be changed every 3 months.
how so? The form shouldn't even submit an empty password, and just guessing the same password over and over again is not exactly going to resuilt in success on the 1 millionth attempt.
> The form shouldn't even submit an empty password,
But it does. And if you have someone malicious trying to access the machine that way, why not lock them out on the first attempt?
I can see the advantage in simplifying things by not submitting blank passwords also, although I also think it isn't necessary.
> not exactly going to resuilt in success on the 1 millionth attempt.
Not, but 2 or 3 attempts should lock the account. I don't see an issue in treating a blank password submission as an attempt, but I guess denying that is easier than trying to educate users.
I don't see how it makes any sense as a behaviour other than not having thought to special case it: it's a signal which is blindingly more likely to be an error than an attack, and has no chance of success as an attack. It makes perfect sense as an affordance, even with user education.
This example makes no sense to me. An attacker is potentially logging on to the computer and submitting empty passwords to get in. And this is what we're trying to prevent at the expense of having an unclear UX?
You still have lots of restaurants that don't accept cards, mainly outside cities. They say it's due to the cost of renting the card reader & the transaction costs but I think it's so it's easier to not declare the earnings.
It might be the case, but "lots" is an overstatement in my opinion. I was able to pay with card even in the most remote locations within the country. The restaurants that don't accept it are usually the exception and that argument of taxes over transactions is mostly bullshit for them to be able to escape proper taxation. A customer who pays with money and doesn't ask for receipt is all profit for dishonest owners.
Usually bright headlights / highbeams are useful in there.