Hacker News Reader

Comment by tobr | Hacker News Reader

As a life-long Mac user, I’ll have to ask. Why is it a “bad idea” to wake your computer by pressing one of the biggest keys on the keyboard?

View on HN

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.

I like to press the shift key because it has a high chance of not triggering anything.

I like to mash on Shift until the screen wakes. On some outlandish systems this enables Sticky Keys and locks Shift.

I always use modifier keys like shift and ctrl for this very reason. Way fewer ways too accidentally mess anything up.

Yep, hitting Left Ctrl with my pinky is what I do.

That's a design bug, not a user problem.

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.

what's wrong with using the 'Shift' key? That's my wake-up key.

And that one doesn't transmit any active characters that can cause problems.

in high school computer lab we'd lock our friends computer and hold down the 'enter' button to get their account locked for 3 minutes

windows 11 (havent tried any others since vista) needs you to release the 'enter' key before it will try no password again

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'.

The goal is to delay bad actors, though, and that doesn't really help with that.

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 was wrong. Still sleepy.

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.

I agree, my point was nonsense. I was still waking up.

> 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.

Reply on news.ycombinator.com