Hacker News Reader

Comment by jpeterson | Hacker News Reader

The takeaway here? If you want to "hack" into sites like these, you're virtually guaranteed to succeed by picking a few random usernames, and trying some combination of "123456", "password", "12345678", site name, and "qwerty" for password.

I think it's time for someone to come up with a radically better authentication mechanism.

View on HN

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]

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.

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/

> 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.

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

...which would allow you to comment on a blog article as someone else. Yikes!

Reply on news.ycombinator.com