121–130 of 144 posts
I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…
Earlier quoted context omitted.
The "timing leak" here does not uniquely identify any word in the dictionary; the attacker is on the opposite side of the problem. This attack is implausible.
I'll make one more attempt. I don't think I can explain it any clearer than this: http://pastebin.com/MYT9kpgZ Here I model the server as a simple function that takes a password, hashes it, and compares it to a known digest with an '==' substitute. The function returns true or false, but also leaks information about how long the match was, through a simulated timing leak. This lets me identify the dictionary word tha…
I wasn't trying to be condescending when I asked how it was significant. I really didn't understand what you meant.
I've added a note to the article.
Earlier quoted context omitted.
Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples! Thanks for bringing this up--the concept of salt makes a lot more sense to me now.
Ya, that's silly. A common and simple password setup is hash(username+password) or hash(private_account_attribute+password). Also, use bcrypt/scrypt/similar.
The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…
No it's not a bad idea and essentially it's what BCrypt does. Think about it. If you use the same salt for all passwords then I can easily create a rainbow table consisting of "keyword" + salt hashes and doing so I can crack multiple passwords. However if there is a different salt for each password then this type of attack becomes more difficult as I have to essentially do the same amount of work for only a single pa…
There are deeper attacks too, but the above are just what can be derived from a bit of reading up on how the SHA family of hashes works.
For a closely related problem/solution, reading up on HMAC is quite enlightening.
Earlier quoted context omitted.
This is only a problem in the sense that once one hash has been cracked the so is the other, however most authentication is done using some user/email attribute also. Usually we fetch user/email, hash password, compare to hash in database - authenticate if match or deny if not.
So, no changing of email without changing the password then?
The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…
Aye. There are two points to the salt:
1. Avoid precomputed hash attacks ("rainbow table") where the attacker has a big list of hashes:password, and can just walk the table of (leaked) password hashes to get the cleartext. A global salt is sufficient for that, and where it's stored does not matter (can be a config file or a config table or whatever)
2. Avoid the attacker being able to brute-force the whole collection at once, there each password needs its own salt: the attacker needs a pair of (salt, hash) to be able to brute-force each and every password, it can't just compute a million (salted) hashes and cross-check all the table, it has to do so for each and every password it wants to crack. This requires a unique salt per password/hash, and the salt can just be stored with the hash.
Salts are not secrets, they just exist to make the hashing of a given user's password unique. They are generally returned as part of the hash function's result (alongside the number of rounds, so the result has the shape (cost, salt, hash)), it's understood and expected that the attacker knows them: it does not matter to their purpose.
Earlier quoted context omitted.
Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples! Thanks for bringing this up--the concept of salt makes a lot more sense to me now.
Ya, that's silly. A common and simple password setup is hash(username+password) or hash(private_account_attribute+password). Also, use bcrypt/scrypt/similar.
Not exactly. Having a salt at all mitigates rainbow table attacks, having a unique salt per password also limits brute-force attacks (you can't brute-force the whole table trying out cleartexts with a given salt, you have to brute-force each password individually).
Having a global unique salt is already better than no salt at all.