0

I was reading this question about ssh authentication and there's a good discussion about authentication schemes. First, there's the answer that yes, ssh sends the full password to the server (but inside the encrypted tunnel). Second, there's talk about alternatives.

They talk a lot about the idea of sending the hash of the password instead of the password itself, but I haven't found anyone mention the following scheme:

  1. The server sends a nonce to the client.
  2. The client encrypts the nonce with a key derived from the password.
  3. The client sends the result back to the server.
  4. The server encrypts the nonce with the same key and compares its result to what the client sent.

This fulfills the objective of having a password-based authentication scheme where the password is never sent to the server during authentication, not even as a hash. (It does have to be sent once, when setting up the account.)

My questions are:
a) does this work?
b) does anyone do this?
c) is this any better than sending a hash?

I include the last question because I realized that having seen the nonce and its encrypted result, you could brute-force the password just like you could brute-force the hash. Is this the Achilles heel of this scheme?

  • If you hash the password and send that, then your hash is now your password. You might as well just think up a password, hash it locally, then use that. The server hashes the password (in the shadow file) to prevent your password from instantly becoming compromised if it leaks, so you'd end up hashing that hashed password anyways. – user Oct 14 at 16:38
  • @user Right, yeah, that's why sending a hash is a really silly idea. I guess my scheme is a way to achieve what the "send the hash" idea is trying to achieve. – Nick S Oct 14 at 16:47
  • Look into Kerberos, it does not require sending the password across the network and uses mutual authentication. – multithr3at3d Oct 14 at 16:55
  • Have a look at the "Secure remote password" protocol, I think you'll find it interesting – paj28 Oct 14 at 17:56
1

You are basically describing Digest access authentication. Only that it is not "encrypts the nonce with a key derived from the password" but that the nonce is hashed together with a value derived from the password. The basic idea of not sending the password but instead a response based on some server challenge and the password is the same though. The weakness is also the same: the server needs to know the password or some equivalent and thus cannot store it securely.

  • Ah okay, yeah I thought I remembered HTTP basic auth did something like this. Still seems to have the same exposure to brute-force, right? The MitM knows everything except the username/realm/password, so they can keep guessing it, repeat the process, and see if it matches the client response? – Nick S Oct 14 at 17:09
  • 1
    @NickS: "I remembered HTTP basic auth did something like this" - HTTP basic auth is just sending the plain password. HTTP digest auth instead is a challenge response method which hides the password. But yes, an attacker which can sniff knows the nonce and can thus brute force the password. Your variant of challenge response has the same problem though. Auth which does not have this problem is public key based, like SSH key based authentication or client certificates in TLS. – Steffen Ullrich Oct 14 at 17:13
  • Right, I was trying to confirm that it has the same issue as my scheme. And I realize that here's an argument for sending the password to the server: it can also be brute-forced, but only in an online attack! These schemes we're talking about here can be offline brute-forced! – Nick S Oct 14 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.