Whizbang wrote:Wouldn't the blacklist be hash values?
Of course it would. I think they explicitely mentioned that.
Derek wrote:Storing the hashed passwords is better, but still leaves you vulnerable to dictionary attacks and rainbows tables if your blacklist is stolen.
Rainbow tables are easily defeated with a long salt, since none of your existing tables will work, and computing a new table is as expensive as brute forcing the key space in the first place. It can even be the same salt for all passwords, so checking a pw against the blacklist remains cheap.
Dictionary attacks can work, but then you know that "12345" is on the blacklist. Now what? Are you going to try it against 3 million accounts? Do you really think the passwords you get with dictionary attacks are on the blacklist because they're currently in use on an active account? Also remember that you can compromise at most one account per password, since the blacklist guarantees them to be unique.
Sure, the blacklist introduces a vulnerability that can make offline dictionary attacks cheaper (assuming someone can steal not only the usernames and corresponding (individually salted) pw hashes, but also the list of blacklisted hashes). On the other hand, the blacklist forces users to strengthen their passwords to the point that both online and offline dictionary attacks become a lot more expensive. I think it's an improvement.
speising wrote:Thinking about it, why aren't bloom filters used for password verification? This way, the password list could never be stolen, since there isn't one.
So someone tells you an username and password, you give the password to the bloom filter and it responds: "Yup, that password is currently in use on some account in our system.. probably.". Would you authorize that login?
You need to link the passwords to the actual accounts, so you'll always have some kind of list that can be stolen and used.