Comment by cyphar | Hacker News Reader

Comment by cyphar | Hacker News Reader

Parent Full thread

Just thinking out loud, but what happens if the SSH server provides two salts. One is the /etc/shadow salt (including the hash type and so on) and the other is a one-time nonce salt to avoid replay attacks. So the client will first generate a crypt(3)-style string (which is equal to the one that the server has stored in /etc/shadow) and then will hash it with the connection-unique nonce to produce a hash that the server can then verify.

Now, to be fair this does mean that you have to give every client the salt for the user they're trying to authenticate as. However IMO a password storage system should still remain secure even after you get the salt for the passwords (you didn't get the hash, so the salt is not useful information to an attacker).

Would that be a viable method, or have I missed something obvious?

Your scheme successfully avoids revealing the password to a rogue server, so it solves the immediate problem.

But your scheme has made the password hash be the password, which is unacceptable because it's equivalent to storing the plaintext password on the server.

Illustration. Here's /etc/shadow

    cyphar:salt:hash

With your scheme, an attacker is allowed to log in by providing

    f(nonce + hash)

so that's a red flag: the attacker doesn't need to know the password, just the hash. Looking at it another way, you've made the hash be the password.

(FWIW, I initially thought your scheme worked, but couldn't believe a solution had been overlooked and so I tried it with a concrete example and only then realised where the problem lay. )

Yeah, I see what you mean. And this would presumably allow someone who has read access to /etc/shadow to be able to log into the server with ssh (something they couldn't do with `sudo` without cracking the password first).

Reply on news.ycombinator.com