Storing the Secret Key on a hardware token (YubiKey)
Never storing/saving the Secret Key on computers would enhance security against a few attack methods, but is currently not an option because of the inconvenience of remembering and/or entering the 34 character key. However, some hardware tokens (such as nearly every YubiKey model) support saving a static password in one of the configuration slots, which could be the 1Password Secret Key. Inserting and tapping the button on a YubiKey is a very minor inconvenience compared to the security gain of not having the Secret Key be stored anywhere that is targetable. It's also easy to program an additional YubiKey as a backup, and storing that in another location (such as a personal safe or bank safe deposit box).
Would 1Password consider this as an advanced option for those who would use it?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@herrchin: Please forgive me. I'm not sure what you're asking here. It sounds like you're aware that you can store the Secret Key as a static password on a hardware token. You can certainly do that if you wish, and it sounds like you've already got a backup plan in mind even. I don't think it requires any "support" from us. Did you mean something else? :)
0 -
Yes, having an option to never have the Secret Key be stored by 1Password, so the user would be required to provide it every time. I realize this is in slight conflict with usability goals, but I thought the hardware token was a significant mitigating factor to that.
0 -
@herrchin: Ah. I see. You can do that in the 1Password.com web interface. Just check the "public/shared computer" option. The point of having a native 1Password app on a device though is persistence: the user doesn't have to sign in from scratch, and encrypted data is cached so that it doesn't need to be downloaded on each use, and is available offline.
0 -
Couldn't the native apps support an option the same underlying functionality as "public/shared" computer though, so that the entirety of the encryption key must be supplied every time? (however the user chose to do it, and hopefully they're not so crazy as to type the whole thing, and instead use something like a Yubikey for the Secret Key portion)
Since ultimately the encryption key is the golden piece of information, having the Secret Key portion of it be offline except for the very instant it is being used would be a small step up.
It could also increase "practical" security in some convenience cases, such as when a fingerprint is used on a mobile phone to unlock. If one had to supply the fingerprint (as the substitute for the Master Password) and wave their NFC-enabled token over the reader (to supply the Secret Key), it's still very fast and convenient, but is now immune to fingerprint attacks (against a stolen/lost phone, or even a phone temporarily left unattended).
The traveler could also send their secret key (on paper, or on a Yubikey, or via a proxy such as a co-worker or friend) to their destination, and not need to purge the vaults from their device. They'd be wholly incapable of decrypting their vault until they re-acquired their secret key. Different from Travel Mode in that you could take your vault with you on your device, if you don't trust your ability to re-download your vault from (either due to government control of Internet access, or even lack of Internet access).
0 -
Couldn't the native apps support an option the same underlying functionality as "public/shared" computer though
The short answer is "probably not." We've gone into the details on why in a few places, including:
- Duo 2 Factor Authentication Security — 1Password Forum
- Multi-Factor Authentication?? Please??? — 1Password Forum
- 2FA Authenticator revoking devices (vs Authy) — 1Password Forum
And other places (search for "offline access" or "cache" for more threads on the subject).
Ben
0 -
@herrchin: All of that sounds like a tremendous nuisance. Almost no one would be willing to do that, and given that and the fact that no one else has requested this it is highly unlikely we'd make such a change to how 1Password fundamentally works. The discussions Ben linked to go more in depth on the usability side of things.
I really appreciate you taking the time to elaborate though, as I think I have a better understanding of where this is coming from. Clearly you're thinking about this more (entirely?) from a security angle, but I believe that you're misunderstanding the function of the Secret Key. It exists solely to protect 1Password users from attacks on us. Because the Secret Key is also used to encrypt the data, along with the Master Password, before it is transmitted to us and stored on our server, an attacker who breaks in and steals the encrypted data from us will not be able to perform a brute force attack against the user's Master Password. The Secret Key doesn't really offer a benefit if the attacker has direct access to your devices -- and, by extension, you; they can get what they want much more easily that way. I hope that helps clarify.
0 -
@brenty Yes, I'm thinking primarily about security scenarios. Wherever the Secret Key exists at rest, brute-forcing the Master Password is now possible. This includes scenarios where the Secret Key (and vault) has been stolen, such as if malware was temporarily present on a device, and the data was exfiltrated. It doesn't even necessarily need to be a sophisticated attack; it just needs to be something able to copy files from disk, whether locally, or even remotely (EternalBlue exploit before the patch was available, other OS weaknesses, etc.).
By never having the Secret Key available at rest, I would be reducing my attack surface to elements where they're intercepting the inputs or the combined encryption key from memory. Because the 1Password database contains such a wealth of information, I don't necessarily think reducing the attack surface in this way is out there in the realm of "effort without practical benefit." Where you identified that the Secret Key helps protect 1Password (the company), the same protection can also extend to the end-user.
(I realize this may seem like a significant ask, but as an advanced option, I would hope it wouldn't be that complex to implement, for the rare persons who would prefer a tiny bit of extra work for added security. I thank you for the consideration and discussion so far!)
0 -
Yes, I'm thinking primarily about security scenarios. Wherever the Secret Key exists at rest, brute-forcing the Master Password is now possible.
@herrchin: Possible, yes. But not feasible, if you're using a long, strong unique Master Password. The existence of the Secret Key is not an invitation to use a weak one. ;)
This includes scenarios where the Secret Key (and vault) has been stolen, such as if malware was temporarily present on a device, and the data was exfiltrated. It doesn't even necessarily need to be a sophisticated attack; it just needs to be something able to copy files from disk, whether locally, or even remotely (EternalBlue exploit before the patch was available, other OS weaknesses, etc.).
Okay...but if malware is able to capture your Secret Key, why not the Master Password? Actually, why bother to capture either, when it can just let you decrypt your data and then collect it.
By never having the Secret Key available at rest, I would be reducing my attack surface to elements where they're intercepting the inputs or the combined encryption key from memory. Because the 1Password database contains such a wealth of information, I don't necessarily think reducing the attack surface in this way is out there in the realm of "effort without practical benefit." Where you identified that the Secret Key helps protect 1Password (the company), the same protection can also extend to the end-user.
I don't think you're following your hypothetical to its logical conclusion, which is that all bets are off if your machine is compromised.
(I realize this may seem like a significant ask, but as an advanced option, I would hope it wouldn't be that complex to implement, for the rare persons who would prefer a tiny bit of extra work for added security. I thank you for the consideration and discussion so far!)
Likewise, thanks for the discussion! It's an interesting thought exercise. I guess what I'm unclear on is what security benefit you anticipate receiving for the hassle on your end and added development, testing, and support on ours for the change you're requesting. Put another way, in order for an attacker to benefit from the Secret Key being "at rest" on your system, they would need to have full access to it; and if that is the case, why do they need to brute force your Master Password, when they can just access your data as you do? The change you're asking us to make doesn't protect you in this scenario: the attacker still has a foothold in your system, and can still get your data unless you literally never use 1Password there -- in which case, it doesn't matter, since you would not need to sign into your account on it at all. Please clarify.
0 -
I don't disagree with the philosophy that once there's a compromise, you must presume they can do anything. I also deal regularly with low-effort, drive-by security incidents. They don't hang around, they might copy data, and frequently drop ransomware on the way out the door. They might manage to get access to an account with AD domain admin privileges, and snoop across the network without actually attacking destination machines. I'm considering primarily not from the angle of theoretical security, but more what we see in practice. Just like basic locks on the door keep out the lazy criminals. How TOTP primarily helps the disturbingly large percentage of people who have bad passwords. If the Secret Key is not sitting on disk, it can't be stolen.
This does lead to the counter-argument where I've sunk most of my own boats. The type of person who would inconvenience themselves by moving their secret key to a Yubikey is also the type of person to have an extremely strong master password, which is used nowhere else, and they're careful about where they enter it to the point of trusting minimal things to log into 1password.com. It's not likely that someone obtains my vault and secret key and will have the resources to brute force it. If they have somehow obtained my (me, the guy who would move a key to a Yubikey) master password and vault, chances are they've also captured my secret key no matter how I protected it, or they're in memory already and can see everything they want.
0 -
You're absolutely right that attacks can be one-off, "drive-by", opportunistic. I just don't think we should be counting on that, even if it may prove true in many cases. But I can certainly see your point, especially if you're speaking from experience. In that case though, even if the attacker is able to grab the Secret Key in that window of time, they still don't have the Master Password, and would also need the TOTP secret to generate the code to log in to an account with two-factor authentication enabled. So there are different aspects/layers to the security that also provide a "buffer" even in the sort of scenario you're seeing. Certainly we don't want to see anything like that in systems we're responsible for or using, but at that point the issue turns toward ensuring that the system is purged of any foothold, so it doesn't go from being a short-term illness to an ongoing infection, to use a medical metaphor.
0
