Live data from Hacker News

Bad Password Policies

davidpashley.com

41–45 of 45 posts

Re: Bad Password Policies

#41
post #21

See also: http://plaintextoffenders.com

And the very first complaint is about a site sending you a password after registration, which is safe unless your email is compromised (in which case you're screwed anyway).

Re: Bad Password Policies

#42
post #41
post #21

See also: http://plaintextoffenders.com

And the very first complaint is about a site sending you a password after registration, which is safe unless your email is compromised (in which case you're screwed anyway).

and it has a disclaimer to that effect;

> On the plus side, they don’t send you your plaintext password if you click on the forgot password link, so maybe they don’t store it in plaintext.

Re: Bad Password Policies

#43
What's a reasonable minimum max password length? I've always fallen back on the Wikipedia Password strength article [0], for the NIST recommendation that 80 bits is sufficient entropy. I imagine that attack vectors other than password strength are for the most part going to be the killer issue. (heartbleed, MITM attacks, rubber hose, tempest, etc...)

Assuming that we're talking about purely randomly generated passwords, the entropy of passwords generated to fit in at least a few of the cases in the the original article should be fine. The UX factors are annoying however. This is an area where consistency would assist conformance.

[0] https://en.wikipedia.org/wiki/Password_strength#Bit_strength...

Re: Bad Password Policies

#44

Earlier quoted context omitted.

IIRC Facebook creates three passwords to deal with character case issues; the one you enter, an inverted case version and a version with the first characters case inverted.

I'd be very surprised if they created all 3. They probably check the other 2 variations if the first one fails though: if (entered == password || entered.swapcase() == password) .. // etc

In order to be performant, since the check is not against your actual password but just against a stored hash (salted/bcyrpted/etc), I wouldn't be surprised if they simply stored all 3 hash results.

Re: Bad Password Policies

#45
It seems to me the more secure you want your data, the more arcane (and less secure) the password rules are. I recently got in an argument with the bank, that doesn't allow special characters "These rules are here for your protection" Then why are you limiting the input space. "It is for your protection, so it is more secure." Rules like these, (limited length, limited set, etc) scream to me incompetence. And I wonder what else is broken.
Post reply on HN