yubikey support for 2FA

Hi

Using the 2FA feature in 1password is really convenient but some argue that it's not a true second factor because with the master password (one factor) you have access to both the credentials and the TOTP codes.

It would be really cool if 1password supported retrieving the TOTP codes from a yubikey. These seems like it should be fairly simple to implement and would provide much greater security.

Is this something agilebits would consider adding?

Thanks

Comments

  • LarsLars Junior Member

    Team Member

    Hi @m4rkw -- thanks for the question! I think Yubikey support is something we can see the benefit in...but that benefit isn't as unambiguous as it might seem, for two reasons. First, there's the ongoing work in other areas that would have to be delayed or put aside if we spend development cycles working on this instead. That's not to say we aren't going to, or that this isn't valuable, just that there are always trade-offs when deciding where to place emphasis and focus in development.

    The second reason is the actual benefit of adding Yubikey (or other true 2FA) support. Our Chief Defender Against the Dark Arts, Jeff Goldberg, actually addressed this in a 2015 blog post:

    In general, there is a reason why many services that offer TOTP refer to it as “two-step verification” instead of as “second factor authentication”. The security that such sites seek to gain from this is not in the second-factorness; it is in the one-timeness. In particular, many of the sites and services that offer or require two-step verification with one time passwords are doing so because many of their users have weak or reused passwords. Although that should not apply to 1Password users, there are other benefits to one time passwords as I discussed above.

    ...

    Put simply: the device that holds your TOTP secret should never hold your password if your aim is genuine two factor security.

    Personally, I don’t think that following that practice would be worthwhile for anything but a very small number of special circumstances, in which case, you should probably be using a specialized second factor device instead of something like a phone. But not everyone shares my opinion on this, and if you have a need for true second-factor security for some particular site or service, you should take that into account before adding a TOTP secret to 1Password.

    The key bit in the above quote is that if you need TRUE 2FA, the devices that hold your password and TOTP (2FA) secret should never be the same. If one's perceived threat profile is such that you need that level of separation, adding it back into 1Password could open up single-device attack vectors that are what 2FA is explicitly designed to prevent.

    It's a matter of determining one's own threat profile; for most people in most situations, two-step verification (2SV) accomplishes what they need for additional security. For those others whose threat profile is such that they genuinely require true second-factor authentication (or those who simply desire it), well, that's a much smaller group of users, both in practice and in theory. Adding Yubikey support would indeed would indeed not only satisfy this smaller group of users but also satisfy that need. The question is: how many users would actually need this (and how many would use it) vs. the complexity it would add to 1Password's UI and operation, and what else would have to be deferred or abandoned to support this -- not to mention could it be implemented in a way that prevented single-device attack vectors? Right now, if a user's self-assessed threat profile is such that they need true 2FA, there are options to use something like Yubikey instead of 1Password's TOTP feature, which again makes this less of an urgent priority -- but we definitely do see the potential value in it.

  • What about integrating the YubiKey so that it's the 2nd factor used to login to our 1Password Accounts?

    I don't want to store the Yubikey in my 1Password, for the reasons that are already discussed. That doesn't make sense to me.

    What does make sense, though is to use the Yubikey to access my passwords so I have 2FA on the vault itself. Not only do I have to know the password, I also have to use the Yubikey to open my 1Password vault on my MAC, Windows, Android and iOS devices.

    I use Yubikey to login to banks, google, Dropbox, github, etc. using 2fa / Fido with Yubikey to accces my vault of secrets seems like a no brainer.

    LastPass, Dashlane, and others vaults support this

    Yubikey provides a cloud-based api that could be leveraged if AgileBits doesn’t want host the secrets themselves. Yubico also provides this on premise option as well, so you can wrap existing security best practices around these Yubico secrets within the boundary of the 1Password service.

    Might be harder to do this on iOS, given that Apple doesn’t provide a way to support NFC based connections with Fido keys. There isn’t a Lightning adatper that I’ve tested that would work either. The Lightning to USB-A dongle used for photo transfers might work, but again, there’s no API or method to leverage that within Apple’s security model.

    I know iOS is a major platform for AB & 1P, but there are many security conscious users who work in IT Security and other industries that would see the addition of 2FA to login to 1Password as a solid addition to the security toolbelt.

    Again, as always, thanks for listening.

    //Shawn

  • brentybrenty 1Password Alumni

    Likewise, thanks for the suggestion! Cheers! :)

  • I completely agree with @GoShawn:

    What about integrating the YubiKey so that it's the 2nd factor used to login to our 1Password Accounts?

    I don't want to store the Yubikey in my 1Password, for the reasons that are already discussed. That doesn't make sense to me.

    What does make sense, though is to use the Yubikey to access my passwords so I have 2FA on the vault itself. Not only do I have to know the password, I also have to use the Yubikey to open my 1Password vault on my MAC, Windows, Android and iOS devices.

    I use Yubikey to login to banks, google, Dropbox, github, etc. using 2fa / Fido with Yubikey to accces my vault of secrets seems like a no brainer.

    Is there anything in the works in terms of a feature that supports Yubikey 2FA for 1Password vault access?

  • brentybrenty 1Password Alumni

    @bknightly: If there was, I couldn't tell you anyway, but it's a feature we could potentially add in the future. Thanks for your interest! :)

  • If there was, I couldn't tell you anyway, but it's a feature we could potentially add in the future. Thanks for your interest! :)

    Thanks @brenty. Just trying to be the squeaky wheel, since this feature is very important to me.

    Also, I have to give you and all the other AgileBit Team Members credit for the impressive work you guys put into maintaining these forums. While the sales presentation in the 1P website is valuable, the conversations you guys manage here is what compelled me the most to pull the trigger on your product. :)

  • LarsLars Junior Member

    Team Member

    @bknightly - Thanks so much for the kind words! Brenty is off now, but I know he'll see them tomorrow morning, his time -- and it's appreciated. :)

  • edited March 2018

    I had to beg my IT dept to let me use my 1Password for personal sites which they allowed begrudgingly. They have a love of this Yubikey thing so any integration would be nice. :+1:

  • LarsLars Junior Member

    Team Member

    @ryangallagher - The main issue with Yubikey is that it fits a niche and fills a need we don't really have. Namely, authentication. Because 1Password is encryption-based (not authentication-based) at its core, the benefits of a hardware token like a Yubikey are negligible to us. We do use authentication for the administration of our 1password.com services (access and admin functions), but not for encrypting your data.

    If you're referring to using a Yubikey as the second factor of authentication to sites you have saved in 1Password, you can still do that - provided the service or site in question supports Yubikey.

  • Hello Lars,
    One of the reasons we are interested in using a device like a YubiKey is to protect against keyloggers, or similar malware that also hunts for clipboard data, local files, memory data, and discovers the master password. Once discovered, could this not be used to decrypt our data and discover all of the keys to the kingdom (everything managed by 1password)? My understanding is that using SMS for 2FA is vulnerable, and using "something you have" in the form of a device like a YubiKey, NitroKey, etc. is preferred by a good number of security people.
    I can appreciate the concept that 1password's data needs to be decrypted by the master password, rather than the user being authenticated by the master password, so that they are able to access the data, and if you'd rather call it 2FE for two-factor encryption, perhaps that is a helpful way to discuss the concern. I would really prefer MFE, or multi-factor encryption because I would like to register two key devices to go along with my password, with either device being sufficient to decrypt. That way, one key goes into the safe and the other gets used. If the key in use gets lost, the key in the safe is used to register a new key.
    Also, if I understand correctly, DashLane, LastPass and Keeper all support YubiKeys.
    thanks!
    Bill

  • LarsLars Junior Member

    Team Member

    @Billl

    One of the reasons we are interested in using a device like a YubiKey is to protect against keyloggers, or similar malware that also hunts for clipboard data, local files, memory data, and discovers the master password.

    In our local apps, 2FA isn't necessary because 1Password's security there doesn't depend on an authentication system. 1Password has been offering protection against keyloggers for quite some time - to the extent it's possible. But as our Chief Defender Against the Dark Arts, Jeff Goldberg, says at the very top of that blog post:

    Once an attacker has broken into your computer [and obtained root privileges], it is no longer your computer.

    In other words, the kind of malware that could embed itself deeply enough within your system to obtain privileges that could bypass things like Secure Input (on macOS) or its analogues on Windows could also likely just read data from memory on your computer after SuperSecureString has been received from ExternalSuperSecureComponent.

    ...if you'd rather call it 2FE for two-factor encryption, perhaps that is a helpful way to discuss the concern.

    It's not that I'd like to play semantic games with you, there's a real-world difference between authentication and encryption.

    I would really prefer MFE, or multi-factor encryption because I would like to register two key devices to go along with my password, with either device being sufficient to decrypt.

    There would be two ways to go about this - the most likely one would be that the other factor provided by the external hardware token is a construct of 1Password's UI which must be combined with the "thing you know" (your Master Password) in order to derive the actual AES256 key which decrypts your data. In other words: two secrets which, combined, derive the actual encryption key. In this case, we already accomplish this for 1password.com accounts by means of the 2SKD (2-Secret Key Derivation) provided by your Secret Key.

    In the other instance, you'd be attempting actual key-splitting, where the 2nd factor provided by the external hardware token could actually be part of the encryption key itself (not just the secret used to derive it). If that's what you're referring to - actually splitting your AES256 key and putting some portion of that onto two different Yubikeys - I have to ask why you would want to be widening your attack surface by providing multiple ways into your data at the same time that you'd be creating a legitimate risk of making your data completely inaccessible if those keys were lost or damaged.

    In my first reply in this thread, I said "Yubikey support is something we can see the benefit in," but let me clarify that a bit: we see its value in certain (non-1Password) applications; we're significantly less convinced of its usefulness for 1Password itself. We'll continue evaluating -- because the security landscape is always shifting -- but at this point, nothing is in the works to add Yubikey support for unlocking 1Password.

  • brentybrenty 1Password Alumni

    One of the reasons we are interested in using a device like a YubiKey is to protect against keyloggers, or similar malware that also hunts for clipboard data, local files, memory data, and discovers the master password.

    @Billl: That won't protect you against key loggers. At that point the attacker might as well just collect data as you access it or enter it.

    Once discovered, could this not be used to decrypt our data and discover all of the keys to the kingdom (everything managed by 1password)?

    It almost certainly could. Why bother trying to collect your Master Password in that case, if they are in control of your machine and can monitor and control everything there? And, of course, they could intercept the code then too, and prevent you from using it so they can themselves.

    More importantly, your data cannot be encrypted with a shifting code, or you wouldn't be able to decrypt it later. That's an authentication function, and wouldn't protect you from an offline attack on the data itself. That's why 1Password's security is built on encryption and not mere authentication. It needs to withstand even direct attack, not just hope that no one can pose as you to get it in the first place.

    My understanding is that using SMS for 2FA is vulnerable, and using "something you have" in the form of a device like a YubiKey, NitroKey, etc. is preferred by a good number of security people.

    SMS is not a secure channel...but at the same time I think it's worth pointing out that SMS is not vulnerable to keyloggers or other computer malware. That's not to say you should use that, only to illustrate that all of these have their strengths and weaknesses, as well as use cases that offer a benefit and those are are irrelevant depending on the context.

    I can appreciate the concept that 1password's data needs to be decrypted by the master password, rather than the user being authenticated by the master password, so that they are able to access the data, and if you'd rather call it 2FE for two-factor encryption, perhaps that is a helpful way to discuss the concern. I would really prefer MFE, or multi-factor encryption because I would like to register two key devices to go along with my password, with either device being sufficient to decrypt. That way, one key goes into the safe and the other gets used. If the key in use gets lost, the key in the safe is used to register a new key.

    That doesn't work because they "unused key" would then be irrelevant. If it was not, in fact "unused", it would be needed to decrypt the data. So you couldn't simply save it for a rainy day.

    A system you seem to be close to describing, though, is one that already exists: with a 1Password.com account, you have a 128-bit, randomly-generated Secret Key which is used along with your Master Password. The Secret Key itself is only needed when authorizing a new device though, so for the most part you can stash it in a safe. That's actually what we recommend, with the Emergency Kit. And then, if you lose the Secret Key (or it is compromised), you can unlock 1Password on an already-authorized device to retrieve it (or generate a new one).

    I understand the appeal of adding yet another key. It feels more secure. But when we're already at 128-bits, adding more doesn't get you any practical benefit; it just makes your life harder when signing into a new device, and adds another thing to potentially lose. And with a hardware token, that's an even bigger risk — again, when it's already beyond infeasible to guess the Secret Key and Master Password together, there's nothing gained by piling more on — since there's no way to back that up. That's not to say there aren't good use cases for that, but it's where authentication is the primary line of defense: then multifactor is absolutely critical. 1Password is functionally very different from that.

    Also, if I understand correctly, DashLane, LastPass and Keeper all support YubiKeys.

    You may be right, but it doesn't seem to have helped them avoid security issues. Security is a painstaking process, not a checklist. A checklist would be easier though, so I wish that were the case. It would be a different world, and we'd all be better off then.

  • Thank you Lars and brenty for your replies.

    I'd first like to assure you that I did not mean to suggest a game of semantics with encryption and authentication. The differences are quite clear to me, and since it was brought up that 1Password protection is through encryption, rather than authentication, I simply meant to acknowledge this and suggest that we could adjust the commonly-used terminology (as in this thread) from 2FA to 2FE, to reflect this.

    I would also like to set the record straight that I am not asking for 1Password to support operations like one-time passwords (OTP) with accounts that are stored inside a 1Password vault. I completely agree with Jeff Goldberg that storing both a password and a OTP secret in the same place is not a good idea. What I am asking for is that 1Password be configurable such that it requires a user to provide an additional key device, independent from the Master Password, in order to decrypt the vault.

    The fact that 1Password takes strides to protect against keyloggers is great (albeit expected), but I am pretty sure that Jeff Goldberg would agree that a) an attacker does not need to obtain root privileges to use a software keylogger, and b) due to ever changing environments (even an operating system security update can introduce bugs), there is always the chance of a new vulnerability showing up that we are not protected against, even in user mode. Even Secure Input and Secure Desktop should be expected to contain unknown flaws. Furthermore, many of us with security concerns are far from fatalists, and are not going to be resigned to an approach like "well, once someone has breached the moat (gained root), you might as well give up trying to stop them". There are also other, non-technical ways for one to lose control of a master password. Although we may all think that we're quite careful and aware, there are going to be employees, contractors, customers or family members that will leave their passwords on a sticky note under the keyboard (if not on the monitor!), in spite of pleas to the contrary. And, at the risk of sounding paranoid, there is always the potential for shoulder-surfing by people or cameras, hardware devices, etc.. If you can at least convince them to attach their digital key to their keyring, they won't go home without it.

    I am not looking to add another key because "it feels more secure". I am looking to require another device because it is more secure. It is far from simply a matter of "adding more bits". I am confident that if you ask a security professional "would requiring the additional presence of a tamper-proof device to answer a digital signature challenge, before allowing access to data (in the case of 1Password, I expect this would be in order to decrypt the vault), be more secure than a password alone?", the answer is going to be yes. You may counter that it would be no more secure than what you already get with your Secret Key approach, but I would have to expect that for a skilled attacker the Secret Key is ultimately a discoverable value (and also does not detach from the computer and go home at night with the user). Furthermore, with knowledge of the master password, it appears an attacker could use the same computer to gain access to the vault, and thereby simply use the Secret Key in situ.

    If someone steals the password to my bank account, the damage will be limited to that bank account. If all of my accounts are in a password manager and someone steals the single factor master password to that, well, I don't even want to think about all of the time, disruption and phone calls that would entail. People managing large systems will have security in layers so that if one layer is breached the damage will be limited. If they are using 1Password to manage all of their logins and that single master password is exposed, their defense-in-layers is seriously compromised.

    I obviously cannot propose implementation changes that would work with your system in order for it to work as I would like. However, I would like to point out that devices such as YubiKey, Nitrokey, etc. support more than just FIDO and OTP, and suggest that their digital signature capabilities be explored in support of true multi-factor protection.

    I would also like to suggest a very robust mechanism of recovery upon the loss or destruction of a registered key device, and would prefer something along the lines of another digital signature device that can be physically locked away in a safe. Anything that is easier to defeat than a combination of master password and independent digital key device becomes the weakest link in the chain, and renders the combination of master password and digital key protection irrelevant. I would be very suspicious, for example, of a recovery approach using the secret key, as that appears to me to be a discoverable value, and clearly not something that I can physically protect.

    Certainly, we cannot expect a completely impenetrable system, but with the standardized devices that are becoming inexpensive and readily available, there are opportunities to do a better job. The notion of putting all of our logins, card numbers, digital certificates, important documents and passwords into a single vault should be an obvious place for true multi-factor protection, and not vulnerable to the discovery of a single factor. We will always need to explore new ideas in order to stay ahead of the thieves and better protect ourselves, and I appreciate the thinking that this topic has inspired.

    thanks,
    Bill

  • BenBen AWS Team

    Team Member

    Thanks for the feedback Bill! You’ve made some great points. I don’t really have anything further to add at this point, but I think there are certainly some items to consider that have been brought up here.

    Ben

  • brentybrenty 1Password Alumni
    edited March 2018

    @Billl: Likewise, Bill. I appreciate it. I apologize if I gave you the impression that I had thought you misunderstood something. On the contrary, in addition to trying to offer another perspective in direct response to your own thoughtful comments, I want to be careful to consider others who may read this discussion. You're absolutely right that there are things we can do (and do, as you noted) to try to mitigate various attacks, even if we cannot ultimately guarantee security in the case of a compromised machine. I thank you for sharing all of your thoughts here. It's a great discussion on a fascinating topic. And with Duo out of beta in the 1Password Teams Pro plan, you may want to take a look at the features their service offers, especially as we roll out support for that in the apps as well in the near future. Cheers! :)

  • Thank you brenty,
    I'll look into Duo a little more than I have, and may try it out with your Teams product.

    Your mention of the Teams plan caused me to look deeper into the Teams product, and brings up a question for me. I see that an admin can "restore access to an account if the Master Password is lost"; I presume this means that an admin can restore access to a team member's account if their personal Master Password is lost. Can you help me to understand how that could work if the team member's data has been encrypted with their lost Master Password?
    thanks!
    Bill

  • brentybrenty 1Password Alumni
    edited March 2018

    Thank you brenty, I'll look into Duo a little more than I have, and may try it out with your Teams product.

    @Billl: You're welcome! Definitely check it out, and let us know if you have any questions about it. However, there's been a rather quiet change there since we last chatted here: 1Password Business. That includes 1Password Teams features and a few new benefits as well. ;)

    Your mention of the Teams plan caused me to look deeper into the Teams product, and brings up a question for me. I see that an admin can "restore access to an account if the Master Password is lost"; I presume this means that an admin can restore access to a team member's account if their personal Master Password is lost. Can you help me to understand how that could work if the team member's data has been encrypted with their lost Master Password? thanks! Bill

    Oh yes indeed. Great question! "Recovery" is a tricky word, because, while I think you understand that this doesn't allow an admin to actually recover a user's Master Password, it could be misconstrued that way. Instead, the account recovery process allows the data to be re-encrypted with a new Master Password (and Secret Key) by the user. The original Master Password, however, is, of course, lost forever. This works similarly to public key cryptography, as each team member has private and public keys. When a vault is created, a copy of the vault key is encrypted with the public key of the Recovery Group. The Recovery Group is able to decrypt the private key of the Recovery Group, which facilitates them restoring access to a user who goes through the recovery process. You can find more details in the security white paper, specifically page 38. So while recovery is really great technically, I think the best thing about it is that it effectively gets team members using public key cryptography when they otherwise wouldn't because of how un-user-friendly it is. :)

  • I'm not very knowledgeable in the realm of security so I apologize if I don't make much sense here. Where I see a 2fa method such as YubiKey being valuable for me as a 1pwd user is to have it required on every login and not just the first time you register a device, where perhaps the secret key is enough of a barrier, but even that could perhaps be replaced by the YubiKey. I don't also mean to require 2fa on every unlock attempt, but to optionally require it on every login (e.g. when you first open the app after starting your computer).
    That would make me feel safer even if it doesn't make sense to some security experts. And on that front I should actually remind you that most of your customers don't understand a word from this thread, so even if you don't think this would be a great security investment think of it as a marketing investment. Just my 2 cents.

  • LarsLars Junior Member

    Team Member

    Welcome to the forum, @sinaH! Thanks for taking the time to share your thoughts with us.

    That would make me feel safer even if it doesn't make sense to some security experts.

    This is exactly what we try to avoid doing, whenever possible: giving people the illusion of security without the reality. We call it "security theater," and there's a fair amount of it out there in the larger world right now: things that make you feel more secure without actually increasing (and in a few cases, decreasing) your real security. To be clear, I'm not referring to YubiKey in general as useless or as "security theater," but - as has been discussed earlier multiple times in this thread - standalone 1Password is encryption-based (not authentication-based) and in the 1password.com model, there is 2-Secret Key Derivation (2SKD) with your Secret Key.

    However, there have been some interesting developments from YubiCo lately, and adding additional meaningful security to 1Password is something we're always on the lookout for.

  • Hi folks - particularly Ben, brenty and Lars,

    I'm wondering if there are any further updates from the 1Password team to address some of the points that Bill raised in his long, well thought out response in March 2018.

    I'm particularly interested if there has been any further thought on the sections I've quoted below, as I agree this isn't about adding another key to feel more secure. It's about the presence of an additional device acting as an external factor before allowing access to data since the secret key is no longer a useful security factor once it is stored on the device.

    I am not looking to add another key because "it feels more secure". I am looking to require another device because it is more secure. It is far from simply a matter of "adding more bits". I am confident that if you ask a security professional "would requiring the additional presence of a tamper-proof device to answer a digital signature challenge, before allowing access to data (in the case of 1Password, I expect this would be in order to decrypt the vault), be more secure than a password alone?", the answer is going to be yes. You may counter that it would be no more secure than what you already get with your Secret Key approach, but I would have to expect that for a skilled attacker the Secret Key is ultimately a discoverable value (and also does not detach from the computer and go home at night with the user). Furthermore, with knowledge of the master password, it appears an attacker could use the same computer to gain access to the vault, and thereby simply use the Secret Key in situ.


    However, I would like to point out that devices such as YubiKey, Nitrokey, etc. support more than just FIDO and OTP, and suggest that their digital signature capabilities be explored in support of true multi-factor protection.

    In response to the March 2018 post Duo was suggested as something to look into as it came out of beta. I don't believe this suitably satisfies the requested features as this is only used during authentication.

  • LarsLars Junior Member

    Team Member
    edited October 2019

    Welcome to the forum, @rowleyaj! This was certainly a blast from the past. :) In the interim, we have indeed brought Duo to full functionality as a 2FA option for 1Password Business and 1Password Teams Pro. It offers some additional adjustability in terms of how often re-authentication is required, and how often administrators will get prompts to approve users' sign-ins.

    Since the time of that discussion, we've also Rolled out support for using your U2F hardware keys with your 1Password account. If you're referring to pursuing something like a key-splitting arrangement using a hardware token, that's not something we've pursued, nor do we have any plans that I'm aware of to do so, at present.

    Here's why: in the current implementation of 2FA in 1Password (whether you're using the authenticator app such as Authy or Google Authenticator, or a hardware key like a Yubikey), new sign-ins to your 1Password account on devices that have not previously been used to sign-into your account will require 2FA. The reason for that is because what 2FA protects you against in 1Password is a situation where an attacker has managed to discover your Master Password and your Secret Key, but does not have a copy of your data. If an attacker is trying to sign in from an unrecognized device and they've somehow acquired your Master Password and Secret Key, 2FA will prevent this -- the attacker would be presented with the 2FA prompt which they wouldn't have the one-time password or hardware key to use...and you'd be notified via email that someone was attempting to access your account from an unknown device. Crisis averted.

    In every 1Password app, however, once you first sign into your 1Password account, the data is downloaded and there is a persistent local cache, which is what any attacker coming into possession of one of your users' devices would attempt to crack. In truth, an attacker in such a case might simply try to socially engineer you rather than trying to mount a frontal assault on AES256 or on a user's strong Master Password; that's usually much easier and quicker. But if they decided to go the brute-force password-cracking route, they certainly wouldn't do it by launching the 1Password app itself and typing or pasting guess after guess manually into the Master Password lock screen. Any competent attacker would simply extract the encrypted data file from your hard drive and run automated password-cracking tools on it. That renders any further authentication (2-Factor or otherwise) we might try to put in place within 1Password apps themselves little more than security theater, which we try to avoid. We could make the 1Password app do an authentication call to a remote server and deny you access to the data if it failed...but because any attacker worth his salt (pun intentional) wouldn't use the 1Password app to try their cracking, doing so wouldn't provide any additional benefit, but would add needless complexity and another possible point of failure (or at least confusion) for newer and less-knowledgeable users.

    Put another way, even if we added a 2FA prompt for unlock, the attacker can bypass that by NOT going through 1Password's UI anyway; so it would not stop an attacker with access to your device and the data on it trying to brute force it, or simply decrypting it if they already have your Master Password and Secret Key (or can get them by virtue of "owning" your device).

    That leaves actually splitting the decryption key necessary to unlock 1Password. I addressed that aspect in my own post when the thread was current:

    In the other instance, you'd be attempting actual key-splitting, where the 2nd factor provided by the external hardware token could actually be part of the encryption key itself (not just the secret used to derive it). If that's what you're referring to - actually splitting your AES256 key and putting some portion of that onto two different Yubikeys - I have to ask why you would want to be widening your attack surface by providing multiple ways into your data at the same time that you'd be creating a legitimate risk of making your data completely inaccessible if those keys were lost or damaged.

    To expand upon that last point a bit, if it were possible to do so securely, what physical key-splitting of this nature would result in, far more often than preventing actual breach of a user's 1Password data, is people losing one of the factors required to decrypt their data. We see this currently on a regular basis with the Master Password, the Secret Key (and even with the existing 2FA implementation): users forget the former, they lose (or don't understand the significance of) the latter. Even the post you quoted from Billl alluded to this, from a different angle:

    Although we may all think that we're quite careful and aware, there are going to be employees, contractors, customers or family members that will leave their passwords on a sticky note under the keyboard (if not on the monitor!), in spite of pleas to the contrary.

    Just so: people lose things. They forget them. They send them through the washing machine. Since 2006, what protects your 1Password data in your 1Password app(s) on your device(s) is your (hopefully long and strong) Master Password. And since those early years, we've yet to be made aware of a user's encrypted 1Password data being breached via a direct assault on their strong Master Password. That's the real reason we've not been inclined to pursue a key-splitting setup that would require a second encryption (not authentication) factor: not because of the considerable difficulty of doing it in a way that would be robust and replicable across four platforms (Mac, Windows, iOS and Android) plus the web interface and 1Password X, but because (as this closed post from six years ago observes):

    ...for every case where someone reports that their computer or device has been stolen, we get probably a hundred more of "I forgot my Master Password" or "I damaged my data and didn't have usable backups". My fear is that key splitting or keyfile moving wouldn't just double the rate of people getting locked out, but would increase it much more [...] The threat of data loss becomes very substantial.

    Indeed. Much of that old post is no longer relevant -- 1password.com accounts didn't even exist then! -- but that specific portion touches on one of the evergreen cornerstones of what we do: making good security available to regular, "non-techy" people (think your mom, or at least mine) by not overly complicating things, requiring them to sort through multiple advanced options or setting things up so it's easy to lose/forget important information that results in frustration and potentially even data loss.

This discussion has been closed.