Request for Multi-Factor Authentication
I am requesting that Multi-factor authentication support be added to 1Password.
I would like to use a third party device, such as Yubikey, to add the 'something you have' factor to authenticating into 1Password. This factor shouldn't be required on devices such a iOS, Android or a tablet, but should be required when unlocking the keychain via web-interface, or optionally, locally via a computer that can support the external device.
Thank you!
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @DMeans,
Thanks for taking the time to write in. The account key, used with our 1Password for Families and 1Password for Teams services functions in a similar way to what you've described (without the next for extra hardware).
Beyond that, this post may answer some questions:
AgileBits Blog | Two Factor or not Two Factor
Thanks!
Ben
0 -
@bwoodruff, thank you for responding. I'll look into the account key.
Nevertheless, I've read the blog before. It hasn't convinced me to stop asking for the feature, so I'll explain why: they keychain is secure until the master password is exposed.
The "password problem" in relation to multi-factor is two-fold: insecure passwords and third-party acquisition of those passwords, such as shoulder surfing or key-loggers. 1Password helps solve the problem of creating and maintaining secure passwords, but leaves the consumer wide-open to attacks using shoulder surfing and key-loggers when applied to data theft of the keychain. A second factor would remediate the attacks enabled by exposure of the password, since all an attacker needs is "access to both data and the master password."
In the end, the exposure of the master password is the only threat we want mitigated.
The argument that two factor authentication "increases the ways that a legitimate user can lose access to their 1Password data," is unsound. The problem is solved by expanding the implementation of key-wrapping. One or more one-time-use secrets are provided to the end user, any of which may unlock the master key. This similar in method to how Google provides a number of passwords that may be used to unlock Gmail in the event the 2nd factor is unavailable. If a PBKDF2 of the one-time-use keys is used to wrap the master key, then AES 256 should keep the data sufficiently safe, as discussed else where .
However, I wonder if 1Password is susceptible to attacks against AES 256? The description of how 1Password generates the HMAC and the encrypting key seems to indicate that those two keys are related. But I don't know if they're related in a meaningful way. See http://eprint.iacr.org/2009/374.pdf.
Finally, the question isn't what value does adding additional key material provide to confidentiality - which is exactly what the blog answers and defends against. Rather, the question is what value does a second factor provide in the presence of a compromised first factor?
We don't want it to protect the data, we want it to project the master password that protects the data.
On a device with a fingerprint reader, it's a shoe-in. Otherwise, you might add support for a blob (image, file) at some location to serve as the additional factor, or not support it at all on such devices, suggesting that the user implement other built-in security mechanisms.
But in the end, it's just a technical and usability challenge to solve.
0 -
@bwoodruff, thank you for responding. I'll look into the account key.
Nevertheless, I've read the blog before. It hasn't convinced me to stop asking for the feature, so I'll explain why: they keychain is secure until the master password is exposed.@DMeans: We're not trying to convince you of anything. You're absolutely right that if you give your vault and Master Password to someone, they will be able to access your data.
The "password problem" in relation to multi-factor is two-fold: insecure passwords and third-party acquisition of those passwords, such as shoulder surfing or key-loggers. 1Password helps solve the problem of creating and maintaining secure passwords, but leaves the consumer wide-open to attacks using shoulder surfing and key-loggers when applied to data theft of the keychain. A second factor would remediate the attacks enabled by exposure of the password, since all an attacker needs is "access to both data and the master password."
The real problem here is that there's nothing to authenticate against with a local 1Password vault. The actual encryption of your data doesn't change over time (to accommodate a one-time password), so the only way to do access control would be server side...and again, when your data is stored in a local vault, there is no server component.
However, we are considering adding additional multifactor authentication to 1Password for Teams/Families, since it is actually possible given the server model. I said "additional" because, as Ben pointed out, the Account Key serves that function...but the individual devices themselves that you authenticate with your 1Password do as well. And it may be possible to incorporate something like this into the apps: using a known, trusted, authenticated device to approve and setup new ones. Definitely check out the 1Password for Teams white paper (which also applies to 1Password for Families). I think it will be right up your alley!
In the end, the exposure of the master password is the only threat we want mitigated.
Ultimately only you have any control over whether your Master Password is exposed. AgileBits doesn't have it. 1Password doesn't store it in your vault. Unless you put it somewhere else or give it to someone else, it only exists in your brain.
The argument that two factor authentication "increases the ways that a legitimate user can lose access to their 1Password data," is unsound. The problem is solved by expanding the implementation of key-wrapping. One or more one-time-use secrets are provided to the end user, any of which may unlock the master key. This similar in method to how Google provides a number of passwords that may be used to unlock Gmail in the event the 2nd factor is unavailable. If a PBKDF2 of the one-time-use keys is used to wrap the master key, then AES 256 should keep the data sufficiently safe, as discussed else where .
This really isn't the same thing. You're not using Google to encrypt your data. You're logging into an account there anyway, so the can simply compare both the password hash and TOTP against what is expected to authenticate. They're not re-encrypting anything on the fly and then using the TOTP you provide as part of the key to decrypt it.
However, I wonder if 1Password is susceptible to attacks against AES 256? The description of how 1Password generates the HMAC and the encrypting key seems to indicate that those two keys are related. But I don't know if they're related in a meaningful way. See http://eprint.iacr.org/2009/374.pdf.
1Password does not simply encrypt your data using your Master Password alone. After all, not everyone uses a long, strong, unique Master Password. Instead, your Master Password is strengthened using PBKDF2, encrypts the vault keys, which in turn encrypts individual items. You can read more details in our knowledgebase:
How does 1Password keep my data safe?
AES hasn't been "cracked", though it almost seems like you're implying that it has. As always, brute force attacks exist to defeat weak keys, but 1Password goes to some lengths to protect us not only from attackers, but from ourselves.
Finally, the question isn't what value does adding additional key material provide to confidentiality - which is exactly what the blog answers and defends against. Rather, the question is what value does a second factor provide in the presence of a compromised first factor?
If the Master Password is compromised and the data is already in the attacker's possession, someone can simply perform an offline attack on it. A one-time password (which could theoretically guard against initial unauthorized access) won't help in this case. Given that many folks (myself included) store vaults "in the cloud", we've designed 1Password with the expectation that your encrypted data will be compromised at some point, and put in safeguards with that in mind.
We don't want it to protect the data, we want it to project the master password that protects the data.
On a device with a fingerprint reader, it's a shoe-in. Otherwise, you might add support for a blob (image, file) at some location to serve as the additional factor, or not support it at all on such devices, suggesting that the user implement other built-in security mechanisms.
But in the end, it's just a technical and usability challenge to solve.Indeed, "just"! :lol:
All of these are interesting ideas, but as Ben mentioned, these are also "one more thing" (on top of the vault, Master Password, and now Account Key) for people to lose. If it can be done in a meaningful way that is usable and improves security, it's certainly something we can consider. But in my experience things like "site keys" that some banks use haven't helped in either respect.
Edit: And I also wanted to point out that the Account Key is the same thing, only it's currently treated as a text string, though it could just as easily be saved to a file and imported that way instead in the future.
0 -
@brenty -
Thank you for responding.
I will definitely look into the account password! :)
But I must say, every time I have this conversation with Agilebits, I come away thinking you guys have your own ideas about MFA, that it some how is only applicable when being implemented in such a way that it increases the strength of an encryption system - which is exactly what you did with the account password. That's not the purpose of MFA, although it can be implemented in with that mind. MFA is about the entity requesting access, not the information system protecting the data: it's something you have, something you know, and something you are. All of those bits are provided to by the entity to assert identity, not required by the system to increase obfuscation. One may perfectly implement MFA but still fail to adequately protect data at rest, in use or in motion. That's why I said we want MFA in order to protect the password. Because if the password is exposed, it's useless with out the other factor. Another password is not MFA, nor better than MFA: it's 1 factor with two passwords which may still be exposed, which means the data is still accessible when that one factor is known.
Regarding AES, please refer to the white paper I linked above: "Key Recovery Attacks of Practical Complexity on AES Variants With Up To 10 Rounds." In this paper they "... describe an attack on 9-round AES-256 which can find its complete 256-bit key in 2^39 time by using only the simplest type of related keys (in which the chosen plaintexts are encrypted under two keys whose XOR difference can be chosen in many different ways)." Since you're using PBKDF2 to generate two keys from one source, you seem to at least have related, XOR keys. It's an interesting read. It's something you might want to investigate and determine for yourselves if the implementation you have selected is vulnerable to their attack.
Regarding the server / team model: keep in mind that there are regulatory requirements some of us have to adhere to when selecting products for corporate use. In example, one of my job duties is to make sure our developers use approved protocols implemented in proper ways. Hence, I need to make sure all of our crypto providers are FIPS complaint. Just something for you to think about.
Thank you for your time; you guys have a great product. :+1:
0 -
MFA is about the entity requesting access, not the information system protecting the data: it's something you have, something you know, and something you are. All of those bits are provided to by the entity to assert identity, not required by the system to increase obfuscation.
@DMeans: Hmm. I think we may be talking about the same thing, just in different terms. Maybe you could break it down for me if you mean something else, but typically MFA is used to prove identity ("something you have") to authenticate with another party.
My point is that — with the exception of 1Password for Teams/Families — there is no such entity to authenticate with, whether it be a company, a server, or something else. With the standalone 1Password app, your data is controlled entirely by you, so there's no one acting as a gatekeeper that you need to authenticate with (for example, using MFA).
One may perfectly implement MFA but still fail to adequately protect data at rest, in use or in motion. That's why I said we want MFA in order to protect the password. Because if the password is exposed, it's useless with out the other factor.
Can you elaborate what you mean by "protect the password"? I'm guessing you mean the Master Password, but as I mentioned, there are only two ways that would (sort of) accomplish this goal: authenticating externally to protect against unauthorized access (policy), or having it somehow be involved in the encryption itself (technology). And again, neither of these are possible with a 1Password vault that is controlled only by you, which must be able to be decrypted on demand using your Master Password; there's no one there acting as a gatekeeper, and the encryption will always require the same keys to decrypt. And to directly protect the Master Password, you'd have to store it somewhere, presumably with access requiring MFA. That wouldn't be very secure at all, and I expect that's not what you had in mind anyway, but I thought it warranted mentioning.
Another password is not MFA, nor better than MFA: it's 1 factor with two passwords which may still be exposed, which means the data is still accessible when that one factor is known.
Well, in the case of the Account Key, it's not just one factor, since more than one is needed to decrypt the data. The Account Key isn't used in the traditional "policy" sense like a typical "one-time password" is (e.g. you have to provide the correct one at the correct time to the server to login), but it is actually used to strengthen your data against brute force attacks: even if your Master Password isn't great, your Master Password alone isn't used to encrypt your data. This makes it impossible for a brute force attack against your Master Password — however weak — to result in the decryption of your data.
That's all well and good, but what's the real reason the Account Key exists? With 1Password for Teams/Families, for the first time, 1Password data is stored on AgileBits servers. It's an encrypted blob, mind you, but we need to take the worst-case scenario into account: a security breach of the server — by a hacker, government, a malicious employee...or maybe some evil corporation buys AgileBits. Certainly, these aren't particularly likely scenarios, but our customers shouldn't have to just rely on good fortune to ensure that their data is secure.
But let's say the unimaginable happens: someone dumps all of the data from the server. They can then, at their leisure, perform brute force attacks to try to decrypt it. But wait! While the server held the encrypted data, the Master Password and Account Key are never transmitted, so it didn't have either of those. They're both setup on the device itself; the Account Key is stored only locally on an authorized device; and the Master Password is known only by the user. So in order to decrypt the data, even if my Master Password is 12345678 and my account is known (so they can target my actual encrypted data), they'll still have to try to brute force the Account Key, which looks similar to this:
A3-8MMQJN-MZ64CY-2SDB4-RPX3T-V52Q3-N2C84. As you can imagine, that's a tall order, even if the attacker has everything else they need — which is pretty unlikely in and of itself.Regarding AES, please refer to the white paper I linked above: "Key Recovery Attacks of Practical Complexity on AES Variants With Up To 10 Rounds." In this paper they "... describe an attack on 9-round AES-256 which can find its complete 256-bit key in 2^39 time by using only the simplest type of related keys (in which the chosen plaintexts are encrypted under two keys whose XOR difference can be chosen in many different ways)." Since you're using PBKDF2 to generate two keys from one source, you seem to at least have related, XOR keys. It's an interesting read. It's something you might want to investigate and determine for yourselves if the implementation you have selected is vulnerable to their attack.
I enjoyed reading that a while back, but it was good to take a look at it again with the benefit of time and (hopefully) wisdom. I won't go into detail because I don't think I could do it justice, but while the research was fascinating, the conclusions of the paper aren't fully supported by the evidence. I'll let @jpgoldberg go into more detail (especially relative to 1Password), but suffice to say that if the theoretical attacks had proven practical (even the researchers admit they aren't), the world would be a very different place right now. There would be no real security (given that nearly everything is built on AES), and the FBI would't need to pester Apple for a way around it.
Regarding the server / team model: keep in mind that there are regulatory requirements some of us have to adhere to when selecting products for corporate use. In example, one of my job duties is to make sure our developers use approved protocols implemented in proper ways. Hence, I need to make sure all of our crypto providers are FIPS complaint. Just something for you to think about.
Absolutely! Thanks for bringing this up. We have some compliance and risk assessment information in our knowledgebase already, but you weren't specific about your own needs. Are you referring to the Federal Information Processing Standards? If so, which in particular (obviously, there are some that simply don't apply)? I'd appreciate your input!
Thank you for your time; you guys have a great product. :+1:
Likewise! Thanks for the kind words, your continued support, and taking the time to discuss things like this with us! :chuffed:
0 -
@brenty -
Thank you Sir, for responding. :)
It's good to know you're aware of the AES research and have investigated it in view of 1Password.
Regarding MFA:
With the standalone 1Password app, your data is controlled entirely by you,
so there's no one acting as a gatekeeper that you need to authenticate with (for example, using MFA).What I've unsuccessfully tried to say is this: MFA isn't about the data. It could be used to grant access to a facility. MFA stands on it's own. In example, I might be able to add MFA to my Mac, but shouldn't infer that it's being used it to secure the data on my SSD, rather it's being used to control access to the machine. That might imply to some that I don't want unauthorized to access the data on my SSD, but my idea of security might be that I don't want someone to use my machine to access the Internet. Therefore, MFA stands on it's own, apart from any other security control, such as those used to implement confidentiality.
With encrypted data solely on my system, one might say that authenticating into OS of the computer adds an additional factor. I would tend to agree. The conflict to that paradigm arrives when that data is in the cloud, and is under attack by a third party.
Since the 1Password app is the default gateway into it's data, then I would suggest that 1Password is the gatekeeper. In the simplest terms, adding the hash of a remote object (as a salt) into the PBKDF2 of my master password adds the additional factor - something I have.
Why is that important? Because the attack strategy to uncover or replicate that second factor is completely diverse from the first. That's why MFA is desirable in many different contexts.
Have a good day, Sirs. I'll be checking in every now and again. And again, I think you have a great product.
0 -
Thank you @DMeans!
You are, of course, correct that the second-factorness of 2FA does add protection in general. It means that there are two (often very different sorts of things) that an attacker must acquire if they are going to break authentication. But again your use of language like "gateway" makes it all too easy to think about these in terms of authentication.
The distinction between authentication and encryption is still relevant despite that the fact that "second-factorness" can provide a security benefit in its own right. Authentication systems can have password resets. The operators of the service you are authenticating to have access as well and so can grant you access if you lose your password or your second factor. Indeed, they can turn of the requirement of the second factor. Because 1Passwords security is from its use of encryption, we need two secret key derivation (2SKD) instead of two factor authentication (2FA). This means that if you lose either of those you will be forever locked out of your data with absolutely nothing that anyone, including use, can do for you.
We've introduced two-secret key derivation (2SKD) into 1Password for Families and Teams because there is a recovery mechanism via the Team owner. We aren't able to perform recovery, but as vault keys are escrowed with the members of the recovery group1, those individuals can assist in recovering data if a user forgets a Master Password or loses their Account Key. But when you are working as an individual, there can be no such recovery mechanism. There is absolutely now way to decrypt your data without both secrets needed in key derivation.
So adding two-secret key derivation (from multiple factors) greatly increases the risk of data lose. And it would be doing so for a security gain that is much smaller than many people would recognize.
But do keep looking for the feature. As we learn about how 2SKD actually works for people, we may extent to having the high entropy secret on a more distinct "factor". And if things like that prove to be sufficiently robust and reliable and portable across clients, it toward bringing a strong two-factorness to 1Password, even without authentication. But the risk to data availability is just far too great for me to suggest that anything would be happening soon.
-
The "Recovery Group" is a layer of complexity that isn't exposed in current versions, as we decided to simply the various sorts of roles of "owners", "managers," "administrators", and "recovery group members" that people have to deal with. Now all "owners" are automatically members of the "recovery group" and so owners are no longer being asked to explicitly appoint people to the recovery group. ↩︎
0 -
-
What I've unsuccessfully tried to say is this: MFA isn't about the data.
@DMeans: I suspect that this isn't quote what you meant, since with 1Password the only thing we're trying to protect is data.
It could be used to grant access to a facility. MFA stands on it's own. In example, I might be able to add MFA to my Mac, but shouldn't infer that it's being used it to secure the data on my SSD, rather it's being used to control access to the machine. That might imply to some that I don't want unauthorized to access the data on my SSD, but my idea of security might be that I don't want someone to use my machine to access the Internet. Therefore, MFA stands on it's own, apart from any other security control, such as those used to implement confidentiality.
I guess the point I was trying to make (this is really hard, isn't it? :lol: ) is that while you're absolutely right that there are other things worth protecting, they're outside of 1Password's purview. We're trying to securely store sensitive information on a device, and additional measures are only useful if they help us achieve that goal — which is why I keep coming back to encryption.
In the case of the computer, you may very well want to prevent someone from using it to do their web surfing. But since I'm approaching this from a different perspective (security and privacy), my thoughts are that if MFA is the only thing "securing" the Mac, it's trivial to rip out the SSD and use it in another machine. Similarly, if the data is not encrypted, someone could then use it to effectively "be" me on the internet, using any cookies to access websites as I would, with full access to my browsing history.
With the computer's data unencrypted and protected only by MFA, it's analogous to a house with a keypad on the front door, but with the back door unlocked. You can encourage people to use the front door and ask to be let in, but even your family members might find it more convenient to just go around back. Nothing in the house is really secured.
I think MFA could potentially be useful for 1Password for Teams/Families, as a way to add another layer of protection against, say, unauthorized changes, or authorizing a new, heretofore-untrusted device. But it doesn't seem to be applicable to the standalone app the way you suggest with the computer. And as Jeff intimated, if it doesn't actually strengthen security, it's just another hoop for people to jump through (or another way for them to lose access to their own data):
Because 1Password's security is from its use of encryption, we need two secret key derivation (2SKD) instead of two factor authentication (2FA).
A tremendous problem, and a fascinating discussion! :pirate:
0
