-1

Consider the following hypothetical algorithm for password-based login for, say, SSH:

  1. The client sends its username and client_auth = HMAC(password, client_timestamp) to the server.

  2. The server verifies the client_auth and responds with server_auth = HMAC(password, server_timestamp).

  3. The client verifies the server_auth and begins encrypted communication using the shared key = HMAC(HMAC(password, client_auth), server_auth).

One more thing: assume that the password was computed from a hidden secret belonging to the client, as follows: password = HMAC(private_secret, public_server_address).

The client uses this one single hidden secret to generate passwords for all services it uses.

My question is:

Is this scheme as secure as public-key authentication? And if not, what is the advantage of public-key authentication?

(Obviously, assume that private_secret was generated with sufficient entropy.)

  • Comments are not for extended discussion; this conversation has been moved to chat. – schroeder Dec 6 '17 at 14:12
  • 1
    If I understand this correctly, password is known to the server in plaintext, and your scheme doesn't cover how the client and the server know this shared secret (maybe trust on first use, maybe out of band, etc)? In that case what you seem to have here is a simplistic and weak kerberos-like protocol with all its downsides, but none of its benefits. Either way you might want to clarify, because currently your question is missing essential information. – tim Dec 6 '17 at 14:18
  • @tim: It's exactly the same way the server obtains the client's public key. When you set up an SSH server how do you tell it your public key? Do the same thing here for the password`. – Mehrdad Dec 6 '17 at 14:23
4

The advantage of public key authentication is that the server only needs the public key to check if the client is the claimed one, i.e. the one having the private key matching the public key. And, since the private key can not be practically derived from the public key an attacker compromising the server can not use the captured information to identity itself as the client.

In your proposal instead the server and client need a shared password so that the server can validate the client. While you attempt to protect this password during transport it still must be stored somehow at the server. Thus, an attacker compromising the server can extract the password. Since the password is all what is needed by an attacker to identity himself as the client your proposed scheme is way less secure than public-key based authentication.

  • "And, since the private key can not be practically derived from the public key an attacker compromising the server can not use the captured information to identity itself as the client." How exactly in my scheme is deriving the private_secret from password any easier...? – Mehrdad Dec 6 '17 at 13:59
  • 2
    @Mehrdad: The client does not derive the private_secret from the password. Instead the client derives the password from the private_secret and need to share it with the server. For the attacker knowledge of the password is sufficient to impersonate the client against the server. And he can get the password when compromising the server. – Steffen Ullrich Dec 6 '17 at 14:12
  • Ahh, I didn't realize you meant that point in the context of the following sentences. Makes more sense now, thanks. +1 yeah. Interestingly I was trying to avoid the leakage of the password from affecting other servers, but completely forgot to worry about the same server. However, it makes me wonder: if the server is compromised then aren't you already toast? How often in reality does an attacker find a way to read a sensitive file like /etc/shadow without also finding a way to access all the other data he wants, or without finding a way to write backdoors into it? – Mehrdad Dec 6 '17 at 14:28
  • 1
    @Mehrdad: Your question asked if this scheme as as secure as public-key, which it is is obviously not. The rest of the idea is mainly deriving the shared server-specific password from a master password (well known idea) and somehow protecting the password in transport for which established methods already exist: use SSL or if SSL is not possible digest authentication. – Steffen Ullrich Dec 6 '17 at 14:39
  • 1
    @Mehrdad: You are proposing a custom authentication scheme so chances are high that it will be built into some web application and that the passwords will be stored inside a database. In this case an SQL injection can be sufficient to get to the password and no further compromise of the server is needed. How about Yahoo! Voices Hacked With SQL Injection – Passwords In Plaintext for an example of such attack. – Steffen Ullrich Dec 6 '17 at 15:14
1

This is a client-side password hashing scheme that uses peppers instead of salts and does nothing to secure the password stored on the server.

And the use of the same secret across all user's logins makes this no different from using the same password across all sites. This one detail alone presents numerous usability and implementation issues if you want to change that secret, for instance.

If you drop the "global password" detail, then you are left with a password hashing scheme that would be better replaced by a standard password hashing process.

  • -1 "And the use of the same secret across all user's logins makes this no different from using the same password across all sites. This one detail alone presents numerous usability and implementation issues if you want to change that secret." This makes zero sense. (a) There's no rotation assumed in vanilla public-key auth either. But you can add it just as easily to either. (b) Breaking the server hash = breaking HMAC+SHA256, just as breaking the public key = breaking RSA. Both are always assumed equally infeasible. Encrypting with the same private key is like HMAC'ing from the same secret. – Mehrdad Dec 6 '17 at 15:13
  • a) if you expect to change the key on one (which violates one of your design elements) then you have a poor hash+pepper scheme (as mentioned). b) as a design defence, you cannot state "but technology X is unbreakable" as a valid design statement, only as a mitigation statement. The fact remains, if one can break one password, then all the others fall, too. – schroeder Dec 6 '17 at 15:19
  • "As a design defence, you cannot state "but technology X is unbreakable" as a valid design statement, only as a mitigation statement. The fact remains, if one can break one password, then all the others fall, too." Yet again, your reply makes no sense. Literally exactly the same statements hold true for public-key authentication. – Mehrdad Dec 6 '17 at 15:25
  • @Mehrdad I'm pretty sure no one would advocate to use the same private key for all communications. It makes sense, you just refute the assertion. – schroeder Dec 6 '17 at 15:31

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.