Feature Request: Enable login-specific dual authentication or master password re-prompt

JFergerstrom

Hello. I cannot find the feature that allows me to enable dual authentication or a re-prompt of a master password for specific logins (like banking). I had this feature in Dashlane, and it was easy to find in my testing of LassPass. While I like 1Password better than the rest, this is an important feature to me when using my computer. Phone authenticates with biometrics each time, which is good, but maybe a dual-auth on mobile or computer could require, on a login-by-login basis, to enter a pin or the first or last ## characters of your master password.

---

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

Jack.P_1P

Hi @JFergerstrom:

Thanks for that bit of feedback. I've added your voice to the tracker for this suggestion.

Would you mind elaborating a bit more on your intended use case for this? It helps as we keep track of suggestions to understand the "why" behind a request :smile:

JFergerstrom

Hello. Thank you. I used this a lot in Dashlane (used it for 2 years before they changed their plans and eliminated a different feature that I couldn't live without). I enabled "re-prompt master password" on all of my banking logins and anything else that I felt was sensitive enough to require immediate reauthorization to use, see/Reveal, or copy in the app/extension. For the sake of this conversation, let's call it "double-verification." (DV).

Double verification could be an option of (user choice):

• re-prompt of the master password,
• dual-authentication through a mobile app (like authy),
• an additional "secret" PIN that you preset in settings (visible and changeable only with re-prompt of master password)
• or part of your master password (faster than the full password), first 4 of the master, or last 4 of the master, etc.

As an example, 1Password automatically generates a login for your 1Password Master Password and Secret Key. I think that entry should require double verification to even Reveal, copy, or use sensitive content from that Login. It could apply to any Item Type, for that matter). The Login-specific control would allow me an extra layer on my banking/Paypal, but it isn't something I'd need on my Reddit login.

To build on this, a separate setting would control how long the "double-verification" lasts; be it 15, 30, 45, or 60 seconds. Inside that window, if you needed to use, see, or copy a DV-protected password again, you could do that without DV being needed. Outside that 15-60 second window, DV would re-prompt you in the field pop-up, browser extension, etc., should you need to use, copy, or reveal that password again.

In the past, even though I was logged in to the computer and Dashlane, my banking Logins remained protected by 1 final layer of authentication should I step away from my computer for a couple minutes (at home or in the workplace) or someone steals my phone right from my hands or right off my table in the coffeeshop (worst case, of course). There are certainly other best practices we could deploy to mitigate these risks (locking computer when you step away), but the automation of this feature protects us in those moments of forgetfulness.

I hope this helps. Thanks for considering!

jpgoldberg

These are excellent questions @JFergerstrom, and ones that we should have a pre-baked answer for, as forms of it come up from time to time.

You are certainly correct that good biometrics or convenience unlock mechanisms encourage stronger account passwords and shorter auto-lock periods. And this is definitely something we need to take into account in tuning how 1Password locking and unlocking should work. Furthermore, the more one has to type in a 1Password account password, the more opportunity that gives to shoulder surfers to observe you typing in your password. These, of course, need to be balanced against the other threats. So you have hit upon a very subtle set of questions,

Repeated verification (DV) isn't what it looks like

It turns out that the typical implementation of what you are calling double verification (DV) offers far less security than they superficially appear to. And by doing so, they can actually be harmful for security. There is a distinction between locking something only in the user-interface (so presenting the data as locked) and actual locking (which means really needed the account password to derive the keys needed to decrypt your data). To the extent possible, we want to present to the user a good representation of locking. I will get to reasons for that below.

An attacker who can sit down and work on your computer when 1Password is unlocked can get at its data irrespective of whether the UI presents it as locked. Sure, they need to be a bit more sophisticated than a casual attacker, but 1Password security design is aimed to defend against the sophisticated attacker instead of just misleading the user and the casual attacker. Quite simply, there are ways to by-pass a UI locking that simply aren't available for real locking.

You might be thinking that even if DV doesn't offer as much security as first appears it still offers something, and more security is always better. The problem is that the misleading security properties of DV encourage people to behave insecurely. That is, it encourages people to leave their computers and password managers unlocked in situations where they really ought to be locked.

One of the things that lead to misunderstanding of the security properties of things like this is that most users are not going to be aware of the distinction between decryption and authentication. Understanding that distinction should not be a requirement for using a password manager safely, but that distinction plays a large role in our design. When you unlock 1Password, your account password is used as a deception decryption password, but for UI unlocking it would be used as an authentication password. Both uses appear the same to the user, but they have very different security properties. So if we were to do something like this again, we would make the local authentication one be a PIN this time around as well.

I should note that I am not accusing Dashlane of engaging in dangerous "security theater" as I don't know how they implement the behavior you describe. It isn't impossible to do that without UI unlock, and I have not studied what they are doing.

Security levels

Long ago, we actually attempted different approaches to this. One was to have a quick UI unlock, and the other was to allow people to specify a different security levels for different items, with the lower level requiring a different unlock password than the higher level one. And the auto locking behavior also differed by level. We did exposed this functionality specifically on mobile before TouchID and other reasonably secure convenience unlocking became available. This was because I good password is much harder to type on mobile than on full keyboards.

Both of those attempts were a nightmare in terms of usability. Many users ended up putting everything at the lower level, and so their most important secrets were protected merely with a PIN. There were other usability problems that made this far more trouble than it was worth in addition to encouraging unsafe behavior. Perhaps such things aren't inevitable, but we would be wary of reintroducing such measures. UI unlock might be acceptable on mobile, as it is a bit harder to by-pass that on mobile OSes than on laptops/desktops. But mobile devices offer app developers a more secure local authentication mechanism.

Mitigations

What you should be doing is making use of your operating system's Lock Screen if you are going to leave your computer unattended. Because of how that it integrated into the operating system, it is substantially stronger than a mere UI locking in a single application. It also prevents someone from installing something malicious on your computer. Remember, that someone who has 30 seconds at your logged in and unlocked desktop/laptop can do a great deal to undermine your security, including that of your password manager. So at the very least, you should have your desktop lock when you close the lid of a laptop.

I know that this is not the answer you were hoping for, but I hope you recognize that it is the kind of thing we have considered deeply.

[Deleted User]

@jpgoldberg A great post as always. Did you mean to say the following in paragraph 6:

When you unlock 1Password, your account password is used as a deception password, but for UI unlocking it would be used as an authentication password.

Did you mean decryption rather than deception?

jpgoldberg

Did you mean decryption rather than deception?

Ha. Yes. Yes, I did.

jpgoldberg

Following on about my typo and autocorrect mishap, there have been other discussions of "deception" passwords. That is, a password that would unlock fake data in an attempt to satisfy those could compel you to unlock 1Password in their presence.

The difficulty with such schemes is that they only defend against a highly implausible attacker. The attacker must have the capacity to compel you to unlock 1Password while at the same time not have the power to retaliate once they discover the deception. Or they must be incapable of discovering the deception.

Note that even if you can fool the attacker at the time that they compel you to unlock, they are very likely to detect the deception at some later time. They are then unlikely to say, "Oh, nice trick. Very clever of you. I guess we lost."

BlueHatHkr

This kind of immediate, thoughtful response from the developers makes me even more confident in my decision to switch from Lastpass to 1Password. I was going to ask for the same thing, but just wow.

ag_ana

Thank you for the kind words @BlueHatHkr :)

ttod

to be honest, even if user wants to have 'UI-lock', you should allow them to have that option, because there are cases when 'poeple have some guests at home (which are not sophisticated hackers) so even some 'UI Lock' feature might be useful in specific cases and have valid use. by defualt you can disable that, but still, if user wants it consiously, you should have option (with warning msg though) for it.
actually, not giving a capability for customization to user (under advanced-settings) is against my philosophical principles of software-engineering, which I highly distract. you don't always know better than me what is good for me. moreover, your customers are not all noobs and some of them are professional and know their job. so, give us the features we request (be it under 'advanced-settings').

Ben

Hey @ttod,

I can appreciate that perspective, but this isn't something that's on our radar; sorry. We've got a lot of cool things planned, and this didn't fit, I'm afraid. You might consider locking your screen (WinKey+L on Windows, or  > Lock Screen on macOS), if you find yourself in the situation you outlined.

Ben

ttod

yes I know already long ago that user's requests are not in your plans (rejecting my multiple & different FRs, which were obviously useful for users like me) and 1P doesn't care of user-requests. thanks for being outright . I regret switching form LP, it had all those features I am missing. 'those cool things' you refer (auto-login with different profiles or etc) is what I totally/never cared of and never need.

Ben

Sorry to hear that, @ttod. Certainly we do listen to user feedback, which is where the idea for e.g. Masked Emails came from. That said, we receive a ton of suggestions, and we'll only ever be able to implement a fraction of them. I do apologize that none of the ones you've brought to the table have been implemented, but we are listening and do roll out new features based on requests when we can.

Ben