Comment by lordlimecat | Hacker News Reader

Comment by lordlimecat | Hacker News Reader

Parent Full thread

>You need both parties to know the nonce and the salt for this to work, so you’ll need to send it over.

I get the impression you don't understand what the nonce and salt are, so I'll break it down.

The salt is used to make the hashes for particular values unique to this site. It generally does not change across the site, but it makes it impractical to use pre-computed hash tables to find the original values for a given hash. By using a salt, the site ensures that transmitted hashes cannot be trivially reversed.

The nonce is used to allow the use of an HMAC to create a one-time hash that cannot be reused. This would typically be implemented as follows:

1. Service sends NONCE, SALT

2. Client Sends password as SHA256(SHA256(ClientPasswd + SALT) + NONCE)

3. Service Computes SHA256(StoredSaltedHash + NONCE), confirms that it matches what the user sent

4. If the two match, the user is authed.

An attacker cannot reuse what the client sent because the nonce is not reused, and he cannot fake the nonced hash because he does not know either the password or the StoredSaltedHash.

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.

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

As a 3rd party who thought he understood this, but then realized he didn't: thank you for explaining it

Reply on news.ycombinator.com