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?

4
  • 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
    – paj28
    Feb 22, 2015 at 19:04
  • 2
    Too short for a real answer: It protects the key from being accessed directly from a backup. Feb 22, 2015 at 19:06
  • It might be a minor obstacle, but why anything easier for attackers?
    – RoraΖ
    Feb 23, 2015 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..) Feb 23, 2015 at 20:11

2 Answers 2

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.
11
  • 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 ? Feb 22, 2015 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. Feb 22, 2015 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 ) Feb 22, 2015 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. Feb 22, 2015 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 ) Feb 22, 2015 at 22:07
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.

You must log in to answer this question.

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