3 ms·

If an attacker can get access to your (encrypted) private key file, you have other things to worry about. And the passphrase doesn't help against memory-based a

If an attacker can get access to your (encrypted) private key file, you have other things to worry about. And the passphrase doesn't help against memory-based attacks (e.g. Heartbleed) anyway. A passphrase is mostly a hassle; someone will have to enter it after maintenance or (worse) a power outage.

Someone1234 11y ago
I agree, I find passwords on certificates useful in some circumstances and bothersome in others. I think putting a password on a root CA certificate is just a bother without any REAL security advantages. First off you'll need to enter it on every restart, secondary the raw private key will need to be in memory after that (which is trivial to extract), and lastly if the machine is completely owned anyway, this seems like "rearrange the deck chairs on the Titanic." Now putting a password on your SSH keys? Heck yeah. Otherwise if you forget to lock your machine just once, someone can sit down, open your SSH client of choice and have access to a remote session as "you" without the need for a single password. It might not be unbreakable but it is a nice extra layer of security that buys you time if your laptop gets stolen or similar.
- edwintorok 11y ago
  if you use that CA to issue a leaf certificate for your server then you don't need the root CA's password or decrypted private key to be in memory all the time, but then of course you make generating self-signed certs more complicate (generate self-signed root CA protected with password, and use that to issue a passworddless leaf certificate).
akerl_ 11y ago
The fact that you make several valid points doesn't mean keys shouldn't default to having passphrases. Yes, there are attack vectors which having a passphrase doesn't protect against. Yes, passphrases require additional considerations when starting services. No, this doesn't mean they're "mostly a hassle". No, you probably shouldn't default to passphraseless keys.
- ryan-c 11y ago
  In at least 99.9% of cases, the an RSA private key used by a service will be stored unencrypted. Would having a default that's the opposite of what nearly all users want be sensible?

Someone1234 11y ago

I agree, I find passwords on certificates useful in some circumstances and bothersome in others. I think putting a password on a root CA certificate is just a bother without any REAL security advantages. First off you'll need to enter it on every restart, secondary the raw private key will need to be in memory after that (which is trivial to extract), and lastly if the machine is completely owned anyway, this seems like "rearrange the deck chairs on the Titanic." Now putting a password on your SSH keys? Heck yeah. Otherwise if you forget to lock your machine just once, someone can sit down, open your SSH client of choice and have access to a remote session as "you" without the need for a single password. It might not be unbreakable but it is a nice extra layer of security that buys you time if your laptop gets stolen or similar.

edwintorok 11y ago
if you use that CA to issue a leaf certificate for your server then you don't need the root CA's password or decrypted private key to be in memory all the time, but then of course you make generating self-signed certs more complicate (generate self-signed root CA protected with password, and use that to issue a passworddless leaf certificate).

akerl_ 11y ago

The fact that you make several valid points doesn't mean keys shouldn't default to having passphrases. Yes, there are attack vectors which having a passphrase doesn't protect against. Yes, passphrases require additional considerations when starting services. No, this doesn't mean they're "mostly a hassle". No, you probably shouldn't default to passphraseless keys.

ryan-c 11y ago
In at least 99.9% of cases, the an RSA private key used by a service will be stored unencrypted. Would having a default that's the opposite of what nearly all users want be sensible?