3 ms·

Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same passwor

Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password, and that can make the hash way less effective in obscuring the passwords if/when leaked. There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts. There are a bunch of them covering the most frequent passwords. Since you are using the same salt for the whole site, two users with the same password have the same StoredSaltedHash, so you order by number of repetitions, and the most frequent is likely one of those ("123456" tended to be the most popular the last time I checked). This exposes your salt and then it's game over. What I'm trying to get across (and failing apparently) is that this is still vulnerable to lots of attacks, which means that you'll have to use HTTPS underneath all of this. Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security.

lordlimecat 6y ago
>Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password, This is only an issue if the hash can be reversed. The entire raison d'etre for salts is to prevent hash reversal via precomputed tables. >There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts Rainbow tables are already enormous-- in the hundreds of GB range for 9+ character passwords. Iterating over the range of possible salts makes the storage requirements untenable. As long as you choose an unlikely or unique salt which could simply be your site's FQDN or its MD5 hash, this isn't an issue. No one is going to have a rainbow table for md5(yourFQDN.com) as salt. >which means that you'll have to use HTTPS underneath all of this You should but it is not necessary for secure password transmission. This is a solved problem for decades now. >Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security. Layered security is a thing. Root CAs can be compromised, trusted CA stores can be tampered with, SSL busters like CRIME or BEAST can show up on the scene, someone can gain network access behind the SSL termination.... Layered security is why when LastPass got popped nothing of value was lost, because they used legit KDFs and salts. There's no increase in attack surface for using an HMAC behind SSL. If SSL is your only line of defense, your security model is stuck in the 2000s.

lordlimecat 6y ago

>Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password, This is only an issue if the hash can be reversed. The entire raison d'etre for salts is to prevent hash reversal via precomputed tables. >There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts Rainbow tables are already enormous-- in the hundreds of GB range for 9+ character passwords. Iterating over the range of possible salts makes the storage requirements untenable. As long as you choose an unlikely or unique salt which could simply be your site's FQDN or its MD5 hash, this isn't an issue. No one is going to have a rainbow table for md5(yourFQDN.com) as salt. >which means that you'll have to use HTTPS underneath all of this You should but it is not necessary for secure password transmission. This is a solved problem for decades now. >Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security. Layered security is a thing. Root CAs can be compromised, trusted CA stores can be tampered with, SSL busters like CRIME or BEAST can show up on the scene, someone can gain network access behind the SSL termination.... Layered security is why when LastPass got popped nothing of value was lost, because they used legit KDFs and salts. There's no increase in attack surface for using an HMAC behind SSL. If SSL is your only line of defense, your security model is stuck in the 2000s.