Using Security Key for 2-Step Verification
Today google started using security key for 2-step verification.
http://googleonlinesecurity.blogspot.com/2014/10/strengthening-2-step-verification-with.html
Other password managers are using it.
https://www.yubico.com/applications/password-management/consumer/
Does 1Password have any plans to start using it?
1Password was my first and one and only password manager app for years on my Macs.
Then when I got my first Chromebook and could got get 1password to work correctly on it so I started using LastPass on my Chromebook well still using 1Password on my Macs and iPhone.
After switching from iPhone to Galaxy s5 I started using LastPass on my Android.
Currently I find myself bouncing back and fourth between 1Password and LastPass.
Today though I ordered my first Security Key because of what I read about google starting to use them. Being I'm going to have a security key with me now I will probably lean more towards using LastPass instead of 1Password, unless 1Password will start letting me use my security key too.
I see there are a few other uses for my new security key too. Including Paypal, eBay, Evernote, Bank of America, etc..
https://www.yubico.com/applications/
What do you say 1Password? Any plans for security keys?
Comments
-
Well after reading this topic...
https://discussions.agilebits.com/discussion/20061/a-few-thoughts#latestI'm guessing the answer to my question is, 1Password has no plans for letting me use a security key.
0 -
No plans, but it is still something we're interested in and considering for the future. :)
0 -
Believe I read on yubico website that they will soon be releasing a new FIDO U2F Security Key with bluetooth & NFC for mobile devices. I don't think their current NFC Security Key is FIDO U2F so it would not work with google. Sound like it would be really slick for use with my phone.
For what it's worth I do like the 1Password interface a bit better then LastPass, but it does seem as if LastPass gives me a few more option.
I'm hoping now that google has jumped on the FIDO U2F security key band wagon other companies will take notice and do the same.Thanks
0 -
Cross linking this post where I had asked about U2F as well. I believe it contains some more informative information.
https://discussions.agilebits.com/discussion/30193/1password-and-u2f
0 -
Thanks for sharing, @incorvia !
0 -
I too have been looking into U2F with interest since Google's announcement, especially since it looks to seriously improve both security and usability of authentication on the web.
Here's my idea in applying it to 1Password: Use a FIDO U2F token as a Master Password ALTERNATIVE.
Considering the balance of security and usability being struck, 1Password is some pretty well made, usable software. But I imagine I'm not the only one who finds entering my Master Password several times/day a fairly substantial pain point.It seems pretty appealing to instead simply push a button on the USB U2F token instead. More secure would be to prompt for a short pin after touching the token, to cover for when you've left your computer unlocked and your U2F token plugged in, and other similar cases.
Thoughts? Likelihood of integrating this into 1Password?
Thanks,
-John0 -
google supports this now - it would be a great addition to the mac client.
Lastpass & Passpack already offer this (via OTP not U2F)
more more details see
https://www.yubico.com/applications/internet-services/
https://www.yubico.com/applications/password-management/consumer/lastpass/0 -
@jds8288 I think @incorvia might already have adressed your idea in his link. Here is my take on your idea.
1Password is not authenticating anything, it is encrypting and decrypting. A Second Factor UX (U2F) authentication token is not meant for encrypting or decrypting anything, it is solely meant as a means of verifying if you should be allowed to access something. Ignoring that for a second and assuming that Agile Bits will implement U2F into 1Password… Anyone attacking your encrypted data will not be doing so by manually guessing passwords into the 1Password main interface. They will attack the data file directly, thus rendering the authentication scheme moot.
Then there is the case of actually encrypting your data with one-time-passwords which U2F:s: If I have understood 1Password's data model correctly it works (very simplified, anyone please correct any errors!) like this: Your master password is used to encrypt a key (essentially a longer password), this key is then used to encrypt your actual data. When you enter your master password your key gets decrypted and that in turn is used to decrypt any content that you view in 1Password.
The key can only be decrypted by using your master password and if you use 1-time tokens you either need to encrypt your key so that it can be unlocked with any 1-time token your USB dongle might send (you can imagine how safe your data would be if any password could unlock it!). The other option would be to have your USB dongle always send the same password, essentially being some sort of a 1-button preprogrammed keyboard that save you the hassle of typing the same thing over and over again, but as I understand it FIDO is not such a thing.
I hope that wasn't too rambly. :)
0 -
"No plans" is a bit too pessimistic. "No immediate plans" is more like it.
We do want something. But because 1Password does not use authentication, we can't (and don't really need to) do it the way that authentication-based systems do. (Fortunately, we don't face the same threats as those systems do, so the need isn't as urgent).
Yubikey is really designed to work with authentication-based systems, but that doesn't mean that it isn't possible to use it with an encryption-based system like 1Password.
What two-factor means for encryption-based systems.
Because 1Password works by encryption, either you possess the secrets needed to decrypt your data or you don't. It really will be easier to talk about this if I introduce some notation. (Really.)
Let's also call your encrypted 1Password data c and your decrypted 1Password data m. c ("ciphertext" in crypto jargon) is what is stored on your phone or computer and synced through iCloud or Dropbox or whatever sync mechanism you use. m is what you see when you unlock your data. (It is for "message" which actually makes sense if you consider that encrypted something for yourself is the same thing as sending a message to yourself to a time in the future.)
One of those secrets is (derived from) your Master Password. Let's call that k₁. With a two-factor security system the second secret would be (derived from) something on your second factor device. Let's call that second secret k₂. (The ks are for "keys".)
Encryption transforms m into c. It's a mathematical transformation that depends on a key. This is often written as
c = E(k, m)
Decryption transforms c into m and can only be done with the same key. And this is written as
m = D(k, c)
Not like authentication
Authentication is about granting access. Encryption is about transforming data. If you only have c it doesn't matter whether something "gives you access" or not. c simply cannot be transformed into m without k. This is why 1Password doesn't have a password reset mechanism. If you lose k there is nothing anyone can do to help you transform c back into m.
Combining keys
So a two factor system for encryption involves having two separate keys, k₁ and k₂ that are both necessary to perform the encryption and decryption. What we do is combine k₁ and k₂ to create the actual encryption and decryption key, k. There are a number of ways that can be done, some of them good ways and some of them bad ways.
How not to combine keys
The simplest way to think of combining keys would be like taking a password of
FooBarBangBingand splitting it intoFooBarandBangBing. Only when combined do you end up with the right password. But this is not a good way to split a secret. The problem with this is that someone who captures one of the secrets is in a much stronger position to guess the full secret. We don't want knowledge of one of the secrets to reveal any information about the final secret.Combining with XOR
Anyway, let's suppose that we have a way of combining keys that does have the right cryptographic properties. For this discussion I will use XOR (which is only appropriate if the keys themselves have certain properties but is the simplest to describe). I will write this as
k = k₁ ⊕ k₂ (The circle with the plus in it is the symbol for binary XOR)
Now that we have that notation ...
OK, so when you would unlock your 1Password data with a two-factor system, you would have c on your disk. You would type in your Master Password from which 1Password would derive k₁. You would do something with some second factor thingy from which 1Password would get k₂. 1Password would then XOR those to get k and then use k to decrypt c into m.
"Great," you say. "That is easy enough." It would appear that all we need to do is pick an appropriate second factor thingy and all would be good. Of course if you lose or damage the second factor it would be like forgetting your Master Password. But let's suppose that you are happy to take that risk.
Syncing is the sticking point
Now consider the fact that you sync your 1Password data to various systems. c is on your Android phone, your iPad, the Windows machine you use at work and on your Mac Book Air. Your Master Password is in your head, and so 1Password can get k₁ once you enter your Master Password. But with k₁ alone, there is no way to transform c into m. 1Password is going to need to get k₂ on each and every device you want to use 1Password on.
For a second factor to be worth anything, it must be impossible to decrypt c with only k₁. Otherwise, the second factor is less security than just facade. The point of a second factor is so that if someone captures c then they can't decrypt it even if they were to guess your Master Password. So k₂ is required anywhere that you need to use m.
So we need to find a single second factor mechanism that will work the same way across platforms.
Possible solutions
There are a number of possible approaches. A mechanism for a one time transfer of the second key from one device to a mobile device and storing these long term on the mobile devices. There may be some NFC/USB combo that will work for the latest and greatest mobile devices. We've actually worked through a number of ways we could go with this.
These all involve a fair amount of UI changes both for initial set-up, regular use, transfer of second secret, and backup. The actual cryptography is easy (a rare thing). But it is the management of the second secret to work for people using 1Password on multiple devices and multiple platforms that is tricky. It is something that needs to be done right. And it is something that needs to be done very carefully so that nobody gets locked out of their data. (Indeed, a lot of the internal discussion is about how we would enable and encourage a backup of the second key.)
0 -
That was a rather… awesome response.
0 -
I concur, that was a fantastic reply, kudos to @jpgoldberg and Agilebits overall for being transparent like this and involving us, the users.
@Niklas, thanks for your reply. I had seen the discussion at the link and I think the key differentiation between what I am thinking of and the typical conversation around Yubikey/2nd factor devices is this:
A FIDO U2F device doesn't generate a 1-time token, but generates a unique key (a public/private keypair, specifically) on the hardware token, per website or entity that you’re authenticating to. The private part of the key never leaves the U2F token during its lifetime, but through an exchange when you visit a website, the private key is used to prove to the website that this is the same key that was registered with your username previously.
When you authenticate to a website using a U2F device, you also provide a password, but it is much more acceptable to use a short password, or even a pin like with an ATM card. The password would mostly just be to ensure someone else doesn’t have your U2F token.@jpgoldberg
Would the goal be more to increase security or usability?
What you described, I think, may well increase security but probably decrease usability, since you have to "lug around" a second factor all the time.What I was envisioning was a "secret" that achieves what a Master Password does now ("unlocks" the encryption key, k1), but is easier to use than typing out a password.
So, what I am saying is, more than one way to "unlock" k1; k2 is not in the picture.
A FIDO U2F device, once matched with my 1Password would contain a public/private keypair specifically for use with 1Password. Couldn't this be used to "unlock" k1?
(Of course this assumes that I have the correct concept of the Master Password and its connection to k1 - I might not.)To me this is analogous to newer cars which will unlock/allow you to start them based on the proximity of the key fob in your pocket or purse. There's no proving who you are - no authentication, per say - as is the case with 1Password as you've pointed out. But you are in possession of a "secret" which unlocks the car and is noticeably easier to use than the key which must be found and inserted.
0 -
@jpgoldberg
You should review your post. I think you've mixed up k1 and k2 in a couple of places.From a technical point of view, how do you ensure that xor'ing k1 and k2 will always produce the same result when k2 is constantly changing? I assume that you'd need a mathematical function that produces seemingly random numbers that will consistently xor against k1 in the same way. I've never heard of such a thing.
0 -
Thanks @RichardPayne!
I've edited to correct a couple "k₂"s. There are probably some more that I missed. (I'd actually had more trouble than I'd anticipated with the notion, and had to change the way I tried to "get" these multiple times before it rendered. Next time, I won't use subscripts in the forums.)
From a technical point of view, how do you ensure that xor'ing k1 and k2 will always produce the same result when k2 is constantly changing?
Very well spotted!
For people who don't see what Richard is asking about, I said k₁ is derived from your Master Password, and that I said that the final decryption/encryption key, k, must be the same everywhere you need to unlock your data. But people can change their Master Passwords, so how to we ensure that we still get the same k after that?
As you can probably guess, I took a few shortcuts in my description so that I could focus on the point I was trying to, well, focus on. The fuller truth is that k₁ is "wrapped" with a Key Encryption Key (KEK) that is in turn derived from the Master Password. So when you change a Master Password, k₁ stays the same, but it gets "rewrapped" with the new KEK.
It's even more complicated
There is actually an additional step we use in 1Password Vaults. Instead of wrapping the key directly with the processed Master Password, we actually encrypt "keying material" with what is derived from the Master Password. That keying material is then hashed to produce the KEK that actually wraps the master keys.
And even more
And to add to all of these there are actually pairs of keys. We are looking at an encryption key and a MAC key. Furthermore, we also distinguish between a "master key" (well actually pair of encryption and MAC keys) and an "overview key". The overview key is used to decrypt things that get displayed in the list of items without having to decrypt the actual details of each item. Each item has its own item key (again, pair of encryption and MAC keys) which is used to encrypt the details of that item.
Anyway, these details get in the way of discussion what two factor security would look like for an encryption-based system, so I didn't bring that into the discussion.
0 -
I see, @jds8288! It appears that I went to great length to answer the wrong question. I may continue to do so.
1Password as a U2F "device"
through an exchange when you visit a website, the private key is used to prove to the website that this is the same key that was registered with your username previously. [...]
OK. So one of the questions I didn't address was whether 1Password could be made to be of more help with websites that use U2F. That is, could 1Password imitate a U2F device? I don't see answer reason why this couldn't be built into 1Password. This is similar to a common feature request of 1Password acting as a TOTP client.
So (whether or not you were asking that question) the answer is "yes". It is something we could do. As with TOTP, I am hesitant to make any promises. There is also the question of whether people should use 1Password that way, as you would be storing both your password and your "other secret" within 1Password. I would feel comfortable doing that, because I think that the benefits of a One Time Password (which both U2F and TOTP provide) is a virtue independent of any second-factor-ness.
Unlocking 1Password with a U2F device
You also say
What I was envisioning was a "secret" that achieves what a Master Password does now ("unlocks" the encryption key, k1), but is easier to use than typing out a password. So, what I am saying is, more than one way to "unlock" k1
This, I think, is more difficult. And it all comes back to the difference between authentication and encryption. U2F allows you to "prove that you possess a secret". That is great for authentication. You prove to some verifier, let's call him Victor, that you are who you say you are. In the case of things like U2F or TOTP you do so without actually revealing a secret. Once Victor is convinced that you are who you say you are (and Victor may require multiple forms of proof), Victor then makes your data available to you.
A crucial fact about such a system is that Victor has the capability of making your data available all on his own. He is not supposed to make your data available to anyone else, but he certainly has the power to. 1Password doesn't work like that. It's not that it won't unlock your data with your key, but 1Password can't unlock your data without the key.
Here are a couple of illustrations of the differences between authentication and encryption. One is about Penelope proving to Victor who she is and Victor letting her in.
The other is about having a secret that is able to transform data from a not so usable form to a usable one.
So for 1Password to behave as you describe here, it would have to store they key in a way that it can get it, but simply choose not to get it until you prove that you are around. This is how TouchID unlocking of 1Password works on iOS, but it is something that we are only willing to do in very restricted environments and through applying a number of limitations. In general, we don't to store your key in a way that 1Password (or some attacker) can get at it without you providing a secret.
But 2nd alternative factor is possible
We could get the effect that you seem to be after in a different way. Going back to my long post, we could simply make k available from the external device. (We can do this without it actually revealing its stored secret, but it still could spit out k). That is, some external device could be a substitute for typing your Master Password.
This falls into the category of something we are thinking about, but it would need to be done very very carefully.
0 -
For people who don't see what Richard is asking about, I said k₁ is derived from your Master Password, and that I said that the final decryption/encryption key, k, must be the same everywhere you need to unlock your data. But people can change their Master Passwords, so how to we ensure that we still get the same k after that?
Actually, I hadn't considered changing the master password. I was referring to the k2, derived from the 2nd factor device. Having a 2nd factor with a fixed key seems a bit pointless so you're looking at rotating OTP codes. Can that be made to work with KEK?
0 -
And so once again, I have answered the wrong question!
@RichardPayne was actually asking:
I was referring to the k2, derived from the 2nd factor device. Having a 2nd factor with a fixed key seems a bit pointless so you're looking at rotating OTP codes.
Again, very well spotted. I kinda-sorta dropped a hint about this along the way. Yes, the normal operation of most second factor devices is not useful for providing k2. So we would have to use them in an abnormal way.
Many of these things, including most Yubikey devices, will perform an HMAC operation with a secret that never leaves the device. So instead of XORing k1 and k2, what we can do is have k1 (or something derived from the password) and send that to the device to HMAC. Then we use the result of that as the actual key. This, again, is not precisely how we would do it because we want 512 bits of key material, and the HMAC built into these devices is typically SHA-256. (This might be a reason to using effectively 128 bit AES keys instead of 256 bit keys, which are perfectly sufficient.
There are a number of ways to get this all to work, but returning to what I said much further above, it would need to work the same way (that is, get the same result) on every device that you use 1Password with.
0 -
Ah ok, so it would be a fixed k2 but you effectively move the xor operation on to the device to protect k2. Makes sense.
0 -
Thanks @jpgoldberg for a very thorough reply to my question.
Admittedly, it is easy for anyone reading this to mix up these ideas. The thread was started for the idea "you need to put 2 keys in the lock to open it." but, I introduced: "well, can I use a couple different keys to open the lock?"With your answer of:
We could get the effect that you seem to be after in a different way. Going back to my long post, we could simply make k available from the external device. (We can do this without it actually revealing its stored secret, but it still could spit out k). That is, some external device could be a substitute for typing your Master Password.
Yes, the effect is the important part, not how it's implemented. Also, I'm making the assumption that having a token that you swipe, touch, etc is easier and more desirable than remembering and typing out a password. (A secret you possess rather than "know"). Folks who know more about how assessing usability should, I'd think, find out if this is the case in practice for 1Password
0 -
You are right @jds8288 that it is very easy to conflate various related issues:
Admittedly, it is easy for anyone reading this to mix up these ideas. The thread was started for the idea "you need to put 2 keys in the lock to open it." but, I introduced: "well, can I use a couple different keys to open the lock?"
And I addressed something more complicated than what you were asking for. And since I'm on a roll, I will continue to do so.
Requiring "at least n keys to decrypt"
Suppose you want to give, say, different keys to five different people and require that it takes, say, any three of the keys working together decrypt something? This sort of thing is useful for – how should I put it gently – granting access to your secrets after you kick the bucket. Or, for those times when you need manage nuclear launch codes, and other every day stuff.
Now this isn't anything we've got plans for, but if we are going to implement a system in which combined keys are necessary, then it might be useful to do so in a way that leaves us the underlying machinery to do "n of m" keys if for some reason that seems like a worthwhile feature in the future.
There are several ways to do this sort of thing. There is a system in which each of the m people get a variety of keys, with some overlap among them, but it will take at least n of them to have the right combination of keys to be able to XOR to get the actual encryption key. But there is another system which takes more computation (more than just XOR), doesn't require that each persons set of keys gets really large once you go beyond just a few people.
Suppose we plot a straight line on an x-y grid. That line will cross the y-axis at some point, which gets called the "y intercept". If all you know is a single point on the line (and that point is not the y intercept) you have no information about what the y intercept will be. There is just no way figure out the y intercept from a single point on the line.
But with any two distinct points on the line, it becomes easy to calculate the y-intercept. So if we want to give out secrets to, say, five people, and allow any two of those people working together to recover the real secret, we can pick a straight line, use the y intercept as our encryption key and give each of the five people the coordinates of one point on the line. Any two of these people can then get together and figure out actual encryption key, but one person on their own has no information about what the key might be.
What I said about a straight line requiring two points to fully determine it extends to quadratic equations (parabolas) as well. But for a parabola it takes three points to determine it. If you have only two points of a parabola, you cannot recover all of its details. But as soon as you have three points, you can fully determine the parabola and work out its y intercept. This extends to all polynomials. If you have a cubic (third degree) polynomial, it takes four points to "fit" it and then get its y intercept.
So if you want to require four people to work together to get a key, then you would used a cubic equation, take its y intercept as your encryption key, and then just give out points on that curve to various people. It would take four of them to work it out. If you want to require n people as your threshold, then you use a polynomial of degree n-1. Calculating this by hand can be tedious, but there are straightforward computer algorithms that do these nicely.
Not so real
To get appropriate properties of the key and to make sure that someone who has "almost" enough points doesn't have advantage at guessing the key we need to change this system of polynomials slightly. Instead of having these polynomials cover real numbers, we restrict them to a Galois Field. I won't go into that today.
0 -
I wouldn’t want 1Password to require two step auth from me, but it would be great if it could generate Google Auth compatible codes in the same way that Authy does. Having it all in one app would be much more convenient, even if it meant entering a Touch ID input, 4 digit pin or some other secret. Just not having to switch apps.
0 -
Hi,
I would be very interested in something like yubikey as a 2FA mechanism. I would rather not rely on google.Thanks
Iain.
0 -
I feel that Yubikey support could & should be added to 1Password (Mac Desktop) as an optional 2nd factor authentication mechanism, in the same spirit as the way 1Password for iOS uses TouchID after you unlock with the master password.
I REALLY REALLY REALLY would like to see a second factor added to mitigate the risk of brute force attacks, and I already have a Yubikey, so ... :)
0 -
@kevwil, I promise you that we are exploring ways to mitigate the risk of brute force attacks on captured data (I am not promising when or in what form such a solution might appear).
But we need it to work on all platforms. If you were to sync your data with a mobile device, would you be able to use your YubiKey there?
0 -
I fail to see why would I expect to need my Yubikey on a mobile platform, especially if I already use the TouchID option. Therefore, I also fail to see why "we need it to work on all platforms".
TouchID is specific to iOS mobile, but that didn't make the idea of integrating it into the mobile app any less valid. And the desktop app still works despite not having TouchID available.
Perhaps the question is moot, if Apple adds TouchID to the desktop hardware in the future. Until then, having the option of using a Yubikey (or other similar solutions) as a sort of TouchID for the desktop and/or 2FA, while not as convenient as TouchID, would be a very nice option.
0 -
@kevwil very reasonably asked
I fail to see why would I expect to need my Yubikey on a mobile platform,
For the answer you need to look further back in the thread on the distinction between authentication and encryption. Because 1Password works through encryption there is no "checking in with something that allows you access".
If your data is encrypted with a key that is a combination of your Master Password (K1) and some secret that comes from your Yubikey device (K2) then both secrets will be needed to decrypt that data. That is true no matter where the data is located. After all, this is exactly what we want if someone captures your data from a sync service.
It's not some software (1Password) that is granting you access to your data. Instead your secrets (your Master Password and whatever second factor secret you have) are needed to transform your data from gibberish to sensible. Some factor that just let you into the software would not actually provide meaningful protection against a brute force attack on captured data.
So some way or other, the secret (K2) that comes from the YubiKey must be available wherever you need to use your data.
0 -
What @jpgoldberg wrote is spot on. I just wanted to clarify one point in case it wasn't clear enough: Touch ID is not a second factor. This is true when Touch ID is used to unlock your device as well as when it is used to unlock 1Password. In both cases, Touch ID can be skipped altogether and either the device passcode (for your device) or your Master Password (for 1Password) can be entered all by itself: no fingerprint required.
It may not be entirely accurate to think of it as such, but you can consider it more of a "convenience" than anything else. It is more definitely not a second factor, though, since it is never required.
0 -
The way I see it (and use it) is there are already two factors involved.
Firstly, the thing I know, is the master password.
Secondly, the thing I have, is the device(s) with the encrypted password data on them.
Am I wrong in seeing it this way?
0
