3

I think I understand the difference between Public Key authentication and Password. But how do I decide which one to use and which one is most secure in what situation? Can anybody give me some real life example about when to choose public key and when to choose password?

2
  • 1
    Here you can find the answer: lwn.net/Articles/369703
    – Vombat
    Dec 2, 2013 at 13:37
  • 1
    Use public key: any time you can. Use password: when you can't use public key.
    – tylerl
    Dec 2, 2013 at 22:52

2 Answers 2

Reset to default
5

But how do I decide which one to use and which one is most secure in what situation?

A public key is probably always more secure than a password, as long as the corresponding private key has a password. This way, even if someone acquires the private key, it's still not usable unless they also have the password, whereas with a password, that's all that's needed.

However, brute forcing a password for a stolen key is probably easier than brute forcing a password for an ssh login, since the later will be slower and obvious -- the server will note the repeated failures and can restrict and report the attacker's IP. A 10 character password using Base64 characters has 64^10 = 1152921504606846976 possibilities, so it may be feasible for a clever person to crack this, if they can try it with their own equipment on a copy of the key.

Of course, you can't force users to password protect their private keys (unless you issue them). But you can't force people to be careful with passwords generally, so a password alone doesn't really solve the "irresponsible user" problem.

Can anybody give me some real life example about when to choose public key and when to choose password?

Some people find keys a hassle because you need to store them. Using a password login is its own hassle, though, if you frequently log in and out, since you must re-type the password each time.

6
  • Always thought you could remove password protection from private keys even if issued by a third party with a password. Cannot image how to prevent one from doing so.
    – Zelda
    Dec 2, 2013 at 14:14
  • @Zelda : Removing the password would require the password, since the key is encrypted with that password. Without it, you can't decrypt the key...but I think you mean in the case of issuing keys to users? Good point. I'm not keen on the idea anyway.
    – goldilocks
    Dec 2, 2013 at 14:27
  • 1
    There is some additionnal fact: If your key gets stolen, then generate a new pair of keys ASAP and make sure that the other key wil be invalid.
    – Bonsi Scott
    Dec 2, 2013 at 14:41
  • @BonsiScott How is that different from if someone figures out your password? You have to know in either case, or it becomes a moot point. Of course good security hygiene would be to change authentication credentials on a regular schedule anyway, but that goes for passwords as well as keys.
    – user
    Dec 2, 2013 at 15:14
  • Someone who steals your key (or your password) is unlikely to tell you about it anyway, lol.
    – goldilocks
    Dec 2, 2013 at 15:16
2

Which to use is rather simple.

Key based authentication is generally better as goldilocks has stated. But it effectively binds a user on machine 1 to a specific user on machine 2. Therefore it can be a giant pain in the back side if you need an unknown number of users or unknown number of machines to login.

A good example of when to use passwords would be a server in which it's mission critical to be able to access no matter where you are or what kind of device your using. So when you need access to that server you can get it, via cell phone, toaster oven, friends computer, public computer, or other place that you don't want to permanently "grant access" to.

That said, that server would obviously be a security weak point. Most people and circumstances should use keys. Passwords do have their uses though.

2
  • Your premise about keys binding "user on machine 1 to a specific user on machine 2" in a way that passwords don't is incorrect. You must log in as a specific user, whether that's via key or password does not make any difference. WRT having "an unknown number of machines to login" to, you can use a different key for each of them if you want (see man ssh, the -i option), and your remote user can allow for more than one key -- which actually makes the key login more flexible than the password login, since normal *nix systems only allow for one password per user.
    – goldilocks
    Dec 2, 2013 at 22:55
  • 1
    I disagree, but perhaps I was not clear. A key is a MACHINE + user to MACHINE + user combo. A password is simply a user to Machine + User combo. So 900,000 different machines to one machine + user, passwords are the way to go. Most of us don't really do that we connect 1 machine + user (coteyr@localhost) to 1 machine + user (someone@someserver). If I wanted to build a system that says no matter what client I (coteyr) want to connect to someone@someserver then my only real option is passwords.
    – coteyr
    Dec 3, 2013 at 4:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .