Store the password hashing salt on a separate server to slow down evaluation?

n-l-i

4/2/24, 12:55 PM

GPUs or dedicated hardware can calculate most things much much faster than regular computers ever could. There are password hashing algorithms such as scrypt and argon2 that make the difference smaller, but a powerful dedicated argon2 machine/cluster is still much more efficient than an old budget smartphone is.

My thought was that requests over the internet is something that is not much faster for a powerful system compared to a weak system. So could one store all required salts on a completely separate (trusted) server and make requests to it (and not storing or caching the response) each time a new hash needs to be calculated? The idea being that one would have to send a number of requests to a server to avoid having to brute-force an infeasibly large random salt.

Reference implementation:

username = "us3rn@m3"
password = "p@ssw0rd"

tmp = sha256(username)
for i in (0, ..., n):
    salt = http_request("https://other.server/"+tmp)
    tmp = sha256(salt+username+tmp)
password_hash = sha256(salt+username+password)

and the other server keeps a database, generating a new random salt each time a new request comes in and retrieving a stored salt for a request that has been seen before.

Could this technique (given a proper specification and implementation) be relied upon as a way to slow down hash evaluation as an alternative to memory hard functions?

Edit:
I can't see any obvious issues with the approach if both servers are not compromised together. If an attacker got access to both DBs, however, they would get easy access to all passwords. This is a big drawback of this approach.

0 + 4

password-hashing

knaccc

4/2/24, 1:54 PM

I'm not exactly sure why you referenced smartphones - can you be specific about the scenario where it would be the phone performing argon2?

n-l-i

4/2/24, 1:57 PM

It was just used as an example of weaker hardware. In practice I was thinking more along the lines of having an old laptop or a small cloud node as the server.

knaccc

4/2/24, 3:40 PM

I can't think of a reason that it would be helpful to have multiple requests to the salt server when you could instead simply require that server to rate-limit requests and provide a single salt per username. In general, you're right that a server whose only purpose is to provide salts will have a much smaller attack surface than your main app server which may have a much larger attack surface. The easier modern solution is to use WebAuthn instead of passwords.

n-l-i

4/2/24, 5:08 PM

That is very true. All requests should see response times independent of the input parameters, so can't rate limit based on the username, but that doesn't mean that responses need to be quick.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Store the password hashing salt on a separate server to slow down evaluation?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.