keybase / keybase-issues

A single repo for managing publicly recognized issues with the keybase client, installer, and website.
902 stars 37 forks source link

Private key is stored on disk and exported unencrypted without user's knowledge #2863

Open fortran77 opened 7 years ago

fortran77 commented 7 years ago

I installed the Keybase desktop application for OS X and exported the PGP private key with the command keybase pgp export -s > somefile.txt, and imported the resulting file into multiple instances of the “Mailvelope” extension for Google Chrome on multiple machines.

When I did some test transmissions of PGP-encrypted mail with Mailvelope I was never prompted for a passphrase. That is when I realized that Keybase had done something that encryption software should never, ever do without the user's explicit request and consent: It had exported a private key in the clear.

Equally bad, Keybase installs the user's private key into GPG keyring in the clear. This too is a bad idea. The private key should remain unencrypted only in RAM and only while the Keybase application is active. There is no good reason why the private key should ever be stored on disk in the clear.

Understandably, we don't want to prompt the user to enter a passphrase each time the Keybase application starts up when the machine boots. The preferable mechanism here is to use the OS keychain, which will be unlocked when the user logs in, and relocked when the user logs out.

This problem was indirectly reported in Issue #2676. The official response was:

Judging by this post from Chris it looks like keybase pgp export --secret decrypts your private key. So you would expect a decrypted key to be in plain text and without password.

I don't think this is a good reason for why the private key is being exported in the clear, or why it is inserted into the user's GPG keyring in the clear. The average end-user will not know about a tiny comment hidden somewhere in Github that warns him to expect an unencrypted key to be stored on disk. If a private key is to be stored unencrypted (and I cannot imagine why that would ever be the case), the user should be loudly warned before, during, and after this is done.

The default action should be to encrypt the private key with the user's password that is used to log into Keybase.

diego898 commented 7 years ago

bump?

saj commented 7 years ago

Equally bad, Keybase installs the user's private key into GPG keyring in the clear.

I think this behaviour contradicts keybase's own documentation.

keybase pgp help gen

   [...]
   Also, by default, the public half of the new PGP key
   is exported to the local GnuPG keyring, if one is found.  (For now,
   you must export the secret half to gpg manually with a command like
   'keybase pgp export -s | gpg --import'.)

I gen'd a new keypair (with --multi) and was surprised to find a new secret key listed in gpg --list-secret-keys. gpg --export-secret-keys | gpg --list-packets confirmed this key was stored in plaintext.

maxtaco commented 7 years ago

Hi everyone, thanks for your feedback here. As I recall, our thinking here is that those users who used Keybase to generate their private keys were unlikely to be GPG experts, and therefore would favor ease-of-use over security. You guys aren't sitting where I am, and we see so many people forget their passwords and getting locked out. We were hoping to avoid that issue with that feature, at the expense of security against local compromise.

Furthermore, as I recall, Go's libraries didn't have an S2K encryption/export feature when we wrote these features.

Going forward, we can consider a number of options. Maybe the easiest would be to export the private key encrypted with the user's keybase passphrase, as suggested here, or rather to provide ample warnings.

Sorry the docs drifted away from the code, we'll fix that too.

Thanks everyone.

maxtaco commented 7 years ago

Some doc fixes landed in this commit. We'll get to encrypting the exported private key soon.