11

Let's assume ssh key brute force is unrealistic.

It seems to me your greatest vulnerability would be someone gaining access to a client filesystem. If that's the case then key loggers and a host of other nasties are possible, making a passphrase a minor obstacle.

Is key bruteforce actually unrealistic? If key bruteforce is realistic, isn't it reasonable to assume a passphrase is also bruteforcable?

Dylan Madisetti
  • 245
  • 1
  • 7
  • 2
    If you use disk encryption on the system with the key, the benefits of a passphrase are pretty minor. I think passphrases are a hangover from the days when disk encryption was rare. I have asked a [related question](http://security.stackexchange.com/questions/66839/how-to-decide-whether-to-password-protect-key-files-in-addition-to-full-disk-enc) – paj28 Feb 22 '15 at 19:04
  • 2
    Too short for a real answer: It protects the key from being accessed directly from a backup. – Dog eat cat world Feb 22 '15 at 19:06
  • It might be a minor obstacle, but why anything easier for attackers? – RoraΖ Feb 23 '15 at 12:43
  • I think you guys bring up perhaps the best points. To me it seems the added utility of the passphrase lies in the chance the key is compromised but not the system (Whether read from a disk, backup, ftp server etc..) – Dylan Madisetti Feb 23 '15 at 20:11

2 Answers2

7

For starters, yes, key bruteforce is unrealistic under normal circumstances. Any properly configured server will not allow you to make billions of guesses at the SSH key. If it does, there are some major problems with the security protocols of the server. All sorts of red lights should be going off from the logs of a production server if there are that many key failures against a single account.

http://blog.codinghorror.com/brute-force-key-attacks-are-for-dummies/ https://askubuntu.com/questions/2271/how-to-harden-an-ssh-server

For nearly all intents and purposes, it is in practice impossible.

Keep in mind that if someone has gained access to a client file system, you are already is very bad shape. However, that does not mean all further security should be abandoned.

For example, in the case of a remote exploit it is very common to gain shell access to a system without gaining full rights. For instance, a remote exploit of the Apache web server will land with a shell... as the server itself (whoami = apache), which isn't always as privileged as you might have hoped.

So in the case of a compromised client machine, you want to make sure that before compromise that machine has every sort of security protection it can to make post compromise life hellish.

There are many ways to compromise a client machine, so it isn't really possible for me to outline all the possible scenarios here but:

  • Make sure to do everything you can to lock down the machine from physical access. Good hardware management, full disk encryption, good passwords.
  • Ensure that once the attacker is on the machine the password to everything is neigh impossible to guess
  • Use a program to generate large, securely generated passwords. Store the passwords in a keystore that is locked when the user is away, and has a very large passphrase itself.
  • Enforce a policy that your users always full-disk-encrypt their laptops while on the move. This way a stolen laptop is useless to an attacker.
  • Use client side log auditing software (like ossec) to raise alarms when fishy activity happens on a client machine.
  • Configure a lockout on SSH key guesses. This will only slow an attacker down, but with a sufficiently good password it is almost a game over for the attack.
MrSynAckSter
  • 2,020
  • 10
  • 16
  • 3
    Playing devils adocate here ( note I agree with everything that you have stated ) , assuming that you have a passprase on your private ssh key, and the attacker has access to both public and private keys would it not be possible for them to simply brute force it offline ? Using the public key as a check and then hitting the real server once this has been compromised ? – Damian Nikodem Feb 22 '15 at 21:41
  • 1
    Even in an offline attack, with good equipment, an attack against a properly sized key or passphrase is highly improbable to succeed. We're talking years of data time from a nation state level adversary. The keyspaces are huge, and if the crypto is configured properly there wont be much you can do to lessen the space. – MrSynAckSter Feb 22 '15 at 21:43
  • 2
    that's completely correct, although you have to revise your "time assumptions" quite often ( or map moore's law over them , since it is logarithmic in scale ) and often you will be shocked at how long time to crack drops, and in the event that the user has a weak passprase then it's game over anyway ) – Damian Nikodem Feb 22 '15 at 21:59
  • 1
    As long as you use state of the art crypto with a large key, you should be fine for that aspect. Always have a good passphrase too. – MrSynAckSter Feb 22 '15 at 22:01
  • the purpose towards my comment was to state that the passprase is sort of moot if you can obtain a key pair ( both public and private keys ). Can you elaborate how having a large key or "state of the art crypto" would help offset that, both of those should only add trivial time to a potential offline attack ? ( my theoretical attack here involves a undetected compromise of a users machine with no sensitive data past the key pair , and knowledge that machine has ssh access too a more interesting target ) – Damian Nikodem Feb 22 '15 at 22:07
  • Because if you use flawed crypto, it would reduce entropy, or enable cryptoanalysis attacks. If you were to use state of the art crypto, the key is not going to be cracked. If it could be brute force cracked with an offline attack, it would happen all the time. A 256 bit RSA key will be neigh incrackable even offline. http://security.stackexchange.com/questions/25375/why-not-use-larger-cipher-keys "brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space." – MrSynAckSter Feb 22 '15 at 22:30
  • while I understand both of your explanations I am going to have to steer the comments back to the topic of pass phrases, because at the moment we are both talking about different things ( and the original question is about pass phrases ) how does state of the art crypto or a large key effect brute forcing of the passprase ? I can completely understand how this will significantly slow down an attack when we don't have any key at all. But in the scenario that I posted above I mentioned that we have both public and private keys ( just that the private has a passprase ) – Damian Nikodem Feb 22 '15 at 22:41
  • It doesn't, a large passphrase is also nearly impossible to bruteforce. In both cases the the *entropy* is decided by the size of passphrase/key. A mixed case password with special characters over 20 characters long with no words from a dictionary cannot be brute forced by any machine on this earth. Period. It doesn't matter how fast that machine is. If every atom in the earth became a small processor *it would still not be enough.* So no, there is nothing to slow you down. http://xkcd.com/936/ - https://howsecureismypassword.net/ also will help you visualize this. It is impossible. – MrSynAckSter Feb 22 '15 at 22:47
  • Of course this timeframe is assuming that we don't have a collision ( which does happen on occasion ), I don't like the word impossible because it is leaving yourself open, I prefer extremely unlikely. But I did finally manage to drag a answer out of you or to get your blinkers off about the fact that pass phrases and keys are 2 separate and distinct factors. I could drag this out one step further and ask would it be more secure to have a key file with a high entropy password or simply a high entropy password on the account without a key ? – Damian Nikodem Feb 22 '15 at 23:28
  • The key with the password is a better choice in most cases in my biased opinion. http://security.stackexchange.com/questions/33381/ssh-password-vs-key-authentication breaks it down but *does not* discuss the prospect of using very large passwords. From a remote standpoint, the key is harder to guess than the password that, although long, may exist in a predefined dictionary of long passwords. Offline, I'm not sure it makes a massive difference, but I if you have the password protected key to brute force, it's really 6 in one half dozen in the other. – MrSynAckSter Feb 23 '15 at 00:12
  • Accepted since you gave additional hardening steps. – Dylan Madisetti Feb 23 '15 at 20:09
6

You apply a passphrase on a ssh key as part of a layered approach to security. If you have concerns about system integrity do not keep the key on that system, keep it external on a usb, hsm, etc.

You should consider the risk vs complexity and also consider the different scenarios of attack. If someone was to just brute force a key, that means they are guessing a value and do not need physical access to your system. If they have access to your system and you do not have a passphrase, they would not need to bother with a brute force because they already have the key.

If the attacker has system access, they will likely have the ability to intercept the actual key value at some point when its used and not need to brute force.

As an aside, a pass phrase is more likely to be a string which makes sense to a human and is shorter than the key value, therefore there is less entropy, etc. In most cases, it would take less time to brute force a pass phrase versus the key itself.

Eric G
  • 9,691
  • 4
  • 31
  • 58