Yubikey as a convenience unlocking device

grossolini

Hi,

In order to protect 1Password, we should really set up a complex password. This means we need to type said password multiple times a day, which is cumbersome. That means we are inevitably going to find workarounds, and end-user adoption will be a hard sell (ie. for Teams).

I'd like password managers to be more useful without getting too much in the way. One way I can see for this to happen, is to enable users to use smartcards to ease the login process.

One use case I really like is that I can use my Yubikey to log in to macOS, using native things: a new certificate is associated linked between the Yubikey and the OS account, and I can choose a simple numeric PIN to unlock my user session on the Mac; but I can also still use my regular password if I want to: that seems perfect as I can now set a really complex password for the user session, and I'll almost never have to type it myself, only in case of emergency (misplaced Yubikey).

Could we have that workflow for 1Password? I mean not as a complete replacement for the password, and not as 2FA either, but as an alternative to the password?
That would work for use cases where FIDO does work (Chrome browser, mobile with NFC...) while not locking out other use cases.

Thanks,

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

AGKyle

Hi @grossolini

Our general stance on this is that you should use a strong, but memorable master password. It's a trade off you have to make but if you make a nice strong master password that's still memorable and relatively easy to type it's still very very secure. This is how we all do it here at AgileBits. If it wasn't secure, we wouldn't use it ourselves.

So the idea of using a Yubikey (or similar device) has sort of two considerations:

The first is that you can set your master password in the Yubikey as a static password. Using their tool you can just assign it as one of the slots that it uses. Then when you invoke that slot it'll simply fill that string into whatever text field you have the cursor in. This would be supported today since nothing on our side has to change.

The second, as you say, would be to effectively allow the Yubikey to handle the generation of the password using a certificate chain of some kind. I'm not sure how this would work exactly but is not something we have on our radar at all right now. So, I'm afraid this one here is probably out of the question for the time being.

But I think I'd find it rather important to point out that having a nice strong master password that you can memorize is still going to be very secure. Particularly with 1Password Teams which includes the Account Key. By making it so the Yubikey does the work you're just taking the security beyond the already very secure territory to the point where you might actually be making it less convenient. Sure, the typing might be less fun, but you have other options, such as modifying your lock/security settings so you type it less. On iOS we have Touch ID, and as we announced on our blog Touch ID is coming to the Mac app as well. These all allow you to fine tune the security settings to make it so that you can still have a nice secure password but keep access convenient.

I hope I've understood your question and your concerns, but if I've missed something please let me know.

grossolini

Hi,

I fear I didn't make my concerns clear.

I am not worried about myself or the people who usually register an account with your services or with any password manager, since these people are usually bent on making their digital life more secure.

Who I am worried about, are people who wouldn't even think to use a password manager by themselves. We are setting barriers to entry that they don't want, and they simply won't do it.

I was not suggesting replacing passwords. My own password was indeed generated by 1password, it is memorable and secure and it is still quite long to type. Since I need to type it several dozen times a day to unlock my workstation, that's something I know I won't be able to convince many people to do unless I can provide a more convenient way at the same time. Or else they will just keep using weak session passwords & push for infinite idle session time, and we won't have gained anything.

So I think certificates and PINs could be a win, and smartcards a way in there right direction.
And I've seen many people here asking for the same?

AGKyle

Hi @grossolini

I'm really sorry for the delay in responding here. It has been a chaotic week for me both in and out of work so I had a ton of tabs open and this one got lost in the chaos. I'm very sorry you had to wait this long for a response. Particularly since it's mostly going to be questions...

It appears I did in fact misunderstand what you were asking for. In an effort to make sure I do understand:

Are you saying that you want some sort of alternative login system for websites?

Or are you saying that you want some sort of alternative unlock system for 1Password itself?

I don't want to dive into both of these for fear I may be confused still :)

I apologize if I sound dense in this situation but if you can help clear things up for me I would be more than happy to make sure to get you answers you need.

XIII

Hi guys, sorry to interrupt you, but: @grossolini can you please share your experience with using the YubiKey (4 VIP function?) with macOS Sierra?

I guess you still have to type your password to unlock FileVault at boot. But after that? Can you use the YubiKey to unlock your Mac? And whenever your password is requested? (App installation, sudo on command line, etc.)

MikeT

I'm curious to know as well, they did change the smartcard APIs in macOS Sierra and it is certainly cheaper than getting the new Macbook Pros with the Touch ID/Bar.

grossolini

@XIII Yes that's it exactly.

After setup of the Yubikey for a macOS account, you can logon or unlock your session by using only the Yubikey and its PIN (which is advised to be only numeric characters for keyboard layout compatibility reasons). It's a pretty neat experience, setup is easy and usage is faster than the native experience (with a complex password or passphrase, which you should probably have).

And yes, since you didn't enter your password at logon, macOS can't unlock your keychain (& hence FileVault); so if you're using it, you still need to enter your password after the Yubikey's PIN each time you reboot the machine. Honeslty, I don't do that very often so that doesn't bother me much.

Also, you can still use your password to open or unlock the session, so misplacing your Yubikey is not an issue.
This is what I meant by "convenience unlocking device" in the post above.

The only downside I've experience so far is that, as mentioned in a post on their forums, sometimes the PIN prompt is presented as a password prompt, which makes it confusing: sometimes you can't use the Yubikey and still have to use the real password. But that's probably going to be fixed at some point.

[Edit] About later password prompts inside the macOS session, the Yubikey doesn't work everywhere. The console is out, while some UI prompts are ok. Though at that point you can use a password manager like 1Password ;)

XIII

Thank you for your explanation.

I think I will not upgrade my (<v4) YubiKey (= buy a new one) and keep on using my Apple Watch to unlock my Mac for now.

AGAlumB

Fascinating discussion, and some exciting developments in this space! :)

XIII

In this video Yubico shows how you can unlock macOS Sierra with a v4 YubiKey:

AGAlumB

Ah, I see. I really wish they'd go with only one model though... Thanks for sharing that video! :lol:

SergeyK

:+1: for YubiKey (or any other secondary unlock option) for desktop clients.

Sorry, didn't mind trolling, but...

Your Android application provides alternative unlock option via fingerprint, which is from user standpoint really great!

I keep all my valuable assets in 1Password, and I have a long strong password.
And I need to enter this password 10 times a day. I hate it.

I know there were several hot debates about 2-factor authentication in 1Password accounts etc.... and I agree on 100% with your position on 2FA, but this is not about 2FA, this is about alternative unlock option.

Be it YubiKey or anything else, something needed to be added.

Windows Hello for example, you have "master password" to your account, but you can also configure multiple alternative options like PIN, fingerprint, etc.

macOS also supports fingerprint as an alternative login option, as well as YubiKey.

Why you would not support it in 1Password on desktop OS, if you already have it on Android?

MikeT

Hi @SergeyK,

2FA is coming to 1Password.com, we have it available as a beta feature for 1Password.com Teams with Duo integration at the moment.

There is no authentication in 1Password and there is no alternative unlock method, we decrypt your data based on the master password you give us. To handle it differently means that we have to store the master password in clear view on the device.

We handle this with TouchID on iOS and macOS because the password (technically a special device-specific derived key) is stored into the secure enclave stored on a dedicated co-processor separated from the rest of the system. Android does it with TEE and you can see more here.

We'd like to expand more with Windows Hello and mandate it with TPM or maybe the future SGX support as well. We do have Windows Hello support in the UWP version of 1Password (not available for new customers atm) but it is limited to a running instance of 1Password, meaning you still have to unlock with the master password as we can't store it elsewhere and keep it running in memory. We would rather be safe than sorry but if we can't be confident in the security of the keys, we can't add them. We will look into adding Windows Hello support to the desktop build of 1Password 6 for Windows once we finish with the core features first.

GuilhermePS

I would like to see this implemented as well, as an alternative to the Master Password.

Wouldn't it be possible to simply encrypt the Master Unlock Key (refer to the "Key derivation overview" section of the 1Password for Teams white paper) with one of the YubiKey's public keys (creating a "Wrapped MUK")?

Then, to unlock 1Password, you could either (a) enter your Master Password, triggering the derivation process described in the paper, or (b) "push a button" that would trigger a PKCS#1 request to decrypt the Wrapped MUK with the YubiKey private key.

As @grossolini mentioned, typing in the Master Password every time after you don't move your mouse for 10-15 minutes or lock the workstation is secure, but inconvenient. Having the YubiKey alternative, with a simple PIN, would be secure and convenient :smile:

"Storage" of the Wrapped MUK could be done with the same mechanism for storing the Account Key on each device; "storage" of a decrypted MUK could be done the exact same way you're doing it now after a user unlocks 1P with the Master Password. (Note that I'm using the term "storage" in a loose way, as in "in memory" or however you're doing it now.)

AGAlumB

I don't really have anything to add since Mike really said it all already, but it's helpful to know the kinds of options you'd prefer. Cheers! :)

GuilhermePS

@brenty Maybe I didn't express it well enough, but what I was addressing was mainly the security aspect that @MikeT brought up. So, I reviewed the 1Password for Teams white paper again and I'm outlining what I think is a possible approach that doesn't [significantly] weaken security (whether you choose to implement it or not is a different story -- I certainly understand that it doesn't pay off if only a handful of your customers have YubiKeys or smart cards).

1. As I understand it, 1Password today (a) stores the Account Key somewhere in storage (after the initial authentication) and (b) keeps the Master Unlock Key somewhere in memory (after it's derived with the Account Key, Master Password, and some other "non-secret data"), so that it can be used in decrypting the Private Key.
2. Now, we're looking to add a second unlocking mechanism. For it to work with minimal changes to the existing security model and application code, the alternative unlocking mechanism should be able to provide the Master Unlock Key; once it's done so, it's "business as usual" as far as 1Password's concerned.
3. I see two alternatives for implementing this, both relying on public-key encryption to protect the Master Unlock Key. In one case, the encrypted Master Unlock Key (EMUK) would be stored in storage, in the same way that the Account Key is stored. In the other case, the EMUK would be kept in memory, in the same way that the MUK is kept except that it would be wiped only when the 1Password process is stopped or the device is rebooted, not when the user locks the device or the inactivity period elapses. The public key used to encrypt the MUK would be one that corresponds to a key pair generated and stored within a YubiKey (YK) or smart card (SC); typically, use of the private key requires both possession of the device and a PIN.
4. The first option is more convenient than the second, but leaves your EMUK in storage; the second option is less convenient than the first, but still significantly more convenient than typing your Master Password every time your device is locked (similar to typing in your Master Password after rebooting an iOS device).
5. In both cases, you'd rely on existing PKCS#1 methods to encrypt the MUK and decrypt the EMUK as needed. Those would also handle prompting the user for his/her PIN.

You may be wondering "what does [significantly] weaken security mean?" What I mean by it is that we're now directly keeping an encrypted version of the MUK, either in storage or in memory.

However, I would argue that, if we trust the security public-key cryptography (which we do, as it's used to encrypt symmetric vault keys), the EMUK is of no value whatsoever to an attacker who gets a hold of it. The only exception to the foregoing is where the attacker -- in addition to obtaining the EMUK -- also (a) gets your YK/SC device containing the corresponding private key (!) and (b) gets you to cough up your PIN for that device. Not to mention the difficulty of physically stealing your YK/SC, if you're coughing up your PIN, isn't that the same as saying you're revealing your Master Password?

Going back to the point I made in the first paragraph, I suppose this is all really just a theoretical discussion, as I doubt there's sufficient interest in this for it to be worth your while to implement it. But, as a security enthusiast, I would appreciate your views on this -- and, who knows, it may be useful down the line :smile:

Guilherme

rickfillion

Hi @GuilhermePS,

I love the way you're thinking there.

For that to work you need a little bit more than the EMUK, but not much. To be useful you need not just to be able to unlock locally, but you'll want to communicate to the server. The MUK alone won't let you do that, and you end up needing the SRP x value in order to create a new session with the server.

We actually use what you've described here to do the unlock of secondary accounts (in the case of Windows I believe it may be all accounts). This is why you can have multiple accounts with different Master Passwords and only unlock the app with a single password. We store E(MUK) and E(SRP x) for those other accounts and from that we can unlock them without the password for that account without storing the password at all.

As for exposing this implementation for the main user account (the one used for unlock of the app)... that's a really interesting idea. I don't think it's something I've personally ever considered, but I see the merits. Thanks for bringing it up. :)

Rick