Revisiting subsequent unlock of 1Password using hardware tokens or biometrics
Hello,
I have read all the past threads I could find regarding unlocking 1Password using a hardware token. Based on those past discussions it seems unlikely that 1Password will implement the requested feature. I would like to revisit this feature request by offering what I hope is a sound security benefit of the feature request. First, I'll restate and extend the feature request.
Feature Request(s)
- Require the user to decrypt their 1Password vaults using their master password once per session. The session length could be configurable to something like "once a day". Ideally, for 1Password for Business, the policy could be set centrally and enforced on all clients attached to the account.
- Within the duration of the session, the vaults will quickly lock after use (again the lock threshold could be configured via a central policy). A default of 2 minutes would be appropriate.
- Within the duration of the session, the vault could be unlocked by touching a Yubikey or similar hardware token or biometric device
- This behaviour could be enforced on all devices (WinPC, Mac, mobile devices) via central policy
Threat Model
We often hear that convenience and security are at odds with each other. However, I think there are situations in which improving convenience can actually enhance security. An ideal password manager would spend the vast majority of the time in a locked/encrypted state, so that there would only be very short windows of time where it would be possible to extract plain text credentials or other secret data. This implies a very short auto-lock interval. However, it is incredibly annoying to have to type a long master password just about every time I want to access a specific credential. So, what wins out, security or convenience? In my case I put up with the inconvenience, but I know that the staff I support will not put up with the inconvenience and they will set much longer intervals before auto-lock kicks in and they will do worse things than this. I want to protect staff from themselves, because I know they will get up and walk off without locking their PC (PC lock timer is longer than I would like to see for 1Password); I know they will leave passwords visible, using the reveal feature, on their screen; I know they will use 1Password to type passwords, in plain text, into applications like Notepad, OneNote, etc, just so that they don't have to keep unlocking 1Password; I know they'll take pictures of passwords and store them on their phone (which is synced with a personal cloud account), etc.
If 1Password can be made even more convenient, such that it's easier to just use native functionality vs all the lazy workarounds, then our security posture will be stronger. I think that using a security token, that just requires a touch to unlock, would be fantastic. The additional centralized policy controls would help to establish a consistent baseline for all users and then the rest of the solution involves training, coaching and managerial intervention when policies are not being followed.
Please understand that I agree there is sound technical logic in the current 1Password design that is based around a master password and secret key for unlocking/decrypting password vaults, so I'm not suggesting the use of a Yubikey for technically enhancing encryption strength; rather I'm suggesting that there is a very human psychological component that seems to be overlooked in the current design. I think this proposed feature request could mitigate more of the human frailty involved in password management.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
No one from 1Password has commented on this feature request, so I'm thinking I must have posted it in the wrong place. Where should I send feature requests?
0 -
Hi @masons!
Thank you for your patience here! The team is back from a long weekend so our response times slowed down a little bit. The forum is a good place to send feature requests though, but I will make sure to send this discussion directly to our Business team so they can get back to you directly :+1: :)
0 -
Hi @mansons!
I just wanted to let you know that I've passed this over to the rest of our team for further review, and while I can't provide any guarantees or a timeframe, they did let me know that is something that's being researched. :+1:
Thanks for taking the time to share this! We take feedback from our customers really seriously, so it means a lot for you to take the time to think through this in great detail. :smile:
0 -
@ag_joshua , thanks for letting me know this request is being researched. If any of your team would like to discuss this request in more detail, I'd be happy to get on a call.
0 -
@masons - thanks for the excellent, well-thought-out question and feature request. There are a fair number of moving parts to that one, but let me try to summarize our position and what may be possible in the future. First, however, let me wholeheartedly agree with your point regarding the intersection of security and usability/convenience. We're big fans and practitioners of the concept that good security should be for everyone, not just the technically-inclined or those willing to subject themselves to unusual steps/rigor each time they use their devices, in the name of security. It's why we don't mandate that users unlock with their Master Password every time they use 1Password. Instead, we offer biometry and lately, Apple Watch unlock for those on the Apple side of things.
But you'll notice that we didn't offer Apple Watch unlock until very recently, and that's because prior to pretty recently, it wasn't possible to use Apple Watch to unlock in a way that met our security standards. That's the same reason that we put a lower-limit of ten characters for Master Passwords in 1password.com accounts -- because although it is easier to both remember and to type a Master Password that's only one or two characters, using that short a Master Password is never secure, and 1Password is fundamentally a security application. It's fine if someone decides security isn't their priority...but we're not going to give people the option to use our app in a way that is insecure, because security is what we do, what we provide.
What we always strive to do is build 1Password so that doing the secure thing is also a simple (or at least not overly complicated) thing, whenever we can. The worst security in the world is a system that's so secure but so complicated or difficult/annoying to use that people don't use it but instead figure out ways around the "roadblock."
All of your suggestions are things that we're considering as possibilities. We'd love to be able to find a way to offer more unlock options for 1Password, and it may be the case that we'll be able to in the not-too-distant future. But in order for any of this to progress beyond the drawing board stage, it has to first meet our standards for security not just from a technical standpoint, but from a "don't allow users to set things in an insecure way" standpoint. It also has to respect users' privacy as well. I mention that latter point because at present both enterprise and individual/private users all utilize the same 1Password applications on their devices, and as such there are few mechanisms for 1Password account Admins or Owners to control behavior of individual apps. It's also the case that many users have more than just their "work" account signed into their 1Password apps. Our current security model (and for that matter, name - 1Password) works on the idea that you only need one password to unlock everything. If you have only a single 1Password account, that's easy. If you have multiple accounts, or standalone vaults as well, not so much. None of these are obvious show-stoppers at present, but all would require us to make substantial changes from how 1Password works today. I've logged a link to this post in the appropriate ongoing issues discussing future possibilities/plans, but there's nothing really to share at this point. Thank you once again, however, for taking the time to think these things through as thoroughly and present them as clearly as you have; we truly appreciate it.
--
Lars Olsson
Security Team | https://1password.com/security/0 -
Hi @Lars , thanks for taking the time to write such a thorough response. I have a few comments on things you've shared.
We'd love to be able to find a way to offer more unlock options for 1Password, and it may be the case that we'll be able to in the not-too-distant future.
I'm encouraged to hear that you'd love to find more ways to unlock 1Password and that this might happen in the "not-too-distant future"!
I'm not a software engineer and definitely not a security software engineer, so this suggestion may be a bit naive. In my feature request, I've suggested that there be a way to use a hardware token (Yubikey in my case) or biometric to perform subsequent unlocks of the 1Password vaults, after the master password has been entered once. Given the master password has to be present in memory, in clear text, for the unlock to happen; what about using the public key from an asymmetric key pair, to encrypt the master password in memory. The private key would be stored on the Yubikey and would of course be required to decrypt the master password, so that it could again be used to decrypt the vault.
With this approach, theft of the Yubikey would not allow an attacker to gain access to a "fully locked" 1Password vault (ie - a vault that has either not been initially unlocked or one who's session has expired and now requires re-entry of the master password), because they would still require the master password (and in the case of 1Password accounts, they would also need the secret key). I assume this approach would also make it easier to add additional unlock options that you feel are reasonably capable of protecting a secret key.
But in order for any of this to progress beyond the drawing board stage, it has to first meet our standards for security not just from a technical standpoint, but from a "don't allow users to set things in an insecure way" standpoint
As my original feature request highlights, preventing users from doing insecure things can be a challenge. For example, adding the Yubikey for subsequent unlocking, doesn't actually mitigate the issue of a user getting up from their PC, leaving the Yubikey plugged in and walking away without locking their screen. That would require a different mitigation, unrelated to 1Password (I'm looking at you Yubikey Bio).
I think you're correct that in some cases it is possible to "[not] allow users to set things in an insecure way". However, in many cases, it's not possible to force users to do the right thing, because they have options available to them that are not under the control of your application/infrastructure. In these cases, I think it's necessary to make doing the right thing almost as easy/convenient as doing the wrong thing. If you can accomplish this, then security training can work. However, if doing the right thing is annoying/complicated/difficult, then no amount of security training is going to change user behaviour.
I mention that latter point because at present both enterprise and individual/private users all utilize the same 1Password applications on their devices, and as such there are few mechanisms for 1Password account Admins or Owners to control behavior of individual apps. It's also the case that many users have more than just their "work" account signed into their 1Password apps. Our current security model (and for that matter, name - 1Password) works on the idea that you only need one password to unlock everything. If you have only a single 1Password account, that's easy. If you have multiple accounts, or standalone vaults as well, not so much.
In a BYOD scenario, I agree that it's difficult to find the balance between exerting a corporate security policy and not imposing on a user's choice in how they use their own personal property. However, in a scenario where the 1Password app is installed on a business owned and managed device, I think it's perfectly acceptable to enforce policy. I'm actually a bit unnerved about the fact that a business user can install the 1Password app on their home PC and and gain access to business vaults and I can't prevent that. Coming back to what you said about, "[not] allow users to set things in an insecure way", I think that there are insufficient controls, within 1Password for Business, to prevent users from creating insecure configurations. That being said, I still think it's the best choice for small businesses, yet I do want to advocate for additional business oriented features.
I'd like to see the ability to strongly manage on which devices business vaults can be accessed. If a business wants to also allow users to access their personal vaults on a business device, it should be possible to set their default vault to a business vault, so that new business logins are not accidentally saved to a personal account. Allowing both business and personal accounts to be unlocked together, does mean that the business has to trust the employee to not copy data between the two accounts, which for most small businesses will be an acceptable situation. But I don't think it's acceptable to also have to trust an employee's home computer onto which they could install 1Password and login to their business account. In that situation, you're now no longer just trusting your employee, but perhaps everyone else in their home and their ability to securely maintain their PC and home network - that's not a realistic expectation.
0 -
Thanks @masons. I think you've put out some great thoughts there. There are some options that exist that you may not be aware of. Specifically, if your corporate locations have static IPs, or you have a corporate VPN that you could route 1Password traffic through, it may be possible to configure 1Password to only allow connections to your account from those locations/VPN:
Create firewall rules in 1Password Business
There are other options that 1Password Business administrators have at their disposal for enforcing policy as well:
About 1Password Advanced Protection
That said, this is an area we would like to expand. :+1:
Ben
0 -
@Ben , I am aware of all these controls you’ve listed or linked to, but for some reason I had always assumed they only applied to accessing the web interface for 1Password. However, assuming they also apply to the synchronization service, I can see how these controls could be effective in preventing a user from setting up their business account on their home PC. Is this correct?
0 -
That's correct, the protections apply to the client apps as well, with this caveat:
If a team member has already signed in to a 1Password app on their device, they’ll have access to their data even when they’re blocked by firewall rules. However, they won’t have access to any new changes until they’re in an allowed location.
The 1Password apps keep a local cache of data, and the firewall rules would not prevent someone from unlocking and accessing that local cache. For example if we set up a rule that says only people in Canada can access the account, and then an employee leaves Canada and travels to the US... they'll still be able to access everything they could while in Canada, but they won't get any updates while in the US. If that rule existed before the employee traveled, and they hadn't yet added their account to their devices, they wouldn't be able to do so once in the US. If you wanted to allow some people a way around this (e.g. perhaps your executive team needs access regardless of their location) you could set up a VPN on your corporate network in Canada. The VPN would need to be configured to route traffic destined for 1Password through it. Once connected to that VPN it would be possible to get the latest changes even while physically elsewhere.
Ben
0 -
You're welcome. :) We'll continue looking at what you've suggested here but in the meantime I hope that helps.
Ben
0 -
@masons
Since you're using a Yubikey, why not just program a (complex) static password and use that password prepended with a password you can easily type as your master password? You can then just press the Yubikey to spit out the rest of the master password.0 -
Thanks @1pwuser31547, that seems like a reasonable suggestion. However, I'm tentative to adopt this approach as I'm pretty sure I read somewhere, either in this forum or 1Password documentation, that 1Password specifically states they don't recommend using a stored password in a hardware token to unlock. I don't remember what the specific concerns were though...
The combination of a short password (perhaps like a 6 digit PIN) concatenated to a long random password stored on a Yubikey, does seem like it would be roughly analogous to 2FA with something you have (Yubikey) and something you know (PIN). With the added security of the 1Password secret key, this does seem like a reasonably secure and more convenient means to unlock a 1Password vault. The potential downside would be that loss of the Yubikey would lock you out of your 1Password account and all vaults. That could be mitigated by storing a paper version of the emergency kit in a secure, yet accessible, location.
@Ben or someone else at 1Password, does this seem like a reasonable workaround to simplify the unlocking process (until you officially support alternative unlock methods)?
0 -
@masons,
That’s what I do and I’ve never had any issues.
(I actually use a different security key- Onlykey since it is PIN protected itself). These keys simply simulate the keyboard.My master password is 256 bit, totally overkill but hey, if I don’t have to type it, why not?
Yes, definitely have paper back ups stored in multiple secure places.
Your master password alone protects your data locally. So by doing this you’ve made your data on your devices much more secure.
The secret key/ MP combo is used for protecting your data on their servers so making your MP super complex won’t add any more practical protection against that threat since the secret key is already 128 bit.
The only inconvenience is using the security key on mobile (iOS for me) devices. You can still do so with a USB lightning adapter.
0 -
@masons - you're certainly welcome to try a setup such as the one 1pwuser31547 employs; clearly, it works for him, and that's a big part of any software: figuring out a workflow that works for YOU. Having said that, I do recall you saying in your initial post that much of your considerations were for staff you support, who you said wouldn't be bothered with having to type out a long Master Password regularly. Given the other methods of quick-unlock already available to them (and you), such as Apple Watch unlock, Touch ID and Face ID, it might be worth asking yourself whether buying them all easily lost/breakable security keys and making them remember to leave paper backup copies of those in multiple places for the inevitable times that those keys are lost/damaged/stolen is really a savings of time or effort for either you or them.
If it is, then sure, it's possible to do what 1pwuser31547 suggests. That's a usability question I can't answer for you, let alone the various staff you support. But those very considerations are one of the reasons we haven't added this method to the suggestions we regularly offer to users: because it requires the purchase and programming (not to mention proper use) of a separate piece of hardware, just to access one's own data. So while this isn't a solution we support, it's definitely possible. Meanwhile, we'll keep looking for ways we can improve 1Password in both the usability and security departments, because this stuff is our passion. :) Thanks for adding to the conversation, and for being a 1Password user.
0 -
@Lars - unfortunately none of the other quick-unlock methods are available to us. I initially began using 1Password several years ago, because I was primarily working on Macs and 1Password treated Macs as a first class citizen and Windows was the afterthought. I'm now in a business environment that is entirely Windows PC based. So we don't have Apple TouchID/FaceID and we don't have every person in the office (actually no one) wearing an Apple watch. So our unlock options are limited exclusively to entering the master password, which is why I started this thread. The workaround that @1pwuser31547 suggested is not easy to administer across a large number of accounts, but I would see it as a workaround until 1Password implements other unlock methods. I know you haven't promised that new unlock methods are anything more than drawing board items right now, but I was hopeful that there was some genuine interest in supporting things such as hardware tokens.
If you have better options available for quick-unlock on Windows PCs, I'm very interested to hear your thoughts.
0 -
@masons - I would be remiss not to mention Windows Hello unlock, in that case. Hello, like all other forms of quick unlock, comes with its owns set of considerations, but it is an option for Windows-based users. As always, unlocking with a strong, unique Master Password that only you know remains the most secure form of unlock.
0 -
@Lars - thank you, I did not know that 1Password supports unlock with Windows Hello. That's encouraging news. Before I start down the long path of building up all the infrastructure to support Windows Hello for Business (CA, GPOs, etc), can you please confirm that Windows Hello for Business will work for quick unlock for 1Password Business?
0 -
It's handled entirely by the OS. As long as you have Windows configured correctly to allow for the use of Windows Hello, it will work with 1Password. All we're doing is calling Windows APIs for that. It's entirely transparent to 1Password.
0 -
Thanks @brenty. Given there are multiple supported unlock methods for Windows Hello (including Yubikey acting as a smartcard and PIN unlock using a key stored in TPM), this seems like the best path to take for answering my main feature request (quick-unlock using a strong hardware factor). I've been thinking that implementing Windows Hello for Business would be a good step for us to take, so I'm glad to hear that our 1Password deployment should benefit from that work as well.
As for the other parts of my feature request, if we allow people to login using a Yubikey and pin (with Windows Hello), then we could probably get away with having shorter inactivity timeouts for PC screens to lock (enforced via GPO) and we could set the 1Password lock time fairly short, without unduly irritating staff. And Ben's suggestion of using the IP based restriction for access to the sync service (with the help of our VPN), would help with keeping the business account from being used on personal devices.
It is a lot of infrastructure to build out and to depend on, so I hope it's worth it.
Thanks again to @Lars for the time he put into answering my questions.
0 -
Glad that helps. :) Unfortunately I am not sure there's a way to both allow Windows Hello to be used and also not have it fall back on an insecure "PIN", but I would be glad to be wrong about that.
0
