13

If an attacker takes control of a server and a user tries to SSH into it using password authentication, can the attacker get the password?

I was under the impression that there was an algorithm in place that demonstrated the client holding the password without revealing it to protect against the case of a malicious server (1), but this article says otherwise:

The simplest is probably password authentication, in which the server simply prompts the client for the password of the account they are attempting to login with. The password is sent through the negotiated encryption, so it is secure from outside parties.

Could someone clarify if this is correct?

  1. something like the Socialist Millionaire, but with one side only having a salted hash?
  • 6
    How would the server calculate the hash to validate unless it had a clear-text copy of the password? – Neil Smithline Jul 23 '15 at 3:08
  • Good call! I've generalized the question to not propose a particular algorithm. I'm thinking of something along the lines of Socialist Millionaire, but with one party holding a salted hash of the password. – Andrey Fedorov Jul 24 '15 at 2:42
  • 1
    The protocol you're thinking of is SRP - Secure Remote Password. SSH does NOT use it by default, although I think there are some experimental add ons. Not widely used though as SSH keys offer similar benefits – paj28 Jul 24 '15 at 6:18
  • 1
    "I was under the impression that there was an algorithm in place that demonstrated the client holding the password without revealing it to protect against the case of a malicious server" AFAIK, that's only true for key-based authentication. – Ajedi32 Jul 29 '15 at 13:51
  • 1
    @NeilSmithline That would not be too hard if the hashing algorithm was designed with that usage in mind. For a general purpose hashing algorithm it is also possible in principle, but infeasible in practice. We are talking about something on the order of invoking a cryptographic primitive once per gate in a network implementing the hashing function. – kasperd Jul 30 '15 at 5:23
8

What if we sent the hash?

If the hash were the authentication parameter, and not the password, then the hash would be the authentication parameter.

To explain that tautology in more depth: a password is hashed so that if the data store of passwords is compromised, one doesn't have a functional authentication credential. For that reason, it is the password that is sent to the server where the server performs the work to calculate the hash. Sending the hash of a password would be exactly the same as using a password generator with no hashing.

Are your passwords compromised if somebody has control of the server?

They can still steal passwords, either by brute forcing the authentication store to generate the raw password, or more efficiently by altering the server's daemon code to record your password attempts.

  • I'm not suggesting we send the hash of the password, but rather the hash of the password and two nonces - one created by the server and the other by the client. This prevents modifying the daemon code to record your password on attempts. Having a chance to brute force the authentication store is not the same as having done it successfully and having recovered a password. – Andrey Fedorov Jul 23 '15 at 15:00
  • Someone pointed out in the comments that this would be impossible to validate unless the server has the password in plaintext, so I updated the question. – Andrey Fedorov Jul 24 '15 at 2:41
  • Updated it again with an alternative suggestion. I'm not sure if I'm qualified to suggest secure schemes, it just seems to me like a solvable problem. – Andrey Fedorov Jul 24 '15 at 4:33
  • 1
    It's a solvable problem (server stores password with N+I iterations, client sends N, server computes I iterations). The technical reason to no due this is that the hash has similar vulnerabilities to a regular password in almost all cases. Further, the client and server must agree on a protocol with the client executing that code. Either a risk from code being push from server or an update nightmare for the client. Therefore, the KISS principle applies and passwords are sent plain via standardized encrypted links. – Jeff Ferland Jul 24 '15 at 16:05
  • 1
    What about just using a challenge response authentication mechanism like SCRAM or SRP? If enrollment is implemented the right way, both have the property that the server never gets in touch with the bare password or something it can use to log in to other servers. Brute-forceability though is a property of password based auth which no protocol can save you from. – user10008 Jul 29 '15 at 15:08
6

Could someone clarify if this is correct?

Yes, it is correct that the password is known to the server in plain text. RFC 4252, section 8 specifies the "Password Authentication" for SSH, and it writes (freely cited):

Note that [...] the cleartext password is transmitted in the packet [...].

I also wanted to provide an answer, not on the question itself, but on

Can you design a protocol which doesn't send the server the password or values equal to the password?

The answer to that is Yes.

You should ensure your protocol does the following:

  1. (more part of the implementation) The user has to have some means to confirm they aren't telling the password to the server. The smartest protocol is meaningless if the server can bypass it with displaying an text entry it can get the content of. This is a problem if your application is just a bare remote terminal, and the authentication is happening already during this "remote terminal mode", or if the server can "fake accept" the connection without a password entry, and then display its own. Another example would be a website with a html form. The http digest auth "dialog window pop ups" is designed with this problem in mind.
  2. You should use a challenge response protocol like SCRAM or SRP. If your password enrollment is designed in a way you don't provide a key to the server (or you trust the server at enrollment time, like in your example), both of them don't give values to the server they can use for login at other servers with the same password. For SCRAM, your salts have to be unique per server, SRP relieves you from that duty.
  3. You should use encryption together with Channel binding between your encryption layer and your challenge response layer. This will make infected servers not be abled to play "man in the middle" to a targeted server for the authentication part of the connection, then do their evil business after it. SRP supports this by its nature as its a key exchange protocol, and the official SCRAM RFC has support for channel binding too.

However, this is a mostly theoretical discussion. You should use ssh keys wherever possible, because they offer much better brute-force protection.

  • Thank you. That's exactly the answer I wanted to write, but didn't have the time to do the research to point to the correct answer. Also good answer about challenge/response. – Steve Sether Jul 29 '15 at 15:54
  • don't give values to the server they can use for login at other servers with the same password ah, that would be a huge step forwards for users. I've seen many places suggest "for security, use a different password for each (website, etc.)" - as if that were a practical solution for a human being. – ToolmakerSteve Sep 20 '16 at 10:29
  • Somebody please tell me if SSH ever gets around to supporting this. – Erhannis Nov 23 '18 at 18:34
0

Could someone clarify if this is correct?

That is a relative issue. I mean it depends on the nature of control the nefarious person has over the server. If he is skilled enough to modify/trap SSH daemon (situated on the server side), he could get your password. But that is less practical in reality because there are easiest ways to get your password for a stubborn hacker by brute-forcing your password.

But still the safest way to connect to the server using SSH is to use Use public/private key pairs for authentication instead of passwords because brute-forcing them is simply impossible.

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.