Hacker News Reader

Comment by slrz | Hacker News Reader

How is the timing here relevant to attacking shacrypt? The run time is a function of the length of the attacker-provided string containing the password guess. That's totally fine, the attacker already knows that string. The output is a fixed-length string that is then compared to a stored (also fixed-length) hash using a constant-time comparison function.

The run time does not depend on the length of any secrets here. I don't see the issue. How can I use that to determine the length of the actual password? That length isn't even available to the password verification system anymore.

View on HN

I think the author is arguing that if someone were to send a 1GB password that it could cause a DOS attack on the server performing the sha-hash of the password. Seems to me the simplest solution is to limit the length of password fields to something reasonable.

I always thought you’re supposed to hash on the client side first to avoid sending the password to the server, and then hash again on the server. Even if the password is a billion characters long, the server will only see a 60(?) byte array and hash that.

I'm of the mindset that clients shouldn't be trusted to compute sensitive hashes whether that paranoia is founded or not. Nevertheless, with https its perfectly fine to send the password in plaintext

What? The client already handles the plaintext password which is a lot more sensitive than a hash.

But the client could also see the SALT which makes it possible to use Rainbow Tables to decrypt the hashes. The SALT should be a secret to the client. Furthermore, as an attacker, I could just steal the DB hashes and send those from the client and viola I just bypassed your authentication without decrypting anything. If the server does the hashing, then it will recompute the hash of the hash which wont match.

Salts are designed to be public knowledge. They’re just supposed to be unique per hashed password to prevent rainbow table attacks against all passwords in the DB.

No two users should ever have the same salt, but they’re not a secret. As evidence I cite many of the Password Hashing Competition entries which offer “Server relief” as a feature by giving the salt to any unauthenticated client who asks so most of the hashing can be done on the client followed by a single hash iteration on the server.

A “secret per-server salt” is called “pepper” in the security community and is commonly buried in a binary or config file. Pepper has limited security value. An attacker that can get your password DB usually is able to pivot and snag config files and binaries as well.

To Start, you bring up an excellent point regarding the Pepper issue of a poorly secured salt(aka Cryptographic Key). Also, you are correct that an attacker that can get your password DB is usually able to successfully pivot.

So here's what I propose: Don't store the key anywhere. Instead, have it be computed from something(s) known and done in a very random and complex manner such that there would be no possible way to decompile release mode code in active execution without triggering a segfault and revealing yourself.

See the way you beat a rainbow table is you make the ultimate password large enough to exhaust the practical rainbow table limit since it grows exponentially. So if you do a SHA-256 hash of the password on the client size then you have effectively transformed it into a 64 character password, far larger than any rainbow table could hold. Now it is still susceptible to the direct hash storage in the DB. So I suppose the most secure way is to do it both on the server and on the client.

Good Post TaterSolid!

no that's not how it works.

If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, because you could simply use the stored hash as the password. This solution would only protect users from password reuse from theft.

Hashing with a negotiated salt and computing client and server side protects the password in transit but means storing the password in plaintext on the server. We use TLS (or SSH, or other encrypted protocols) to protect passwords in-flight instead, and hash passwords on the server to protect them from theft.

(Remember, the original attack password hashing was protecting against was a world readable file that contained all usernames and passwords, /etc/passwd on Unix. Eventually the world moved to "shadowed" passwords, where the hashes were stored in a root-readable-only file called /etc/shadow.)

There are systems where the user enters a key locally and it's not transmitted over the wire. Kerberos and SRP are two of them.

This is the correct way to do it. I would say that a negotiated Salt isn't necessary and infact should be discouraged. Let the Server use its mystery SALT to make it impossible to use rainbow tables should the database get hacked.

> If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, because you could simply use the stored hash as the password.

I'm not sure I understand this sentence. Are you reading the parent message as proposing hashing client-side using the same algorithm as the server-side hash and comparing directly on the server against the database-stored hash. This would be outrageously stupid of course, but I'm certain the commenter was not proposing that.

They said:

> hash on the client side first to avoid sending the password to the server, and then hash again on the server.

Note, hashing again on the server. To describe this slightly differently, think of the clientside algorithm as effectively being a password generator, with the user inputting their own memorable password as a kind of encryption* key for their "real" auth API password—the main advantage is fighting password reuse.

*encryption!=hashing but I'm just using the term here to illustrate intent.

It's passive observation of a successful authentication session. This may occur if the victim performs authentication over a network where you can observe the authentication traffic (even though it is encrypted in transit), or if you can inject a timing script that can observe when authentication starts and finishes, or if you can gain access to logs of the server performing the password check (containing at minimum e.g. IP addresses and timestamps).

> How is the timing here relevant to attacking shacrypt?

By observing the time on the CPU it takes for the password hashing algorithm to complete, you can learn the length of the password. It's a side-channel timing attack.

But, as mentioned in the post, it's a negligible concern. In the case of md5crypt, the algorithm processes the password in 16-byte blocks. For standard 8-bit ASCII, this is 1-16 characters. Knowing that the bulk of user passwords are 7-10 characters, we aren't really learning anything anyway. We're not assuming here the adversary has the salted password hash. We're strictly talking about observing running processes on the machine.

> The run time does not depend on the length of any secrets here.

For md5crypt, sha256crypt, and sha512crypt, it does. sha256crypt will hash a 10 character random password faster than a 35-character Diceware passphrase. That's the whole point of the post.

Reply on news.ycombinator.com