Improving usability with hardware tokens
Hey,
I use the default 1Password security settings, and I like that. 1Password locks after screensaver goes on and when the computer goes to sleep. As others who work in an open office space, I lock my computer every time I leave my desk, and I usually close the lid every time I go to a meeting. On average I'd say I type my very long and very secure master password about 8-10 times day. I'm looking to optimize for typing my master password fewer times without sacrificing (much) security, suggestions are welcome. And yes, I'm aware of the secret key and that using a short and insecure master password is a viable alternative, but please work with me on this one.
I currently use a hardware token, Yubikey, to lock and unlock my computer, and by extension lock 1Password. When I insert my Yubikey, I type a short PIN and computer unlocks[2]—1Password doesn't (of course). When I eject my Yubikey, screensaver goes on and 1Password locks. Can you see any way I can use the Yubikey to unlock 1Password?
I think what I want is a similar workflow to how I interact with GnuPG Agent, or maybe how it is on iOS, but comments are welcome here:
- My GnuPG private key is stored on the hardware token, in order to unlock it, I need to enter a short PIN. Use this as a master password when opening 1Password. I can backup this key on paper using paperkey [1] and qrcodes. You'd need to make this work on iOS as well.
- OR, use a similar flow as you do on iOS. Require the master password once, and then accept login as long as the hardware token is present. If I can require iOS to use the hardware token as well, then that's an extra bonus.
[1] http://www.jabberwocky.com/software/paperkey/
[2] This works through PIV and PAM depending on whether it's OS login or screen save unlock
1Password Version: 7.1.2
Extension Version: Not Provided
OS Version: macOS High Sierra
Sync Type: iCloud
Comments
-
Hi @jgogstad
Definitely some interesting thoughts here. I think the primary challenges are:
- Your data is encrypted using your Master Password, not a PIN. We’re not likely going to change that, so at some level the Master Password needs to be entered. If that isn’t via the keyboard into 1Password, where is it going to be stored?
- Support for hardware tokens is seemingly quite limited on iOS
Another similar suggestion we’d love to find a way to make work if it could be done securely would be unlocking 1Password on a Mac via an Apple Watch or Touch ID / Face ID from an iPhone. Unfortunately that whole if it could be done securely caveat keeps popping up.
I’m not super familiar with Yubikey yet, having just acquired one earlier this month (just before they released v5, of course), but I believe it may be possible to store your Master Password on the Yubikey and have it type it? I’m not advocating for that, just mentioning that I believe it may currently be possible.
We will continue to investigate what options might be available in this area. :)
Thanks!
Ben
0 -
I believe it may be possible to store your Master Password on the Yubikey and have it type it? I’m not advocating for that, just mentioning that I believe it may currently be possible.
Yes, that's possible (but not advisable).
0 -
:+1: Thanks for confirming.
Ben
0 -
Hi @Ben ,
Please excuse the late reply.
Your data is encrypted using your Master Password, not a PIN. We’re not likely going to change that, so at some level the Master Password needs to be entered. If that isn’t via the keyboard into 1Password, where is it going to be stored?
I expressed myself a bit unclear here. I see two solutions: 1) The master password is derived from a PIN and a token-local secret, for instance using HMAC-SHA1 challenge-response. The PIN is the shared secret and the response is the master password. This should be easy to back up on paper as well. Alternatively, 2) you could use the PGP private key as a master password, the Yubikey requires a PIN for unlocking that and users could use GnuPG Agent or similar to keep the PIN in memory. The latter gets a bit unwieldly when backing up the master password on paper though. I get my 2048 bit RSA private key down to 4 QR codes using structured symbols version 40 and paperkey.
Support for hardware tokens is seemingly quite limited on iOS
True. Yubikey has an iOS SDK [1], but it only mentions OTP in the docs. Improving usability on Mac would be a big step forward though. You already provide face recognition for authenticating on iOS, and I think that works fine.
Another similar suggestion we’d love to find a way to make work if it could be done securely would be unlocking 1Password on a Mac via an Apple Watch or Touch ID / Face ID from an iPhone. Unfortunately that whole if it could be done securely caveat keeps popping up.
Sounds like just another variation of the same problem to me. Use an external token for authentication, be it Apple Watch or Yubikey is an implementation detail. But I agree, supporting such third factors would be very useful.
[1] https://developers.yubico.com/Software_Projects/Mobile iOS SDK/1.1.0/
0 -
@jgogstad: I wanted to jump back a bit to address this, just so no one gets the wrong impression:
I'm aware of the secret key and that using a short and insecure master password is a viable alternative, but please work with me on this one.
We really have to disagree on this point. Certainly we'll have to concede that it is possible to use a relatively weak Master Password (10 characters is the minimum for 1Password.com accounts, and we can't stop someone from using "DonaldDuck"), but it's not something we'd ever recommend or consider to be a viable alternative. We also have some suggestions that might help folks:
How to choose a good Master Password
It's important to note that the Secret Key does not protect against local attacks, since we should assume that an attacker would also be able to obtain the Secret Key in that case (from the user or from one of their authorized devices). So the purpose the Secret Key serves is to protect 1Password users from brute force attacks against their Master Passwords in the event that encrypted data is stolen from us.
I hate to be a pain about this since I'm sure you understand that, but I wanted to clarify for anyone who might be reading our discussion here. Thanks for bearing with me. :)
I expressed myself a bit unclear here. I see two solutions: 1) The master password is derived from a PIN and a token-local secret, for instance using HMAC-SHA1 challenge-response. The PIN is the shared secret and the response is the master password. This should be easy to back up on paper as well. Alternatively, 2) you could use the PGP private key as a master password, the Yubikey requires a PIN for unlocking that and users could use GnuPG Agent or similar to keep the PIN in memory. The latter gets a bit unwieldly when backing up the master password on paper though. I get my 2048 bit RSA private key down to 4 QR codes using structured symbols version 40 and paperkey.
It's certainly an inventive idea, but I'm not sure that's really solution for people. If GPG and similar technologies were even remotely accessible, most people would actually be using them, and we'd all be safer for it. The reality is that just GPG is a huge pain for almost anyone, and if we can't expect people to use that outside of 1Password, we also can't really expect them to use some variation of it tacked on to 1Password either.
Improving usability on Mac would be a big step forward though. You already provide face recognition for authenticating on iOS, and I think that works fine.
We also support Touch ID both on iOS and macOS. But certainly it's true that iOS devices with biometrics are much more common — and affordable. But personally I find it much less onerous to type my Master Password on a computer than a mobile device. Practice helps a lot, and a full size physical keyboard sure doesn't hurt either. ;)
Sounds like just another variation of the same problem to me. Use an external token for authentication, be it Apple Watch or Yubikey is an implementation detail. But I agree, supporting such third factors would be very useful.
The biggest challenge with things like this isn't using X or Y security technology for the user, but maintaining state. We have a great place to store a cryptographic secret on all recent iOS devices — if I'm not mistaken, that's all devices supported by iOS 12 now: the Secure Enclave; we don't have that same luxury on most other devices. That may change in the future though. Cheers! :)
0 -
Hey @brenty ,
Thanks for the elaborate response
We really have to disagree on this point. Certainly we'll have to concede that it is possible to use a relatively weak Master Password (10 characters is the minimum for 1Password.com accounts, and we can't stop someone from using "DonaldDuck"), but it's not something we'd ever recommend or consider to be a viable alternative
Great, I thought you had another stance. Please ignore my comment about weak master password then.
It's certainly an inventive idea, but I'm not sure that's really solution for people. If GPG and similar technologies were even remotely accessible, most people would actually be using them, and we'd all be safer for it. The reality is that just GPG is a huge pain for almost anyone, and if we can't expect people to use that outside of 1Password, we also can't really expect them to use some variation of it tacked on to 1Password either.
I certainly agree. The HMAC-SHA1 challenge-response solution is much more feasible in all aspects, and it would require zero extra effort from the user. With native Yubikey integration, 1Password could either set the 1Password secret key as the token local secret, or generate one at random. 1Password would query the user for a PIN, send it to Yubikey and use the response as the master password. Whenever the user needs to authenticate, he needs to put the Yubikey in the USB slot (or use NFC) and provide the PIN to 1Password. Please don't get caught up in my wording here, personally I would use a PIN number, but users could of course provide a longer password also.
Some things to consider
- It would require Yubikey to access 1Password on all platforms, given that the user opt for this approach.
- Backup is not a problem. The expected response should fit into a single QR code.
- The token local secret needs to be backed up also, it's a 64 byte secret so it should fit fine in a QR code
--
Jostein0 -
Great, I thought you had another stance. Please ignore my comment about weak master password then.
@jgogstad: No worries. It's definitely a dicey topic since some people want to use weak Master Passwords (or none at all :scream:), but we do want to be clear that we can't recommend doing that. What folks do in the privacy of their own homes though is up to them of course.
Please don't get caught up in my wording here, personally I would use a PIN number, but users could of course provide a longer password also.
Ah, that's fair. Thanks for clarifying. I just want to be careful not to give anyone the impression that we're endorsing weak passwords. :)
Some things to consider
It would require Yubikey to access 1Password on all platforms, given that the user opt for this approach.
Backup is not a problem. The expected response should fit into a single QR code.
The token local secret needs to be backed up also, it's a 64 byte secret so it should fit fine in a QR codeIt's gotten a lot better as far as usability, but I don't think it's really there yet for most people. Also, every day we're hearing from folks (the two I replied to just now before you, in fact) who have locked themselves out of their data. Another thing to use is also another thing to lose, so we'll tread cautiously in this area. It's good to know what you're looking for though, and perhaps we can offer more options in the future. Cheers! :)
0 -
Here's an automator workflow that implements the HMAC-SHA1 solution: https://github.com/jgogstad/yubikey-challenger-1password (it's a fork off an unmaintained implementation for 1Password 4).
I'm using it actively (as of today), it has some caveats, so it's not for everyone:
- The Yubikey iOS SDK only supports OTP, so it this solution doesn't work on iOS. I'm using FaceID to authenticate on iOS; every second week when the iOS client needs the master password input, I need to use my computer to retrieve it from the Yubikey.
The value-add of this is primarily easier use on macOS, I also now have a longer master password that I don't know. In my threat model that's good, but I understand it's not universal.
Going forward, I would love to see
- Webkit support for FIDO U2F and 1Password leveraging this instead of TOTP for 2FA. This relies on both on a missing implementation and Apple updating iOS to use it. The feature is tracked in https://bugs.webkit.org/show_bug.cgi?id=143491
- Use of "some protocol" for safely storing the master password on a password protected hardware token. HMAC-SHA1 works, I don't know enough about U2F to say how viable that is.
I understand you have some upstream dependencies here, so I'm crossing fingers and not holding my breadth🤞
0 -
Interesting. Thanks for sharing! I don't think we're in a position to do anything more in this area right now, but it's something we're following with interest. :)
0
