Most active commenters
  • coldpie(4)

←back to thread

430 points tambourine_man | 14 comments | | HN request time: 0.002s | source | bottom
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 #
1. 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 #
2. coldpie ◴[] No.41879652[source]
So what?
replies(3): >>41879706 #>>41879737 #>>41879764 #
3. fkyoureadthedoc ◴[] No.41879706[source]
You ask a yes/no question, someone says "yes", you say "so what?". You should have just started there. "So what if someone gets my email and password for whatever website?"

So in your very specific contrived scenario that a user is using weak passwords but never reusing them, yes they are fine provided the site with the leaked account data realizes this and makes you reset your password.

But we already know that in reality most people reuse weak passwords. If your reused password was a passphrase that wasn't in the dictionary and couldn't be brute forced in a reasonable time, then you would be fine.

replies(1): >>41879792 #
4. jusssi ◴[] No.41879737[source]
So the service you used this password at gets its password hashes leaked. Your account is one of the (admittedly many) low-hanging fruits that gets used for whatever else someone might be using it for.

I suppose, if it's some random forum, they could just post some bot spam with your account and get you banned, no big deal. You'll live.

replies(1): >>41879755 #
5. coldpie ◴[] No.41879755{3}[source]
Ah! That's a good point. I had been considering a hash leak to be equivalent to a plaintext password leak, where you're screwed no matter the entropy. But I guess you have a fair point: a high entropy password could prevent your password from being cracked even under that scenario. So you could have a point here.

We could explore that further: are there any recent examples of this happening? is cracking password hashes still hard, given modern GPU hardware techniques? This could help us establish what "low" actually means when I say "low threshold."

replies(2): >>41880032 #>>41881149 #
6. 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 #
7. coldpie ◴[] No.41879792{3}[source]
My point with this thread is that if you're focusing on entropy, you're wasting your time. It doesn't matter beyond some threshold, which I argue is quite low. It doesn't matter if it takes 500 years or 5000 years to crack your password, no one's doing it so long as it's beyond (say) 3 months of CPU time.

It would be better to focus on easy and unique, than to focus on entropy.

replies(3): >>41879943 #>>41880086 #>>41889086 #
8. fkyoureadthedoc ◴[] No.41879943{4}[source]
Yes I agree that the passwords should be unique, easy to type manually when you have the need, and some minimum threshold of entropy is nice to have.

I have no idea what that minimum should be though. Aren't passwords cracked with GPU? I admittedly have no clue about this, but it sounds right to me lol. Assuming they are, a 4090 can probably guess a hell of a lot of passwords per second. I've had the same generated strong Reddit password for like 15 years, what are GPUs going to look like in the next 15?

The last time I had to implement password login for something we just followed NIST guidelines and called it a day.

9. freedomben ◴[] No.41880032{4}[source]
Yes it still happens pretty regularly, but in recent years people have gotten a lot better at using libs, so passwords are salted and hashed with a slow algorithm which substantially increases the difficulty of hashed attacks by makign it computationally expensive to hash every password. These days it's not uncommon for it to take months or years to crack 50% of the passwords in a dump. If your password has sufficient entropy, it may never be cracked. Modern GPUs can parallelize across their numerous cores, but statistically a brute force isn't going to work. Hybrid dictionary attacks are where it's at, and if your password is random (pseudo-random) then a dict attack won't work.

Modern password hashing is very good.

10. freedomben ◴[] No.41880086{4}[source]
It depends on what "easy" means to you, but assuming some minimum level of "easy" I would agree. I typically encourage people to think in pass phrases instead of pass words, like the xkcd[1] except throw some personal variances in there. A substituted misspelling, a fake word, intersperse some meaningful numbers, (basically anything to make the standard dictionary attack algorithms fail at generating your password).

[1]: https://xkcd.com/936/

11. umanwizard ◴[] No.41881149{4}[source]
> is cracking password hashes still hard, given modern GPU hardware techniques

Yes, if the entropy is high enough. What else would be the point of salting and hashing passwords?

There's no known way to reverse major hash algorithms like SHA-256 or bcrypt; you have to try all the combinations. So you have to do exponential work in the amount of entropy whereas GPUs only give a constant factor speedup over CPUs.

If this ever changes (e.g., someone breaks SHA-256 or bcrypt) you will definitely see it as the #1 story on HN (and probably pretty prominently in mainstream media too).

12. butlike ◴[] No.41881448{3}[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 #
13. wholinator2 ◴[] No.41882927{4}[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?

14. joshka ◴[] No.41889086{4}[source]
The measure of uniqueness is effectively entropy (entropy = log base 2 of the number of possible passwords). Ease of use is just unnecessary (for entropy purposes) padding on top of that (constraints on symbol sets, order, etc). The necessary threshold is entirely dependent on your threat model, combined with the risks that your use cases are exposed to when using the password.

Your point that using entropy rich passwords is foolish, is incorrect most of the time, and even if it weren't people's general understanding of where specifically to draw that line is generally significantly underestimated as a collective. The evidence of this is the amount of data breach information available, and the actual attacks which are available using this information.

Service breaches happen where the password database is insufficiently secured, and that often correlates strongly with insufficient protection of the password hashes. This means that low entropy passwords can be cracked and used for a period of time before the data breach is discovered. Entropy (and MFA) are the only protections against that.

56 DES was cracked in a day in 1999. Your passwords should definitely have more entropy than that. Probably around 80 bits is enough (about 16 alphanumeric characters or so). Your much lower threshold on entropy is insufficient for pretty much any reasonable threat model except public access.