If the lock screen is set up to remember your username, the cursor defaults to the password text box.
While one press of the enter key will wake the computer, its pretty easy to inadvertently double click it, and submit a login attempt with an empty password.
E: I like to use the even bigger key on my keyboard and just slap the spacebar as I sit down.
Why are zero-length passwords treated as login attempts for a user with a non-zero password? Why are a cluster of login attempts permitted in such quick succession? There's so many obvious fixes here for what is apparently a common issue.
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'.
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.
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?
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.
> 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.
We're absolutely stumped on this one user who gets locked out almost every day. We've tried a bunch of stuff, including many of the solutions offered in the thread above.
Almost every day, around 11.30, she presses Win + L to lock her screen and then goes to lunch. When she comes back her account is locked, and she has to wait up to 15min before she can log in again.
We've tried...
Checking for network drives with old credentials. There are none.
Removing all credentials in the credentials manager. No help.
Giving her a new computer and wiping the old one to completely eliminate any traces of old credentials. No help.
Wiping her work phone and setting it up again from scratch, also to eliminate any old credentials. No help.
After every one of the above steps, she would get locked out again the next day.
I've checked event logs and also sent them to our second line support, but they can't see anything out of the ordinary.
She has no other devices. When I look her up, only one laptop and one iPhone come up.
Also, she did admit to using Enter to wake her screen, so we explained why that's a bad idea. She now uses the arrow keys to wake her computer. Still gets locked out.
Please help me, I'm losing my mind.
EDIT
Wow, this got way more attention than I expected. Thank you very much. I'm at home right now. I'll through all your suggestions at work tomorrow.
Some clarifications:
She has a work phone. There are no personal devices on the work wifi.
I'm only a first line supporter. I don't have access to AD and I unfortunately don't know what many of your suggestions mean, such as PDC emulator or SSRS. Our second line people are very cool, though. I'll write a short list of your suggestions and send it to them.
28 comments
[ 336 ms ] story [ 989 ms ] threadWhile one press of the enter key will wake the computer, its pretty easy to inadvertently double click it, and submit a login attempt with an empty password.
E: I like to use the even bigger key on my keyboard and just slap the spacebar as I sit down.
Why are zero-length passwords treated as login attempts for a user with a non-zero password? Why are a cluster of login attempts permitted in such quick succession? There's so many obvious fixes here for what is apparently a common issue.
And that one doesn't transmit any active characters that can cause problems.
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.
All that logic sounds like a recipe for introducing a side channel attack into the system. Much better to keep things simple.
windows 11 (havent tried any others since vista) needs you to release the 'enter' key before it will try no password again
See this post: AD User Constantly Being Locked ( https://www.reddit.com/r/sysadmin/comments/1cb45bi/ad_user_c... )
We're absolutely stumped on this one user who gets locked out almost every day. We've tried a bunch of stuff, including many of the solutions offered in the thread above.
Almost every day, around 11.30, she presses Win + L to lock her screen and then goes to lunch. When she comes back her account is locked, and she has to wait up to 15min before she can log in again.
We've tried...
Checking for network drives with old credentials. There are none.
Removing all credentials in the credentials manager. No help.
Giving her a new computer and wiping the old one to completely eliminate any traces of old credentials. No help.
Wiping her work phone and setting it up again from scratch, also to eliminate any old credentials. No help.
After every one of the above steps, she would get locked out again the next day.
I've checked event logs and also sent them to our second line support, but they can't see anything out of the ordinary.
She has no other devices. When I look her up, only one laptop and one iPhone come up.
Also, she did admit to using Enter to wake her screen, so we explained why that's a bad idea. She now uses the arrow keys to wake her computer. Still gets locked out.
Please help me, I'm losing my mind.
EDIT
Wow, this got way more attention than I expected. Thank you very much. I'm at home right now. I'll through all your suggestions at work tomorrow.
Some clarifications:
She has a work phone. There are no personal devices on the work wifi.
I'm only a first line supporter. I don't have access to AD and I unfortunately don't know what many of your suggestions mean, such as PDC emulator or SSRS. Our second line people are very cool, though. I'll write a short list of your suggestions and send it to them.