Client: How does the keybase app "remember my passphrase" on linux?

[presencia]

I just installed the keybase app on my linux pc. I noticed that when the "remember my passphrase" option is checked in the gui, I am not prompted for my passphrase on startup of the app, even after rebooting my computer.

I understand from the docs about local key security keybase uses os keyrings to store the passphrase when possible, but this feature is said to be only implemented on OSX. I am on a linux machine using gnome but keybase seems to login even with the gnome-keyring still locked.

I am confused. How/where does the keybase app store my login passphrase to remember it? Is it somewhere in plain text? Or some protected keyring I am unaware of? Or does the "remember my passphrase" feature work without storing the passphrase?

I have searched the keybase docs and github issues for an answer without success. I would greatly appreciate any help in understanding this feature. In case this is not the right place to ask this kind of question, please point me to the right direction. Thanks.

[junderw]

1. session token saved to disc in your home folder
2. device private key saved to disk in your home folder

[maxtaco]

Here's the overall protocol (cc @patrickxb):

• Your private keys are encrypted with a symmetric key p, which is the XOR of some server-stored data, and a portion of the scrypt stream derived from your passphrase.
• on macOS, iOS and Android we store p to the OS's keychain, since those OSes have nice hardware integrations and reasonably standard keychain systems (compare to Linux which has one for each windows manager -- groan!)
• on Windows and Linux, we don't have a nice keychain system, so instead we:
  
  
  
  • Generate a 2MB file of random data, call it f
  
  
  • Hash f to a 32-byte key h
  
  
  • Encrypt p with h, and write that to your home directory.
  
  
• This means that all the elements to decrypt your private keys are in your home directory, but when you "logout" or unclick the "remember passphrase" box, we zero out the file f. The thought here is that even if f is on an SSD (which makes it hard to actually delete file blocks), it's still very challenging for an attacker who has access to your unencrypted SSD to construct f, decrypt p, and then decrypt your secret keys.

[presencia]

Thank you for the quick and insightful reply, @maxtaco. This is just what I was searching for.
Although I am not a computer security expert and therefore forced to trust in the expertise of you developers in evaluating the security implications of any implementation approach, I can at least now understand the general idea. I feel much more comfortable in deciding whether or not I want to check the "remember my passphrase" option.

May I humbly suggest to include a short description of the concept---similar to your post---in the dos, e.g. on local key security?

[maxtaco]

Great idea, thanks!

[junderw]

Just out of curiosity, which Linux distro that doesn't come with gnome-keyring out of the box?

chromium auto detects gnome-keyring and uses if present, and pops up with a warning if not present and unlocked.

Any distro without gnome-keyring could easily package it in (deb, rpm, and AURs could easily include it)

I mean, yeah, I get that Linux is a small niche, but Linux does have a keychain in 99% of popular distros and the 1% could just be forced to install it via required dependencies.

[eli-schwartz]

You'd use libsecret, actually. gnome-keyring is just a frontend for libsecret, as it implements the org.freedesktop.secrets service and the DBus API is explicitly supposed to be generic (it is in fact implemented on KDE as well).

[maxtaco]

I couldn't find a Go wrapper for libsecret, do you know if a good one exists?

[eli-schwartz]

I googled around and did not find a generic wrapper either, but I did find https://github.com/docker/docker-credential-helpers/tree/master/secretservice which binds to libsecret using cgo.

Or you could use godbus and implement https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/

[maxtaco]

Thanks, we'll do some research this sprint

[joshblum]

@presencia updated docs are live: https://keybase.io/docs/crypto/local-key-security

[heronhaye]

We just merged in support for this feature, and it will be available in the next release (~3 weeks from now). You can try it out right now by installing a nightly.

It should work with any process that implements the D-Bus Secret Service protocol (usually gnome-keyring or KWallet). If your keyring is accessible, Keybase will ask you to unlock it if necessary and store passwords in there.

Note that if you're using a wm like i3, you may need to run dbus-update-activation-environment --systemd DISPLAY first (preferably in your ~/.xinitrc), but should work out of the box on Gnome or KDE. If you're on a headless system, your keyring must be unlocked before you start Keybase as there won't be a GUI for the keyring daemon to ask for a password.

Two caveats while we make sure this works reliably: you will not be automatically upgraded from file-based to keyring-based unless you explicitly log out and log back in again. And this will not be enabled for users who sign up without a password (a new feature coming soon). If Keybase is unable to access the keyring for whatever reason (perhaps it is not installed), it will automatically fallback to the file-based secret store described in the docs linked above. To disable this automatic fallback, you can run keybase config set -b force_linux_keyring true and Keybase will fail to login unless it can access your keyring.

[presencia]

Wow, that was quick! Thanks for the improved docs and the keyring feature implementation. I appreciate that.

[maxtaco]

After some feedback we got on a different channel, we are going to iterate a bit more on this, stay tuned.

[heronhaye]

We ended up going with a split key strategy where both the file data and the keyring data are required to "remember my passphrase", so it is as secure as the securer of the two.

As with before, you need to have your keyring running and then log out/log in to upgrade, and you must have an explicit passphrase set to use this feature.

For technical details, see https://keybase.io/docs/crypto/local-key-security#key-storage-on-the-device.

Let us know if you have any questions! Thanks. It will be available in the next release, 4.0.0.