Hacker News Reader

Comment by gkoberger | Hacker News Reader

There were one million passwords released, and only about 3,000 use '123456'. That's only a 0.3% chance.

Yes, you could have a bot that checked the top 50 passwords against a few thousand or so accounts- but even then, you'd only get one or two matches at most.

What if sites blocked passwords that have been used more than twice already? So, at most, there would be two "123456" passwords- any secure password is more than likely something that no more than one other person on any given site would be using.

[Edited: Whoops, did the math too quickly]

View on HN

There were one million passwords released, and only about 3,000 use '123456'. That's only a 0.003% chance.

Actually, 3000/1000000 = .003, so a .3% chance.

> What if sites blocked passwords that have been used more than twice already?

"I'm sorry, another user on this system is already using the password you have submitted. Please choose a different one."

That's not the sort of information you want to be leaking.

"Your password is too weak"

Yes, this would suffice. But I think it points out that a duplicate password is just a proxy for a weak password: strong passwords tend to be locally unique.

If you are going to have a strength requirement, then run your strength validation routine and deny weak passwords. That a password is duplicated seems like a special case of weakness that is not worth checking for.

i.e. You probably don't want special checks for 'password' or '123456' either, since your strength validation routine should catch these.

Mot to mention storing the passwords in plaintext (or unsalted) to be able to query them.

I think good practices around encryption/storage of passwords would make it infeasible to check how many times a password is already in your database.

How about instead just implementing a blacklist of unacceptable passwords?

Wouldn't you just need to hash the password and do a lookup on the table to see how many results were returned?

If you are generating a per-password salt, that won't work. In order to find prior occurrences of a given password, you would have to hash the password for every salt value that you've ever used. And since you're using BCrypt[1], that will be very slow.

[1] http://codahale.com/how-to-safely-store-a-password/

How long would you spend in the "another user has this password, please try a different one" loop before getting fed up and leaving?

Reply on news.ycombinator.com