4 ms·
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
by matthiasl 10y ago
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. )
- deleted 10y ago[deleted]
- cyphar 10y agoYeah, 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).