9

I read an article about SSH-keys. The author says that they are stronger than password-based authentication. All you need to do is just to create a pair of keys (public key and private key), move your public key to the server and you are done. I know that assymetric key cryptography come in handy when encoding data, but what data do you encode in this case? So, why exactly SSH-keys are stronger than password-based authentication? For me private key is just a long password. The difference is only in the ways to enter the remote host. In password-based authentication you just type the password, in SSH-keys authentication you just type in the private key:

$ ssh -i privatekey.private user@the_server_address

So what's the difference?

Rodion Iskhakov
  • 103
  • 1
  • 5
  • 14
    Does this answer your question? [Why is using an SSH key more secure than using passwords?](/questions/69407/), [Is using a public-key for logging in to SSH any better than saving a password?](/questions/3887/). – Steffen Ullrich Feb 04 '22 at 18:09

5 Answers5

19

You are missing a lot. I think there are two main points:

  1. User-chosen passwords are low entropy. When people choose a password, they sometimes use really poor passwords (you can guess the password given 10 tries), and when forced to choose better passwords they usually only get up to about 20 bits of security. The standard today is 128 bits, so you need to select 12 words at random from a list of 2048 words using dice. That is a strong password. Nobody does this manually. A computer generated token of length 20 which uses upper case and lower case letters and digits would be a good password. Thus, many systems don't let users choose passwords and instead have the computer generate a token and let the user copy it. For example, AWS IAM secret access keys work this way.

  2. To authenticate a password the server needs to store a "recognizer" for the password. It can be the password itself but that is obviously very bad (an attacker can steal your password from the server's storage, even if you don't use the password while the attacker has access). To avoid this, for user-generated low-entropy passwords the server has to use a computationally expensive password storage system like argon2id. For a computer generated high entropy token the server can store the hash or HMAC of the token, which is computationally cheap and fast and secure. But, the server still needs your password/token during the login process to verify that you know the password/token. During this time when you're performing login, the server knows your password and an attacker in control of the server can steal it. With asymmetric cryptography, the "password" (your long term private key) doesn't leave your device. The server sends a new challenge and you compute a solution to the challenge on your device using your private key and send the result and the server has a "recognizer" stored (the public key) that lets it determine whether you have computed something that could only have been computed with access to the private key (a private key that the server has never seen). Someone seeing your challenge-response pairs cannot compute the response to the next challenge. This means that an attacker in full control of the server doesn't get to steal your private key. They might be able to fool you to sign / authorize bad things, but not steal your key, and when the attacker's access is revoked you don't need to roll your key.

One of the problems people have when trying to learn about asymmetric cryptography, which you appear to have not even tried to do but I hope you will now try, is that people's intuition about asymmetric cryptography is that the thing it promises to do (and actually does) is impossible. That a Diffie Hellman key exchange or a digital signature or a KEM are impossible, there must be some trick and there must be some way to just compute the private key from the public key or something. But no, asymmetric cryptography really does what it says, and you can't simulate that with symmetric cryptography.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • "During this time when you're performing login, the server knows your password and an attacker in control of the server can steal it." - How exactly does it happen? As far as I understand, it happens between the time when you entered the password and pressed 'Log in' button and the time when you actually entered the website? – Rodion Iskhakov Feb 05 '22 at 08:34
  • 9
    Simplest case: You type your password in the form, it is sent in the body of the http request over TLS, the TLS terminator, web server, app server, middleware, application logic can all see it and log it. The logs can be compromised. – Z.T. Feb 05 '22 at 12:57
  • 8
    Slightly less simple case: the server has your password in memory, something like heartbleed comes along, random people can exploit it and read the memory of the server, and see your password, without controlling the server _per se_ – njzk2 Feb 05 '22 at 16:43
  • 2
    @RodionIskhakov, you asked about SSH, and the way password authentication works there, is that SSH sets up an encrypted connection, and then just sends the password over it. Eavesdroppers can't get to it because of the encryption, but the server gets the password as-is. Usually the authentication module just checks it against the stored password hash, but it could just store it plaintext or whatever, and the client has no way to know. Which is why you shouldn't use the same password on multiple systems. That's not a problem with keys. – ilkkachu Feb 05 '22 at 21:38
  • @Z.T. But I think this problem won't happen with HTTPS, because it encrypts the data received? – Rodion Iskhakov Feb 11 '22 at 15:19
  • 1
    @RodionIskhakov of course it will happen with HTTPS, because "TLS terminator, web server, app server, middleware, application logic can all see it and log it". "You are missing a lot". – Z.T. Feb 11 '22 at 15:22
12

I know that assymetric key cryptography come in handy when encoding data, but what data do you encode in this case?

Basically, you encode some challenge/response data to prove to the server that you hold the private key (the secret key) that corresponds to the public key on the server. You never send the private key to the server.

So, why exactly SSH-keys are stronger than password-based authentication? For me private key is just a long password.

Yes, this is one reason why SSH-keys are stronger. They are effectively longer (and thus stronger) than typical passwords.

Another reason is that you do not have to transmit the secret material (the private key) to the server. You only have to prove that you possess the private key, as discussed above.

In password-based authentication you just type the password, in SSH-keys authentication you just type the private key: $ ssh -i privatekey.private user@the_server_address

No, you don't "type in the private key." You provide ssh the location of the private key file. Then ssh uses that private key in a challenge/response protocol to prove to the server that you hold the key, but the key never leaves your computer. This is different than the password, which you actually do type in and actually does get transmitted to the server.

So what's the difference?

See all the differences I explained above.

hft
  • 4,910
  • 17
  • 32
  • 3
    honestly I think this is the important part that the OP might be missing. You provide the server the password, but the key stays local. So it's not just a "longer password", but an entirely different mechanism – fyrepenguin Feb 05 '22 at 04:45
  • 1
    Another factor is the private key is usually (but not required to be) protected by a password. Therefore you not only have access to the private key, but you also have the password to unlock the private key. – ssh2ksh Feb 05 '22 at 07:47
  • How does a challenge/response data (or protocol) look like? – Rodion Iskhakov Feb 05 '22 at 08:23
  • 2
    @RodionIskhakov: basically, the server generates a random value and encrypts it with the client's public key (which you gave it earlier). The client decrypts the value with its private key (thus proving that it _has_ the private key) and sends it back. If you want more details, that's probably another good question to ask. – minnmass Feb 05 '22 at 09:09
  • 2
    The more common challenge response authentication using asymmetric cryptography is to sign a nonce using a digital signature and the other side verifies the signature. This is what ssh ed25519 and ssh RSA does. Another way is to perform an ephemeral-static DH key exchange, which is what noise protocol (e.g. wireguard) and signal (e.g. whatsapp) do. Encryption is also possible, with the obsolete TLS RSA key exchange being the most well known example, and post quantum KEM being the modern examples, but they are less common today. – Z.T. Feb 05 '22 at 18:34
  • As always, I'll link "digital signatures are not encryption": https://security.stackexchange.com/a/87373/70830 – Z.T. Feb 05 '22 at 18:36
4

Ssh keys are stronger that passwords for 2 distinct reasons:

  1. There is no "shared secret" so the private key is never known by the server. The server sends a challenge (a random value), the client encodes it with the private key, and the server validates it with the public key. On the other hand, even if only a hash of the password is stored, the server does receive the plain text password and if it has been compromissed, it can steal the password

  2. They have much higher entropy than the average password. They are always generated by crypto software so we can expect them to be as close to random as possible. On the other hand passwords that human can remember generally have a much more limited entropy and can be subject to social attacks (name of children of just the initials, name of a pet, etc.)

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
2

Modern keys are always stronger than passwords. They're also much harder to steal.

This is kind of like comparing an RFID-chip key for your car to a PIN code. They're both better than nothing, but somebody can guess your PIN (four digits means there are 10k iterations, which provides 13 bits of security) and nobody can reasonably guess both your key's tooth configuration (seven teeth with four levels is 16 thousand iterations) and the RFID code embedded inside it (32-bit encryption is 4 billion iterations, though since you need both, multiply them: 4⁷ × 2³² = 70 trillion, 46-bit security).

A password consisting of 16 random printable characters has 94¹⁶ = 104 bits of security (37 nonillion = 3.7e31 iterations), though this assumes the password is truly random and that's unlikely. The current standard for SSH is ED25519, which has 128 bits of security (340 undecillion iterations, about ten million times stronger).

You can think of keys as really long passwords, but they're actually a lot more potent than that. Passwords are hashed, meaning their entropy is limited by the entropy of the hashing function, while a key would use its higher entropy.

Additionally, you can be more certain the key fully represents its assigned entropy (whereas most passwords are designed to be memorable at the expense of their entropy). Passwords can be collected by phishing campaigns or man-in-the-middle attacks while keys are never actually transmitted anywhere.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
0

In addition to the above answers, some other cool things with SSH keys:

  1. I can generate the keypair, drop the public key on Github or Gitlab, and have a script to download them automatically for me on my staging servers. This key will work in all those places. When it is also setup to ONLY allow the publicly-accessible keys, that means I can revoke the keys whenever I need by removing them from my account.
  2. If I assign a passphrase to an SSH private key (miniscule but another step), I can change that passphrase as often as I want without having to replace the public key on my target servers.
  3. The randomly-generated key pair is not tied to something you know, like a password would be (i.e. hunter2 probably has a dog named Hunter). The seemingly-randomness is not personally identifiable as you, other than the comment at the end (which can be changed anyways).
  4. If you're using certificate-based SSH key authentication, things get even cooler (so I'm told - I haven't used them yet).
Canadian Luke
  • 296
  • 3
  • 13
  • 3
    all I see for the password in the third point is `·······` – Aaron F Feb 06 '22 at 17:12
  • 1
    @AaronF Weird... It appears normal to me... `hunter2` looks like `hunter2` – Canadian Luke Feb 06 '22 at 19:07
  • 2
    @CanadianLuke dude, you are not supposed to type your password in plain text. Don't worry, I changed it to something more secure. Be more careful next time. – emory Feb 07 '22 at 01:09
  • "@AaronF Weird... It appears normal to me... `·······` looks like `·······`" that's what I see – Aaron F Feb 08 '22 at 17:03