Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password Requirements: Myths and Madness

franzoni.eu

Post reply on HN
Print view View original

41–50 of 257 posts

Re: Password Requirements: Myths and Madness

#41

Post by halostatue »

cirrus3 wrote: post #33
joezydeco wrote: post #11

My favorite is this transaction: I forgot my password. Can you send me a link? Sure, here you go. Pick a new password. Okay, CorrectHorseBatteryStaple. Sorry, you can't use an old password

Old password detection isn't necessarily a sign of weak security, if they are doing it right, they are just comparing a hash of the new password to saved previous password hashes. It is probably debatable if it is better security to not save old passwords hashes at all to perform this check, or to let users re-use old passwords that may have been disabled since they are known to have been cracked.

It can also be done securely if you have a flag that, when a password reset link is redeemed, the password must be reset in order to log in. There’s a couple of steps needed to make that happen cleanly (such modification should not be done on the GET of the password reset, but on a POST after the password reset link, prior to testing the passwords against old passwords and other security mechanisms).

Re: Password Requirements: Myths and Madness

#42

Post by kccqzy »

galangalalgol wrote: post #3

For judging complexity I always thought large businesses should just set aside some compute to try to brute force passwords with the hash. If they get yours, you have to change it and get a talking to. If they can't get it, they give you $X where X is big enough to be a pleasant surprise.

Idea: just run a standard compression algorithm on the password and measure its length.

Re: Password Requirements: Myths and Madness

#45

Post by ar_turnbull »

joezydeco wrote: post #11

My favorite is this transaction: I forgot my password. Can you send me a link? Sure, here you go. Pick a new password. Okay, CorrectHorseBatteryStaple. Sorry, you can't use an old password

would be a nicer UX if instead of "sorry" it was "great, your password hasn't changed as this was your old password. ps. you're now logged in, go do whatever you were hoping to do you rascal!"

Re: Password Requirements: Myths and Madness

#46

Post by MaxGabriel »

_dan wrote: post #32

In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…

You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.

Re: Password Requirements: Myths and Madness

#47

Post by cirrus3 »

halostatue wrote: post #41
cirrus3 wrote: post #33

Earlier quoted context omitted.

Old password detection isn't necessarily a sign of weak security, if they are doing it right, they are just comparing a hash of the new password to saved previous password hashes. It is probably debatable if it is better security to not save old passwords hashes at all to perform this check, or to let users re-use old passwords that may have been disabled since they are known to have been cracked.

It can also be done securely if you have a flag that, when a password reset link is redeemed , the password must be reset in order to log in. There’s a couple of steps needed to make that happen cleanly (such modification should not be done on the GET of the password reset, but on a POST after the password reset link, prior to testing the passwords against old passwords and other security mechanisms).

yep, all true... this is a solved problem on how to do it right. The fact that the OP finds this interaction funny leads me to believe they don't understand how it can be done correctly, which is scary.

Re: Password Requirements: Myths and Madness

#48

Post by BlueTemplar »

MaxGabriel wrote: post #46
_dan wrote: post #32

In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…

You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.

I have had trouble convincing people before, would you happen to have a link ?

Re: Password Requirements: Myths and Madness

#49

Post by lolinder »

alwayslikethis wrote: post #29
lucb1e wrote: post #13

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong". > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. Security through obscurity. This is safe until everyone does it. It's not a strong passw…

> > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. > Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use…

Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at the password.

The only good solution I can think of is to assume low bits per character and require a minimum password length.

Re: Password Requirements: Myths and Madness

#50

Post by lucb1e »

the_af wrote: post #30
lucb1e wrote: post #13

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong". > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. Security through obscurity. This is safe until everyone does it. It's not a strong passw…

The author's point is not that you should use a short unicode password, but that the key thing to focus on is password strength , not length . That is, use a lib that enforces password strength -- he is arguing -- instead of focusing on arbitrary and possibly wrong constraints such as "password too short". Strength is going to take care of it if it really is too short, anyway. The author is also aware that we've know…

So what's the proposal, switching to requiring a different length when a unicode character is present? How do you know from what set of possible values (like thousands of possible unicode chars versus a-z) the user chose each character?

While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally with symbols) and call it a day; users aren't going to be able to input a unicode snowman with combination marker with orange skin on every keyboard without using the clipboard or other software. It's not more secure, it's just asking for trouble. A software tester can do this, but there is no practical reason to lower the length requirement to 4 characters because an ẍ might be entered.

The author doesn't end up proposing such a thing, but the argument in this paragraph still doesn't sound practical to me.

Post reply on HN