U2F support for Yubikey [under consideration for memberships; not applicable to standalone vaults]
Comments
-
Hi. I'm interested in protecting my 1Password data with a U2F product like Yubikey but I don't have 1Password for teams, just the regular single user product. Will U2F be available anytime soon? I use 1Password primarily on my Mac but love having it available on my iPhone for other personal data when I'm mobile. Thanks.
0 -
Apologies for hijacking the thread. I'll start a new discussion...
0 -
Hi. I'm interested in protecting my 1Password data with a U2F product and am leaning heavily towards Yubikey. I don't have 1Password for teams, just the regular single user product (v6.3.5.635001, AgileBits Store). Will U2F be available anytime soon? And I'm curious why I would need to Duo for this type of integration? Are there any plans for full U2F integration or would 1Password always require a third party solution?
FYI, I use 1Password all day/every day, primarily on my Mac but love having it available on my iPhone for other personal data when I'm mobile. Thanks.1Password Version: 6.3.5.635001
Extension Version: 4.6.1.90
OS Version: OS X 10.12.1
Sync Type: Dropbox
Referrer: kb-search:yubikey, kb:undefined, kb-search:duo, kb:undefined, kb-search:yubikey0 -
@SaxDaddy: Thanks! I've merged your other comments into a single discussion here.
We don't currently have plans to integrate U2F into 1Password. It seems like U2F/Yubikey is a bit problematic on mobile devices, so I'm sure it's an ideal solution for 1Password. And especially using the standalone apps it isn't feasible, since there's nothing to authenticate with. But it's certainly one of the options we'll continue to consider for 1Password Teams. Thanks for letting us know you appreciate that feature! :)
P.S: I'm lovin' that that monkey! :sunglasses:
0 -
@brenty Thanks, the monkey's been my avatar for a while now. Long story...
In thinking about security after having an account hacked, I realized that 1Password is a single point of failure. While not the worst case scenario, if my master password is guessed in spite of +15 characters with a mix of numbers/letters/other, I'd be screwed. I was really hoping to protect my 1P db with U2F to make my sleep more restful. I really love your product but when everyone is out to get you, paranoia is just a practical reality! >_< :p
0 -
@SaxDaddy: You're absolutely right that that may help in some circumstances, but we also have a few important measures in place already that should help you sleep better:
- 1Password uses HMAC to protect against brute force attacks.*
- With 1Password Accounts, it is impossible to perform a brute force attack against the Master Password alone, because the Account Key is also needed to decrypt your data.
- The Master Password is chosen by you, the Account Key is randomly generated on your device locally, and neither is ever transmitted.
These are important because multifactor authentication does not strengthen the security of your data directly. For example, if someone breaks into our server or gets a copy of the database from one of your devices, they can circumvent any authentication schemes. We've chosen to build 1Password on encryption rather than authentication (and the Account Key in particular) to maintain the mathematical security of your data even in a dire scenario.
I don't say "worst case", because that would be more like "someone bad is willing to do anything to you to get your secrets". The bad news is that this makes you the weakest link in your security. The good news is that we're unlikely to be put in that position, but if we are, we'll probably be happy to hand over anything to keep our persons intact.
That got a lot darker than I intended, but hopefully that helps illustrate the current state. Various MFA can help serve as a barrier and may be something we add in the future, but for the truly paranoid, we've got you covered already. Cheers! ;)
P.S: Always happy to hear any monkey stories. :lol: :+1:
*Edit: Doh! This is a typo. It should read "1Password uses HKDF to protect against brute force attacks", and more specifically 1Password uses PBKDF2 iterations to slow down attempts at guessing the Master Password.
0 -
@brenty Thanks for that "dark" explanation and for calling me the weak link. Well played, sir!
I'd probably still like to see U2F integration so that I can use a biometric device rather than type in my increasingly complex password(s). Please let me know when the Duo functionality will be brought to stand alone 1Password. Thanks. BTW, the monkey story doesn't get told without an ample supply of intoxicants...
0 -
Thanks for that "dark" explanation and for calling me the weak link. Well played, sir!
@SaxDaddy: Dang. Wow. Sorry about that! That's pretty gross. Just to clarify, "you" (the user) applies to anyone, myself very much included! :blush:
I'd probably still like to see U2F integration so that I can use a biometric device rather than type in my increasingly complex password(s). Please let me know when the Duo functionality will be brought to stand alone 1Password. Thanks.
Oh totally! That isn't something I can promise you right now, and I think that it's important to acknowledge that in that case, it wouldn't be a second factor, since it would be in lieu of your password (similar to Touch ID on iOS). That said, it's something we may add in the future in some form. But something like that would almost certainly not be possible with the standalone apps, only the hosted version, due to the server component.
BTW, the monkey story doesn't get told without an ample supply of intoxicants...
Fair enough. Another time, perhaps! ;)
0 -
@SaxDaddy I thought the Yubikey was not a biometric device?
0 -
That's certainly technically correct. I suspect that he simply misspoke, and it's easy enough to conflate the various authentication mechanisms out there, which are manifold. ;)
0 -
Hi brenty,
Would you mind elaborating on
"1Password uses HMAC to protect against brute force attacks.
With 1Password Accounts, it is impossible to perform a brute force attack against the Master Password alone, because the Account Key is also needed to decrypt your data.
The Master Password is chosen by you, the Account Key is randomly generated on your device locally, and neither is ever transmitted."I understand what a brute force attack is, but could you maybe provide more information or a link about how HMAC protects against it.
For the 2nd bullet part about needing the Account Key, do you mean to try to brute force from a web browser or 1password 6?
3rd bullet - for the Account Key never being transmitted, isn't the Account Key sent in transmission over the internet via login in bullet point 2 (albeit an SSL connection)? Maybe to go along with this, how secure is SSL?
0 -
I understand what a brute force attack is, but could you maybe provide more information or a link about how HMAC protects against it.
I suspect that Brenty crossed a couple wires when writing that response. When you answer as many posts per day as he does, it's bound to happen. :)
I'm not entirely sure what he was referring to here, so it's difficult for me to provide more information. There's a couple different things that he could have been meaning, but I don't want to put words in his mouth.
For the 2nd bullet part about needing the Account Key, do you mean to try to brute force from a web browser or 1password 6?
There's two brute force scenarios to consider. The first is when they're attacking remotely and the attacker has nothing to start with. In this case the account key is required in order to authenticate with the server, so if an attacker doesn't have the account key they're stuck brute forcing a random 128 bit number where each try will require going through the key derivation with password + account key which uses PBKDF2 in order to purposefully slow it down.
The second is a local attack based on data in our local database. In this case an attacker wouldn't need to be brute forcing the account key, so the Master Password is what's protecting your data locally. The brute forcing attack will still be slowed down by the same key derivation but they won't have the 128bit number to guess, just the Master Password. This is why having a strong master password is still necessary.
3rd bullet - for the Account Key never being transmitted, isn't the Account Key sent in transmission over the internet via login in bullet point 2 (albeit an SSL connection)? Maybe to go along with this, how secure is SSL?
The account key is never transmitted. At most we transfer the version identifier (the A3 it starts with), and the unique identifier for it (the next few chars). The actual 128bit number is never transmitted. Authentication with the server is done without ever needing to transfer either your Master Password nor your Account Key. It works via a process called SRP. An attacker can be watching the whole sign in process as a man in the middle and yet still not obtain anything useful to their attack.
I hope this helps.
Rick
0 -
but I don't want to put words in his mouth.
What fun is that?!
I suspect that what @brenty meant was HKDF, not HMAC. In his defense wikipedia literally says "HKDF is an HMAC based key derivation function". :)
In this case the HKDF we use takes your Master Password and Account Key (and other bits of data) and from those it derives an encryption key. This process is intentionally slow by way of of PBKDF2 with a large iteration count.
Hopefully when Brenty wakes up he's not too upset by my assumption here.
Rick
0 -
@huntsin2: @rickfillion is right on. I'm surprised that this typo has survived so long. Thank you both for bringing it to light so I could fix it. How embarrassing! :dizzy:
Anyway, sorry for the confusion that must have caused you (and Rick, who probably had to re-read it a few times to be sure he wasn't going crazy). Cheers! :lol:
0 -
The first is when they're attacking remotely and the attacker has nothing to start with. In this case the account key is required in order to authenticate with the server, so if an attacker doesn't have the account key they're stuck brute forcing a random 128 bit number where each try will require going through the key derivation with password + account key which uses PBKDF2 in order to purposefully slow it down.>
What is the 128 bit number that they would be trying to brute force? And is that the same as the key derivation?
The second is a local attack based on data in our local database. In this case an attacker wouldn't need to be brute forcing the account key, so the Master Password is what's protecting your data locally. The brute forcing attack will still be slowed down by the same key derivation but they won't have the 128bit number to guess, just the Master Password. This is why having a strong master password is still necessary.>
What do you mean by local attack, someone trying to access the database that for example works at the company and has access to the network or server that it is stored on? Or do you mean someone that is trying to get access to the database from a remote location?
0 -
What is the 128 bit number that they would be trying to brute force? And is that the same as the key derivation?
The account key. Here's an example account key (anyone reading this should avoid actually posting their account key on a forum like this) :
A3-4QLNH3-QTT24Q-PKKW9-ZYZ5W-QZ959-5RQ92. TheA3part at the front just says what version of an account key this is. I think everyone with a 1Password.com account except AgileBits employees have A3 keys and some of us have the older A2 keys. The4QLNH3is a unique identifier for the key. A3 and 4QLNH3 aren't considered secrets. The rest of the keyQTT24Q-PKKW9-ZYZ5W-QZ959-5RQ92is a random number that was generated when you create your 1Password.com user account. It's created locally and never transmitted to us.What do you mean by local attack, someone trying to access the database that for example works at the company and has access to the network or server that it is stored on? Or do you mean someone that is trying to get access to the database from a remote location?
Sorry, I should have been more clear there. By local attack I mean an attack happening on your device (a Mac for example), or where an attacker has stolen the local database that exists on your device (where we store the information so that it's usable while offline). The account key (in addition to your master password) protects your data on our server. On your device where you've provided the account key already the data is protected by your master password.
Does that clear things up?
Rick
0 -
Wow, that makes things much clearer. Thank you for your reply, I really appreciate it.
I was just curious how hard it would be for someone to potentially break into an account. It seems from what you have said that unless it is some type of government agency, one's information is pretty secure.
A couple of last things.. the first is I didn't receive a notification email that you had replied to my second message..which I find kind of weird.
Lastly, the reason that I was going to post was about the original U2F YubiKey. I would like to see YubiKey work with the U2F as well. However, I would like to see it used in addition to the fingerprint or Master Password on iOS not merely as a replacement for the fingerprint or Master Password. This would require, at least for the iPhone or iPad, some kind of YubiKey that is smaller like a USB-c, which the direction I believe that Apple is going in for their future charging ports.
So I just wanted to share my hopes for potential enhancements.
0 -
I was just curious how hard it would be for someone to potentially break into an account. It seems from what you have said that unless it is some type of government agency, one's information is pretty secure.
@huntsin2: This is out of reach of even world government agencies collectively (if they worked together) given power constraints. It simply isn't feasible on a human timescale to do this. Certainly there will be advances in technology, but even as processing improves it will require sufficient power to perform a brute force attack that completes before we're all dead. And 128 is a lot of bits. ;)
A couple of last things.. the first is I didn't receive a notification email that you had replied to my second message..which I find kind of weird.
Ah, sorry. Rick didn't @ -mention you there, so if you've disabled notifications for indirect replies in discussions you're participating in you wouldn't get one in that case.
Lastly, the reason that I was going to post was about the original U2F YubiKey. I would like to see YubiKey work with the U2F as well. However, I would like to see it used in addition to the fingerprint or Master Password on iOS not merely as a replacement for the fingerprint or Master Password. This would require, at least for the iPhone or iPad, some kind of YubiKey that is smaller like a USB-c, which the direction I believe that Apple is going in for their future charging ports. So I just wanted to share my hopes for potential enhancements.
I don't think we want to count our chickens before they hatch with regard to Apple and USB-C, but we'll continue to explore other options 1Password users can use to authenticate. Thanks for letting us know! :)
0 -
@brenty @rickfillion
Thank you both for your clarifications and explanations. It actually does make me feel more comfortable with using the product.0 -
Anytime! And likewise, thanks for using 1Password! We're here if you have any other comments, questions, or suggestions. I think you can tell we love this stuff. hehe
0 -
I was able to get my YubiKey to work on my iPad, the problem is that it only works when I have an external power source connected to my Lightning to USB 2 Camera connector. I used a USB power boost cable and connected it to a USB power source.
The new Lightning to USB 3 connector has a built in Lightning socket for adding power.
Once enough power is there, the YubiKey works without problem.
0 -
That's awesome to hear @skippingrock, thank you for taking the time to share your experience here :smile: I didn't realize Apple updated the lightning to USB connector :+1: Good stuff.
0 -
Yes, and one doesn't need to be tethered to the wall, they can always use one of those USB portable power bricks that everyone has to recharge their phones on the go. So it's not completely impractical.
0 -
Good point indeed! :wink: :+1:
0 -
Hello,
I would love U2F support as well... just another measure, and believe it ought to be added. Just expressing my opinion on this topic.
Thanks.
0 -
Thanks for doing so, @nimerjaber. :)
Rick
0 -
U2F via NFC works well on Android with GSuite logins. Yubico and Feitian sell nfc capable security keys, there may be others.
-Trevor
0 -
This content has been removed.
-
It's something that we're interested in looking into. We don't have the development cycles to tackle this at the moment, but it's definitely something that we think is cool.
Rick
0 -
Glad to see it's somewhere out there on the roadmap! I was happy to see from above that it's possible to use USB u2f with an iOS device, but I keep hoping that Apple will announce support incorporating the secure element and touchID/faceID. My usability dream is seamless u2f support via an iOS device with the ability to authorize requests from my Apple Watch (just as I can approve O365 2-factor push now).
0
