Live data from Hacker News

Myths of Password Security

stormpath.com

31–40 of 52 posts

Re: Myths of Password Security

#31

Earlier quoted context omitted.

I think you're missing the point, which is that that information is already unavoidably leaked by the signup form. So leaking it from the log in form doesn't change anything.

Yep, the only way to really leak no information is to just always say that the action (sign up, forgot password) was sucessful, which is awful from a ux perspective. Don't forget to go through the motions of registration/recovery to stave off timing attacks as well.

I have actually worked on systems where the signup form allowed multiple users to have the same user name, and the log in process consisted of checking for the existence of a (username,password) pair. Needless to say, I regarded this as a major design flaw and fixed it (except for the existing non-unique users). But there is, for all the reasons it shouldn't be done, a situation where the signup form doesn't leak usernames.

Re: Myths of Password Security

#32

Earlier quoted context omitted.

I humbly disagree, if you say to the user that the username was correct but the password was wrong then you have leaked information to the user that they should not have access to. i.e. If email is used as a username and I go to a porn site and type in my wifes email address and a random email and it comes back 'username right, password wrong' then I now know she has an account there which she was trying to kepp secr…

I think you're missing the point, which is that that information is already unavoidably leaked by the signup form. So leaking it from the log in form doesn't change anything.

That's a very binary way of looking at it. Depending on the sign up flow, it may be much more difficult to discover the existence of a username or not, than it is in the login form. (For instance, if the signup flow involves payment details before the username step.)

Re: Myths of Password Security

#33
post #15
post #5

>Simply put, adding length increases entropy more efficiently than replacing letters with symbols. I don't like this meme. Because it's not necessarily "more efficient." Like most things, it depends. If I have a password made of 10 lowercase characters, it's much better to replace with an upper case character rather than add another lower case one. Option 1) Add a lower case character. Password is 26 times stronger.…

But don't do what someone I know did and replace every single e with 3, every single a with 4, every single o with 0. Identical entropy, extra theatre.

I don't think that's identical entropy, since the usage of that strategy varies, and the non-substitution case is more common. But it probably adds less than one bit, and last I checked, 2 * instant = instant.

Re: Myths of Password Security

#34
post #30

Complexity Trumps Length Question for the smarter people out there. If everyone started using passwords like "donkey computer watch" would this mean that this format would then be much easier to crack as opposed to xy7*hdkSD Security is a bit of game theory right?

It actually wouldn't, because the entropy doesn't rely on the attacker not knowing the general format - it relies on the number of words available as choices.

Re: Myths of Password Security

#35
post #15

Earlier quoted context omitted.

But don't do what someone I know did and replace every single e with 3, every single a with 4, every single o with 0. Identical entropy, extra theatre.

Not to imply that what you describe is a great strategy, but I wouldn't describe it as pointless. The password "12345" has the same entropy as "b0g4p" but it would be a mistake to think they are equally secure.

Is bogap a dictionary word?

What I'm describing are passwords like

T1g3rF33t Cam3lT03

etc.

All dictionary stuff along a theme, but made "secure" by applying a zero-entropy substitution of all occurrences of (L,O,A,E) with (1,0,4,3).

Given that crackers know people do this, they add them to their dictionary attack routines so this is no more secure.

Given I'm still fighting with them over, "don't store passwords plain text" I've not even begun to attack them over this practice yet.

Re: Myths of Password Security

#36
post #32

Earlier quoted context omitted.

I think you're missing the point, which is that that information is already unavoidably leaked by the signup form. So leaking it from the log in form doesn't change anything.

That's a very binary way of looking at it. Depending on the sign up flow, it may be much more difficult to discover the existence of a username or not, than it is in the login form. (For instance, if the signup flow involves payment details before the username step.)

Are you going to enforce uniqueness of payment details? And if so, what part of those details must be unique? Will you require a unique credit card number?

If so, you will have to maintain either a bloom filter or a list of hashes for all eternity to ensure that nobody signs up twice with the same CC number. [Edit: actually, you could keep the scrambled CC data for a finite length of time if you're just trying to rate-limit, but still see below]

So suppose you've done all that. Are you going to do a test charge to see if the credit card number is valid before allowing the user to choose a username? If you don't, your efforts are wasted, since anyone can just use a CC generator (they're used for testing) to sign up for new accounts all day. If you do, you've probably driven away 99% of your users with your ridiculous signup process.

Re: Myths of Password Security

#37
With advice like this seemingly contradicting other seemingly sound advice and the debate taking place here at HN it's no wonder regular people (and geeks) have trouble deciding what is and isn't a secure password.

Re: Myths of Password Security

#38
post #34
post #30

Complexity Trumps Length Question for the smarter people out there. If everyone started using passwords like "donkey computer watch" would this mean that this format would then be much easier to crack as opposed to xy7*hdkSD Security is a bit of game theory right?

It actually wouldn't, because the entropy doesn't rely on the attacker not knowing the general format - it relies on the number of words available as choices.

English has roughly 100,000 words, so that password scheme has 10^15 combinations. Suppose the latter scheme incorporates the 96 printable Ascii characters. log96(10^15) is 7.5, so yes the latter scheme gets ahead on entropy at 8 characters or longer.

But it's not a question of maximizing entropy. It's a question of maximizing entropy relative to the human brain's ability to remember it. The brain handles words as single units, so it's a lot easier to remember three of them than eight or more arbitrary characters.

Re: Myths of Password Security

#39
post #13

Saying that using random words is better than using a string of unrelated characters assumes that password crackers don't know how to combine words. There are about 180000 words in English (but don't assume everybody knows 180000 words). That means that for three words, you have at most 5.8 10^15 options. For a password with mixed case and numbers, you have 62 different characters. With, 9 characters, you have 1.3 10…

How about mixing languages in the words chosen. English, French, Italian, Spanish, German, etc. Are they using multi-language dictionaries? Also, are they looking for typos? Voluntarily misspelling words would not make it harder to remember yet it might be harder to figure out.

Re: Myths of Password Security

#40
post #34
post #30

Complexity Trumps Length Question for the smarter people out there. If everyone started using passwords like "donkey computer watch" would this mean that this format would then be much easier to crack as opposed to xy7*hdkSD Security is a bit of game theory right?

It actually wouldn't, because the entropy doesn't rely on the attacker not knowing the general format - it relies on the number of words available as choices.

Doesn't the entropy just measure the difficulty of brute forcing a password though? From an entropy perspective, "password" may be more secure than "r&E2pX@", but I doubt anyone attempting to crack passwords in a practical manner is going to adopt a direct brute force approach.
Post reply on HN