←back to thread

430 points tambourine_man | 2 comments | | HN request time: 0.001s | source
Show context
mr_mitm ◴[] No.41879391[source]
I'm glad someone is thinking about UX and ergonomics when it comes to passwords. Most people I interact with have by now realized that generating passwords is a good idea. But if you are already generating the password, please do not include special characters. I regularly use different keyboard layouts (sometimes it is not even clear which layout is active, like in the vSphere web console), and the fact that passwords are often not shown on the screen when typing them makes for terrible UX and causes frustration.

The usual advice about character classes is only for casual users who don't know what makes a secure password. Entropy is the deciding factor: Ten random lower case letters is much more secure than "Summer2024!", which satisfies most password rules and has more characters.

Personally I stick to lower case letters for things like my Netflix password or Wifi key, because typing with a TV remote can be a huge pain. To keep a similar entropy, just increase the length by one or two characters.

replies(10): >>41879469 #>>41879535 #>>41879556 #>>41879734 #>>41879735 #>>41880345 #>>41880499 #>>41881423 #>>41881471 #>>41883418 #
coldpie ◴[] No.41879556[source]
In the context of web authentication, does entropy even matter (beyond an extremely low threshold)? Are there any attacks that actually occur that are defeated by increasing entropy? AFAIK basically all the auth attacks we see today are from password re-use, and out-of-band authentication, neither of which password entropy has an effect on.

"Summer2024!" is perfectly fine, if you use it for exactly one service. Frankly, "1235" is probably fine. No one is out there brute-forcing passwords.

replies(6): >>41879633 #>>41879639 #>>41879642 #>>41879681 #>>41879821 #>>41880424 #
jusssi ◴[] No.41879639[source]
People are definitely running dictionaries against password hash leaks. Both examples look like they might be in a dictionary.
replies(1): >>41879652 #
coldpie ◴[] No.41879652[source]
So what?
replies(3): >>41879706 #>>41879737 #>>41879764 #
Plutoberth ◴[] No.41879764[source]
So the user remains at risk in the time between the leak and the time the company discovers it and resets all passwords, which could be months. It might not really be relevant for most sites and for most users, and you might argue that if the hash database is compromised you have other things to worry about, but it's a something to consider.
replies(1): >>41881448 #
1. butlike ◴[] No.41881448[source]
Why is it my responsibility to keep my data secure? You (the ~1+bil dollar company) should be responsible for that if my password is 65 characters of gibberish or `111`.

I just find it funny that my bank doesn't say to reset my bank website password if my identity gets stolen or there's fraudulent charges on my account. They go after the root of the problem.

replies(1): >>41882927 #
2. wholinator2 ◴[] No.41882927[source]
I'm not sure i know which side of the debate you're on but the analogy that comes to mind is if you put your watch on a shelf in Walmart, they're supposed to protect it for you? It's absolutely your responsibility to lock your doors at night even if the bank currently owns your home.

People are walking around trying car doors at night and people are throwing dictionaries and tables at log in forms. Would you blame the bank if someone guessed your password of 1234? How are they supposed to tell it isn't you?