[Feature request] Two-factor authentication

[jyn514]

Title pretty much says it all. Passwords, even long ones can be brute forced, and once they're gone, they're gone. I'd appreciate even a basic 2fa using google auth (although of course open-source implentations are preferred).

[ruipacheco]

+1

[seefood]

just FYI: Google Authenticator is Free Software, released under the Apache License: https://github.com/google/google-authenticator-android (It's even available from F-droid's app store!)

Also, the auth methods of TOTP and HOTP are RFC and under the public domain for years. it's fully compatible with implementations in Microsoft Azure Authenticator, Keepass and the others out there.

Anyway, I vote +1 for TOTP and/or U2F, which I'm a very happy user of :-)

[smiller171]

TOTP and U2F would be excellent additions.

[junderw]

With the website login being an all-powerful poison pill to revoke all keys, I would feel much better if 2FA was an option.

[goeddea]

For the app: Why have just a username + control over an authenticated device at the time of pairing? I was expecting to be asked for the password as well (password + control over a device).

[georghendrik]

Personally, I’m trying to decide where the-continued-use-of-the-‘pass phrase’-after-signing-up-with-keybase falls on a scale between the achilles heel and the thermal exhaust port.

Adding two factor authentication to protect it does not seem to solve the problem —that a pass phrase that’s encouraged for ‘regular’ keybase.io use also allows for an account to be reset— instead, adding 2FA makes the problem worse.

Please consider the case when a keybase user loses access to all keybase devices and their keys. In that case, the pass phrase is the only way to reset all keys and recover the account. Requiring a 2FA token would likely prevent a legitimate reset, since the 2FA token is likely generated using one of the lost devices. So, adding 2FA will make it impossible to use the pass phrase in the only use case for which it may still be appropriate.

Instead of ‘protecting’ the account reset option with the pass phrase and 2FA, there should be a separation between ‘regular use’ of keybase.io, and the ‘all-other-keys-are-lost-please-reset-my-account use’. The pass phrase can be used for either, but should not be used for both. Instead, when keeping the pass phrase for ‘regular use’, paper keys can help to recover an account. And when keeping the pass phrase for account resets, perhaps the ‘regular use’ of keybase.io can be authenticated by scanning a keybase.io-QR-code with an authenticated keybase device.

What makes keybase.io different from Slack, Github, or Dropbox is that it’s designed that we do not have to trust a centralized server whenever possible. Adding 2FA is a step in the wrong direction.

TL;DR: 2FA bad. Kill pass phrase once device keys exist.

[ruipacheco]

Well, we need more protection but if you lose your keys, yes, you should be able to get back to them. How does this work with, say, Gmail accounts?

[seefood]

TL;DR: 2FA bad

I'll have to reread this to make sure I'm grokking your reasoning. for me, personally, between the passphrase, my pgp key passphrase and paper keys I keep in my KeePass database, I think I'm covered nicely with regards to fallback ways of re-entering my account. The point of a 2FA (and not just TOTP, there are other tools) is to subvert the stealing of your passphrase when you used a foreign computer with a keylogger, for instance. it can be U2F, or hitting OK on the keybase app on your phone, all of those are better than just entering username and passphrase when logging into the website. it can even be used for the CLI, of course, though hardware keys like U2F may be trickier to support.

[smiller171]

@seefood U2F is actually pretty easy to support if you use the libraries Yubico has created.

@georghendrik If you use U2F rather than TOTP then there's no central trust required, as you hold the private key and the domain is verified, vs TOTP where the server holds the private keys.

[goeddea]

@georghendrik - This should be handled like GitHub etc. do: You store a set of recovery keys (printing these out is suggested), and these can be used instead of the 2FA device when this is lost. Each key is for one-time use only.

[georghendrik]

@goeddea How is that different from having a paper key? In what scenario do you still have your keybase recovery keys, but not your keybase paper keys?

[georghendrik]

@seefood Thank you for taking the time to grok it. Please correct me if I’m wrong. There’s a distinction between resetting your account (destroying your data), which is what the pass phrase currently allows, and ‘re-entering’ your account using a device key or paper key (keeping your data).

There is a legitimate use case for resetting an account: it’s a last ditch way of keeping your username if all other methods of ‘re-entering’ are impossible.

In the case that a keybase user cannot ‘re-enter’ their account and legitimately wishes to reset their account, they are not likely to also still have the device that generates 2FA tokens. (For most 2FA users, the token device will not be a U2F one but rather their phone which would have the keybase app installed allowing a ‘re-enter’ instead.) The procedure of resetting the keybase account should therefore not be 2FA protected.

I'd rather see that the login to keybase.io is the same as provisioning a new device: by using a paper key or scanning a qr code — no typing of the pass phrase anywhere unless it's to reset your account.

[goeddea]

@georghendrik - Sorry for my lack of reading skills. (no sarcasm)

[georghendrik]

@goeddea No worries, we're all trying to make Keybase better.

Concerning reading skills, somehow I missed these before: #347 and #1169 on keybase-issues, and about twelve other requests for 2FA. There is also this: A-Plan-for-Two-Factor-Auth, but the author does not seem to be a current Keybase team member.

Edit: the issues are on the keybase-issues repo instead of this repo...

[ruipacheco]

Leaving this here: https://motherboard.vice.com/en_us/article/kz74ym/google-gmail-advanced-protection-security-keys-yubikey

[smiller171]

@ruipacheco I'm not really sure how that's relevant in this context. We've already been talking about U2F in this thread

[junderw]

How about: Once you have a provisioned device, require approval from any device along with the password to log in to the Web UI.

Now all you need is to make a paper key as a backup plan, and you're set.

And for people who sign up via Web UI and never provision a device, pester them relentlessly!!! mwahahaha

[kallisti5]

U2F is becoming a pretty major hardware token standard. There is even a W3C standard forming around it with chrome support today https://w3c.github.io/webauthn/

A quick search on Amazon turns up multiple cheap -> expensive USB tokens supporting the U2F standard.

[bbcorp]

👍 TOTP + FIDO U2F

[junderw]

The way I protect my account from being deleted without my permission is I just try to keep my logins down to a minimum and never login to a browser window.

However:

1. Since multiple accounts require logout and login on my device....... ugh... every time I login I wonder if some tricky MITM browser popup isn't just trying to intercept my password since my password is all they need to destroy my account. (Can't impersonate me, but destroying my entire sigchain is just as bad IMO)
2. Implementing TOTP 2FA literally takes 5 minutes. Add new endpoint called {user}/2fa/register and when they visit, check if they have TOTP enabled, if not, send them a response with 2FA token. Store the token in the DB, but keep the TOTP flag as disabled. Then give them a box to type their 6 digit code, when they click submit, it just POSTs the 6 digit code, then you check with the secret on the DB, if it matches, set TOTP to enabled on the DB and send them a nice "enabled, good job!" message. Then ask for it every time someone tries to login via web. (imo TOTP is only needed for web, so login via device doesn't need to ask for TOTP token)

I think the biggest reasons why this isn't implemented is:

• There is an idea in keybase team that "if a user loses everything (phone with 2FA, phone with device key, PC device key / paper key etc.) they should be able to wipe everything clean and restart anew (or delete their account) with only their username and password"... which I think is an ok DEFAULT for people who don't quite understand technology, or don't quite understand Keybase and how it works...

But I understand Keybase, and I would like an option to disallow someone who was able to phish me once from irrevocably destroying my entire account on Keybase, and affecting all the teams I manage... FOREVER.

Adding a tiny 2FA TOTP check on a small set of login requests is such a simple request, and could prevent some REALLY bad things happening to users.

If you're really worried about users losing everything, plop a big red warning on the TOTP registration screen. "Having this on and losing the 2FA device along with every device key will mean there is no way to recover your account and it will be frozen in time for all eternity. So be warned."

I would code it myself (in fact I would love to if you're willing to share the source with my privately) but the source of the web backend is not available publicly.

Another solution to this problem is to just never be phished, ever.

[nisc]

Please start supporting USB keys (e.g., NitroKey, YubiKey, etc.) or at least traditional authenticator apps (such as Google Authenticator). I consider this basic security in 2018, especially for a service like Keybase.

[yawn]

If you're looking for an integration of Yubikeys as TOTP sources via the go core (not sure if that's really the case here) https://github.com/yawn/ykoath might fit the bill.

[norenjr]

Would love to see an app-based or hardware 2fa as well.

[strib]

All: we have "lockdown" mode now, which gives you the benefits of 2FA without having to deal with codes: https://keybase.io/docs/lockdown/index

[junderw]

I love the new lockdown feature. It's so much better than classic 2FA.

In classic 2FA model, if the server is compromised, all the 2FA secrets are leaked. The hacker can then recreate any 2FA tokens on their device and if the break-in remained undetected by the server, then they would have a master key to everyone's 2FA without anyone knowing.

In the Keybase device key NIST model, the pubkeys of the devices are signed into the sigchain and committed to the blockchain... those SAME KEYS are the ones signing the request, and are ONLY accessible via an approved device.

This makes Keybase in lockdown mode much more secure than a keybase with some hypothetical 2FA (Authy/Google Auth)...

We are very happy with this feature, and I think this issue can be closed IMO.

One more thing I would add to make it even more secure is device permissions management. So I could revoke the permission of "add/revoke device" from all my devices besides my phone or paper key or something... then if my PC got hacked, they would get all my private info, BUT they wouldn't be able to revoke all my other devices, add their own device, and then revoke my PC from their newly added device, thus taking over my account without anyone getting a warning.

"Default new devices to not have device-add-revoke privileges" as a setting would also be nice.

But to be honest, that one final nit pick is not a "downside to lockdown mode" as someone who hacked your PC will see you log in to any service with 2FA and can screen-cap all your private emails, even open a hidden browser in the background and browse through your mails...

The "if your device gets hacked" attack scenario in almost every single service (gmail even) is catastrophic... but it would be nice if Keybase could help lock that down a little bit more.

[smiller171]

@junderw These downsides don't apply to U2F/WebAuthn, which would be the preferred way to implement 2FA in 2018

[junderw]

These downsides don't apply to U2F/WebAuthn

@smiller171 U2F uses public key crypto within the U2F device... but in Keybase the private keys are used extensively and must reside within their respective devices themselves (Phone, PC etc.)

Adding U2F to the current model would not make anything more secure. If my account is locked down, and I add U2F to the login process, how would that help?

2FA is meant to prevent a hacker from Russia (aka not in my box via rootkit etc) to enter my account via credential stuffing etc.

Currently the only place where that was possible is the web UI. Which a credential stuffer could log in and reset all keys. Then initialize his own device. (Keybase does provide warnings to people who try to interact to someone who recently reset all keys, but this could easily be ignored)

So even without 2FA, the credential stuffer was limited in scope of attack.

But now that I can lockdown my account, my Web login (the only area a credential stuffer could access) has 0 power. Nothing can be done from the web UI.

If you want to log in you need to completely take control of a device I have previously signed into my sigchain.

While I agree it would be cool to have a device support (whether it is U2F or not is irrelevant) where we could use a specific device (like a smartcard ie. Yubikey) as our "sole device approver/revoker"...

Which is exactly how I explained my "next step" recommendation. And the ONLY way a U2F device would be useful in the current Keybase security model.

Are you well versed in the way Keybase works? If so, then explain how you would think U2F could add a layer of security to a locked down account, and what attacks it could prevent.

"Anyone who doesn't use xxxx in year yyyy is insecure." is a poor argument.

[smiller171]

But now that I can lockdown my account, my Web login (the only area a credential stuffer could access) has 0 power. Nothing can be done from the web UI.

I want to use the web in some circumstances, I just want it protected by 2FA. I'm not asking for a U2F requirement on other devices.

[junderw]

I want to use the web in some circumstances

The web, even when not locked down, is severely nerfed and only kept there for old users who joined before the device based NaCl model was adopted.

Encouraging use of the web UI is probably not wise unless they add some new features to it. (ie. make the web a "device" and store the encryption keys in localStorage etc.) But this will undoubtedly lower security of any account using it (browser crypto is prone to error and localStorage is one XSS from a browser extension away from being stolen at any time... so I doubt they will do this.)

Adding 2FA to the web UI at this point would be like saying "well, we have a small set of users that refuse to add a device and only want to use the old keybase (which was web-based)... so do we appease them by adding 2FA which will still leave them open to a plethora of attacks, or do we try to encourage them to add and set up their devices in a way that is MORE secure than web+2FA."

The former is a valid decision, though it seems like backporting a bugfix to a version released 10 years ago because "some people still rely on it... sooooo"

At some point, Windows XP users need to upgrade. At some point, Keybase web-only users need to add a device.

Reminder: I am not a member of Keybase.

[donbright]

Might I point out the app, for MacOS/Linux/Windows is just some blob of code we downloaded off the Website?

[soullivaneuh]

Lockdown looks great, but:

In other words, the user's view of the Keybase Web site when locked down is roughly equivalent to an anonymous, logged-out user.

This is not really the wanted behavior for part of us I think. I will not used it, not because it is not a good thing, but it does not feet my need.

The main issue is the passphrase: Having 2FA will be a security barrier in case of passphrase crack with why not, notifications if some 2FA auth was not working.

[edmundlaugasson]

Lockdown seems to represent same idea as the key-based approach in general. Now there is a paper key which facilitates the user account management and makes key-based approach more appetitive for regular users. Same wish applies to 2FA as well - if Keybase accepted to create paper key in next of PGP then you could also accept to add classical 2FA in next of Lockdown mode. So people can choose whether they prefer to use Lockdown mode or classical 2FA. This is a win-win situation - Keybase usage (also awareness, more interested people to possibly also contribute) will increase without sacrificing any security, privacy which are main concerns to choose and use Keybase. The more people use Keybase the more secure and private our world will be and with that we will create better world to live in for now and in future. Especially in post-Snowden era what we have for now. In phone you can also use FreeOTP+, which allows you also to backup data. TOTP is definitely a good choice For FIDO standards there is a good website to get quick overview of current status and developments.

[qoomon]

any news for this topic?

[sudochop]

this is the only thing preventing me from using the service

[dapendragon]

It seems to me that a better fit for the Keybase security model is to add support for full FIDO2-based authentication (similar to devices and paper keys). In such a scenario even with a full local machine compromise the keybase data will still be safe without also having access to the owners security key (e.g. Yubikey).

This removes the dependency to MacOS keychain and other local storage variants for the passphrase, since the key will be stored on the security device instead.

While using FIDO2 auth the Keybase client should never "remember" login, and have options to auto-logout users after a configurable amount of time as well. Login is as easy as a button press on the security device, or holding it next to an NFC reader if supported.

[lostnet]

You make fido sound similar to paperkeys, but a paperkey is a key that can sign arbitrary things once it is available, a fido key only wants to sign specific messages that primarily help a relying party prove to themselves that you are the same. Creating an entirely transparent relying party to publicly audit or some similar mechanism to prevent blind trust in a particular server is probably not going to be straight forward.

[Kaishu-Sahu]

this is the only thing preventing me from using the service

Exactly, this same thing is preventing me as well.

[dmadisetti]

Hey, this over 7 years old if you consider https://github.com/keybase/keybase-issues/issues/77

@maxtaco Any updates on this?

[yugoslavskiy]

hello from 2022 🤷