Encourage users to password encrypt their keys.

[vext01]

The README contains this passage:

Passphrase-protected identity files are not necessary for most use cases, where access to the encrypted identity file implies access to the whole system. However, they can be useful if the identity file is stored remotely.

We've discussed this before when password encrypted keys were being considered. They are now implemented, which is great! Thank you.

However, I disagree that password protection mostly isn't required. I do still think that we should encourage users to password protect their keys by default.

Why? We can't possibly trust every piece of software we run on our systems, and it would be trivial for a malicious program (or a malicious payload for a trusted, but flawed, program -- think Javascript in a browser) to search for, and transmit, private keys over the network (undetected).

By password protecting keys, we at least don't make it trivial for the bad guys to use a stolen key. This is why ssh-keygen and gpg ask for passphrases by default.

There would be two approaches to addressing this in age:

• Update the docs where you talk about generating keys to include the password protection step. Then users who copy/paste this will be using a protected key.

• Make password protection default and have a switch to turn it off if required.

Obviously the latter is more invasive, but more fool-proof.

What do you think?

[covert-encryption]

Storing keys on the system keychain would be a good option for some users, offering protection by a single password (often the same as the login password so that the keychain is unlocked when the user logs in) and providing at least some protection against other programs running on the same account (asking for a password in console is not secure either in presence of malware running on the local system).

In any case, password protection is quite crucial and effective to protect against devices stolen or seized revealing their contents, particularly when very few users actually have disk encryption enabled.

[FiloSottile]

Hi! My position has not changed on password-encrypted keys: they make sense when the place where the key is stored is at a different trust level than the age execution environment. On a modern machine with FDE enabled, most if not all scenarios that lead to compromise of the key file also allow logging or intercepting the password. I was persuaded that there are enough use cases where they are relevant, which is why they are implemented, but I did not change my mind on the default. It's also not age's job to compensate for the lack of FDE deployment, which anyway is increasing AFAICT.

I am somewhat skeptical of the system keychain too, because the popup requesting the password is trivially spoofed, but I wouldn't be opposed to such a plugin. The real step up are hardware tokens, which is why we are focusing on https://github.com/str4d/age-plugin-yubikey, FIDO2 support, and eventually Secure Enclave.

[vext01]

Thanks for the swift response.

I take your point, that there are still many ways to stifle password protection, however I think there may be a little "nirvana fallacy" at play here -- the idea that because something is not perfect, it's not worth doing.

A password protected key will stifle opportune key thieves who don't have the time or expertise to (e.g.) spoof a pinentry.

[The other thought that crosses my mind is that yubikeys are pretty expensive, and it may not be realistic to expect everyone to have the spare cash to buy one]

Anyway, I'll stop now. I'm going to see if I can get an age key on a yubi.

Thanks for the discussion.

[vext01]

Another reason to encrypt the secret key is to protect against accidental disclosure.

e.g. accidentally putting a key in a webroot.

[covert-encryption]

@vext01 Yes, that could very easily happen if you run test servers on your personal account (very common for NodeJS development, VS Code "Live Server" and such), although at least some of them by default only listen on localhost.

For normal users the common accidental disclosure happens when iCloud or some other utterly stupid backup solution decides to send everything from your system to a cloud service completely unprotected. Apple, Microsoft and others are making it way too easy to accidentally enable these systems.

As for FDE, if a machine is stolen or confiscated powered on, the encryption can easily be bypassed. Having an extra layer of protected key storage, protected at rest, would prevent then leaking the keys as well. Installing a key-stealing pinentry is harder, needing the machine to be covertly hacked first, and that would obviously also bypass the FDE.

It is good to think of practical security rather than theoretical perfect security. Often developers don't implement things that would be beneficial because there is always something that can be used to bypass any security measure (Yubikeys included).

[FiloSottile]

I understand that perspective, but I don't think private keys are necessarily that special. On the list of files I would not want leaked from my disk, my age keys are not even in the top ten, after my cookie jar, some documents, my picture gallery, the cache of my WhatsApp Web messages... Degrading the UX because we think we know better than the user whether these files are the more sensitive and deserve more protection against hypothetical scenarios feels misguided.