Feature-Request Login with Hardware token
Hi,
it would be nice, you support Yubi Key or other U2F token for Desktop or Web Login...
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
I'd like to second this request. Just to be clear, this is how I'd like to use a U2F token with 1Password:
- Given macOS / Windows / Android with NFC / some future iOS with extended NFC access
- open 1Password app
- be prompted for my 1Password password
At this point, I would normally type in my password, or, for fingerprint reader equipped devices, tap my fingerprint.
I would, as an alternative to typing/fingerprint, like to be able to:
- computer: insert my U2F key (if not already inserted), then tap it
- phone/tablet: hold an NFC-capable U2F key close to the device
Right now, it is the computer scenario that would be most useful, as the fingerprint reader is quite convenient on mobile, but I can imagine the mobile case becoming especially interesting if iOS opens up NFC access.
Background: as someone who had their phone stolen, and then the SIM card removed and placed in another device for SMS use, I've become pretty wary of using my phone as a 2FA device and find the various Yubikey use scenarios increasingly attractive.
Thanks!
0 -
@mm2001: Thanks for reaching out! I'm sorry to hear that something like that happened to you. :(
To be clear, nothing like this is possible (without "security theater" anyway) with the standalone 1Password app using local vaults, but we're exploring options for additional authentication for 1Password.com accounts. Thanks for your feedback on this!
0 -
I am cross posting against another post here, but since this exists here I will also comment here. I would like to second/third this request. I use 1password on multiple platforms and I need hardware u2f support. Please, make this happen. NFC api support is now possible with yubico and apple, as well as other platforms. Its a developing area but still.
0 -
I want MFA to avoid typing the master password in hostile environments, in addition to TouchID. Not instead of TouchID, and not when using the master password, only as an additional factor with TouchID/FaceID/etc e.g. via U2F challenge-response
Master password is easily observed. TouchID and FaceID can be fooled. Multi Factor Authentication seems like an improvement, once you understand how it works. We’ve had many threads over the years requesting Yubikey support, but it seems like AgileBits reps haven’t all understand the options and implementation choices available with this tech, and it keeps getting dismissed or deprioritised?
0 -
@niallyoung - If you’ve scoured these forums enough to have read the various threads we've had on hardware tokens (e.g. Yubikey) over the last couple of years, then you're already familiar with our thinking on the topic, so I won't rehash it here, except to say two things. The first is that we continue to survey the security landscape because it's always changing, and what's a good idea today might be less so tomorrow - or vice versa, depending on how things change. And the second thing is to note that on Mac and PC, your Master Password is never visible at all, and on mobile 1Password (iOS and Android) the letters are quickly obfuscated. If you or any other user is in an environment so hostile that you suspect adversaries of actively "shoulder surfing" you or even trying to video record your keystrokes or what's on your screen, our recommendation would be not to use 1Password or any other critical application under such conditions. Like texting while driving, "it can wait." Security is not a product you purchase (not even 1Password); it's a process we each undertake daily, a set of best practices to do - or, in some cases like this, to NOT do - to keep ourselves secure.
0 -
I want MFA to avoid typing the master password in hostile environments, in addition to TouchID. Not instead of TouchID, and not when using the master password, only as an additional factor with TouchID/FaceID/etc e.g. via U2F challenge-response
@niallyoung: It sounds like you're saying you want to both not use Touch ID and also not enter your Master Password, and that isn't going to happen. The Master Password is needed to decrypt the data. U2F/2FA/etc. are not and cannot be a substitute for that. You'll still need to enter it. I know you also said "only as an additional factor", but that contradicts "I want MFA to avoid typing the master password in hostile environments". There also cannot be a "challenge-response" if you're offline. Are you okay with not being able to access 1Password in that case?
Master password is easily observed.
That's not a given. There are certainly measures you can take:
It may come off as a bit comical, but Snowden was dead serious and you should be too if you're in a hostile environment and/or believe you may be a target for attack.
TouchID and FaceID can be fooled.
That's a bit glib. The reality is that for most people this is not a real threat. But certainly if your threat model is different you need to take that into account. For example, if you're potentially a target of nation states or other attackers, you should probably not use biometrics. They don't need to be "fooled" at all; they just need you.
Multi Factor Authentication seems like an improvement, once you understand how it works. We’ve had many threads over the years requesting Yubikey support, but it seems like AgileBits reps haven’t all understand the options and implementation choices available with this tech, and it keeps getting dismissed or deprioritised?
How so? You seem to be ignoring the fact that we've supported Duo multifactor authentication for a fairly long time now, which Jacob mentioned it above in this very discussion. You may want to check out what we already offer with 1Password Teams and Business accounts:
1Password multi-factor authentication
Duo was in beta for a long time, and the development of our own two-factor authentication was a long project as well, because we're not going to roll out anything hastily, especially when it can, by design, prevent a person from accessing their own account. A hardware "key" the can be lost, stolen, destroyed, or simply stop functioning is a harder sell for us, but there's probably been nothing stoping you from using it yourself already indirectly for a while now as I believe Duo supports it. Have you looked into that?
0 -
@niallyoung: It sounds like you're saying you want to both not use Touch ID and also not enter your Master Password
No.
I know you also said "only as an additional factor", but that contradicts "I want MFA to avoid typing the master password in hostile environments".
No it doesn't. As I said above, I'd like to use TouchID + Yubikey, instead of the master password (and instead of TouchID alone).
There also cannot be a "challenge-response" if you're offline.
Incorrect. e.g. https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html#expanding-u2f-to-non-browser-apps "it is perfectly sensible to have app on a mobile OS such as Android talk to U2F devices over a system API". There are many options here, Yubikey does not do 1 function or 1 protocol, or only have 1 use-case.
Master password is easily observed.
That's not a given.
It's simply a fact.
There are certainly measures you can take:
Off-topic for a feature request thread.
TouchID and FaceID can be fooled.
That's a bit glib.
It's a well documented fact.
Multi Factor Authentication seems like an improvement, once you understand how it works. We’ve had many threads over the years requesting Yubikey support, but it seems like AgileBits reps haven’t all understand the options and implementation choices available with this tech, and it keeps getting dismissed or deprioritised?
How so?
Well this thread is a great example: two AgileBits reps have jumped on my post to reply, without really addressing what I posted but you've both managed to distract from what your Customers are saying and requesting. You're not listening, particularly on the topic of Yubikey support, and you don't appear to understand the technology, or what your Customers want.
You seem to be ignoring the fact that we've supported Duo multifactor authentication for a fairly long time now
Duo != Yubikey.
This is really frustrating. I'll try again next year!
0 -
No it doesn't. As I said above, I'd like to use TouchID + Yubikey, instead of the master password (and instead of TouchID alone).
@niallyoung: Touch ID doesn't allow anything like that to be used in conjunction with it. When your fingerprint is recognized, that unlocks a cryptographic secret stored in the Secret Enclave which can then be used to decrypt your encrypted Master Password stored in the Keychain, which in turn decrypts your data. How do you propose to have a hardware token also be used in that process?
Incorrect. e.g. https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html#expanding-u2f-to-non-browser-apps "it is perfectly sensible to have app on a mobile OS such as Android talk to U2F devices over a system API". There are many options here, Yubikey does not do 1 function or 1 protocol, or only have 1 use-case.
Thanks for clarifying what you meant.
Master password is easily observed.
That's not a given.
It's simply a fact.
There are certainly measures you can take:
Off-topic for a feature request thread.
Why did you bring it up then? That's a bizarre thing to say, considering that this is not a discussion about what you're asking for: Yubikey + Touch ID. Just keep in mind that if your adversaries include government agencies, that still won’t be your ticket to crypto-paradise.
Well this thread is a great example: two AgileBits reps have jumped on my post to reply, without really addressing what I posted but you've both managed to distract from what your Customers are saying and requesting. You're not listening, particularly on the topic of Yubikey support, and you don't appear to understand the technology, or what your Customers want.
No need to be rude. No one is jumping. Still waiting for you to explain how you'd like us to implement Yubikey + Touch ID. It's an interesting idea. I'm just not sure how what you're proposing is technically feasible. Maybe there are some important details you're leaving out.
Anyway, you've asked us to implement a new feature for you, and we've said we'll consider it. It just doesn't seem possible in the form you're requesting though.
Duo != Yubikey.
I didn't say those were the same thing.
This is really frustrating. I'll try again next year!
It might be worth checking out. Take care.
0 -
I have to comment here. TouchID + Yubikey is a VERY valid use case. You are correct that TouchID does not allow for a second factor. But an App can require a second factor. Now that Apple has sorta opened up NFC on newer iPhones, that is possible (see this blog post: https://www.yubico.com/2017/10/iphone-support-yubikey-otp-via-nfc/). Also now that FIDO2 has going into final draft, and is expected to be ratified "any day now", the expectation is that Apple will soon provide FIDO2 (and by way of backward compatibility, U2F) support soon for it's ecosystem.
As for Duo vs. Yubikey. I am VERY familiar with both solutions. Duo is a GREAT MFA tool, but it cannot provide strong, cryptographic MFA in accordance with NIST SP800-63 revision 3. To get to Authenticator Assurance Level (AAL) 3, a cryptographic hardware token is REQUIRED (see NIST SP800-63B for a better understanding).
Bottom line, in todays world, MFA is a requirement. Also, a cryptographic hardware token is, by far, the most secure way to implement MFA. That really leave two options, X509 certs (ie. Smartcard mode) and FIDO2/U2F. This is not a difficult implementation, many 1Password competitors have done it.
I, for one, have been asking for true MFA in 1Password for at LEAST 5 years. It is VERY, VERY frustrating that AgileBits keeps saying that it's not needed and the Account Secret Key is good enough. That is simply not true. A separate hardware device is the new reality.
I am a BIG 1Password fan. Have been a customer for 10+ years. It's getting harder and harder each year to stay with 1PW. There are just to many viable options out there now.
0 -
I have to comment here. TouchID + Yubikey is a VERY valid use case. You are correct that TouchID does not allow for a second factor. But an App can require a second factor. Now that Apple has sorta opened up NFC on newer iPhones, that is possible (see this blog post: https://www.yubico.com/2017/10/iphone-support-yubikey-otp-via-nfc/). Also now that FIDO2 has going into final draft, and is expected to be ratified "any day now", the expectation is that Apple will soon provide FIDO2 (and by way of backward compatibility, U2F) support soon for it's ecosystem.
@jsfrederick: That's very helpful! Thank you! :)
I have to say it's a bit of a non-starter if it can't be used with platforms that most of our customers depend on though. :(
As for Duo vs. Yubikey. I am VERY familiar with both solutions. Duo is a GREAT MFA tool, but it cannot provide strong, cryptographic MFA in accordance with NIST SP800-63 revision 3. To get to Authenticator Assurance Level (AAL) 3, a cryptographic hardware token is REQUIRED (see NIST SP800-63B for a better understanding).
That's a fair point, but most of our customers are looking for temporal authentication measures, which both Duo and our own TOTP-based authentication provide. The Secret Key (née Account Key) fills a very specific role: it is used to actually encrypt the data, so it protects users against brute force attacks in the case of a server breach.
Bottom line, in todays world, MFA is a requirement. Also, a cryptographic hardware token is, by far, the most secure way to implement MFA. That really leave two options, X509 certs (ie. Smartcard mode) and FIDO2/U2F. This is not a difficult implementation, many 1Password competitors have done it.
I, for one, have been asking for true MFA in 1Password for at LEAST 5 years. It is VERY, VERY frustrating that AgileBits keeps saying that it's not needed and the Account Secret Key is good enough. That is simply not true. A separate hardware device is the new reality.I have to disagree with you on the "separate hardware device is the new reality" point. That may be true for you, but hardware tokens are not mainstream by a longshot. Certainly in certain circles they're ubiquitous (I've always thought that Yubico's and the Yubikey's name was play on that), but even in enterprise — which is our target for multifactor authentication, they are not. So it's good to hear from folks with (presumably) a different use case.
I am a BIG 1Password fan. Have been a customer for 10+ years. It's getting harder and harder each year to stay with 1PW. There are just to many viable options not there now.
Interesting. First, thanks for your support! Can you tell me more about what's "viable" for you though, and why? What is the specific role that you'd like Yubkey to fill for you with 1Password? Are we talking account access, device setup, or do you want to have to authenticate any time you unlock the app? And what are the types of threats you're trying to defend against? Thanks! :)
0 -
Thank you all. And your requests have been noted.
Diminished objections to Yubico integration
- Yubico and other hardware token perform U2F (which addresses some very serious problems with previous schemes)
- These integrate with more client platforms (mobile, desktop, web) then previously.
- There is an authentication component to 1Password (so there is some authentication that a second factor could be added to)
- There is a lot of pressure for such a feature. Even if it adds no real security, are we acting in our (potential) customers' security interests if they end up using a less secure system just because that alternative has such a feature?
there would be some actual security benefit to its use with 1Password. But it could never safely replace the need for your Master Password. And this is for reasons we've spelled out many many times.
It could be used meaningfully to bolster an already strong authentication component. This would be of most benefit for new device sign-in. In other cases, it would only really do any good if off-line use of 1Password were disabled.
The chief difficulty
The difficulty remains that we have to do this in a way that isn't mere security theater. That is, we need to do it in a way in which its use doesn't imply security properties that it doesn't really have. We don't want to do what some others do, which is to offer apparent 2FA without it actually doing anything. Or if we have to do things that way, then we will have to find a way to communicate to the user that the hardware 2FA doesn't actually offer the security it might first appear to.
But hardware authentication factors look cool. And for some security architectures they add real security. So naturally people believe that it would add meaningful security to an e2ee password manager even when they don't. We get that. So we have to find a way to do what people want without misleading them about the actual security properties. It also will be tricky to make it offer some meaningful security without people being locked out of their data if they lose their device.
0 -
Even if it adds no real security, are we acting in our (potential) customers' security interests if they end up using a less secure system just because that alternative has such a feature?
I'll be blunt, this is a prime example of the arrogance of AB on this topic going back YEARS. NO crypto is perfect and NO security plan is perfect. They can and will be hacked or broken, the only question is when. The answer is defense in depth or layers. The more actions a hacker or bad guy needs to take to get to my data, the better.
If someone gets to my laptop, and has my master password, they can get into my 1PW desktop. They can also get into my 1PW family web account. If I have a second factor that is an external hardware device, then this is not an issue. YES, this IS valid use case. And, yes, the is also a problem with my security posture. Having that defense on depth is always a good idea.
we will have to find a way to communicate to the user that the hardware 2FA doesn't actually offer the security it might first appear to.
Do you REALLY believe this? If so, that shows you don't really understand what this request is about. Sure, your security architecture of a master password and secret key is GREAT for encrypting the password store. This is all about access. If someone has the opportunity to access my date by the unfortunate nature of having my account key and Master PW, then I am scr**ed! If I needed an external device, preferably a hardware token like the Yubikey, then it must presented to log into my 1PW account/datastore. Again, no one solution is perfect. We need a layered defense strategy
Look at the U2F protocol. REALLY look at it and read it. It offers a lot of additional features such as origin checking. If someone was to put up a fake website that LOOKS like the 1PW website, using U2F would catch that and disallow the authentication. The AppID's would not match and would be caught during the crypto exchange. There are some other optional features such as token binding that also come into play.
As for the desktop client, yes that is a different animal. Maybe some kind of OTP, such as YubicoOTP would be better suited for that, again using a separate hardware token.
Bottom line? Stop telling me what YOU think I should do. Stop telling me what YOU think is best for me. Take off your blinders and open your mind to options. Look at and study options like U2F and really understand what they bring to the table. U2F is relatively easy to implement for web applications, while providing TREMENDOUS benefit (albeit for web apps right now).
0 -
Touch ID doesn't allow anything like that to be used in conjunction with it. When your fingerprint is recognized, that unlocks a cryptographic secret stored in the Secret Enclave which can then be used to decrypt your encrypted Master Password stored in the Keychain, which in turn decrypts your data. How do you propose to have a hardware token also be used in that process?
It just doesn't seem possible in the form you're requesting though.
How you guys choose to implement it is really up to you, but it sounds like you guys are over complicating this or still don't understand the technology.
Here's one very simplistic view of what is possible:
if (master password successfully entered) { unlock() } else if (TouchID authenticates) { if (Yubikey U2F challenge-response Setting is not enabled) { unlock() } else if (Yubikey U2F challenge-response is successful) { unlock() } }i.e. local U2F challenge-response between the App the the Yubikey, nothing online. TouchID is used as normal, so the Yubikey has nothing to do with retrieving the encrypted master password, offline or online. Multi Factor Authentication. Does that make sense?
No-one is suggesting to use the Yubikey for encryption, we're requesting that it be enabled for 2FA/MFA. Authentication. No-one here seems to be requesting that this feature be online only, or to only work with your charged service 1Password Vaults, but I appreciate where you're coming from. That's not a constraint that your Customers are asking for, we're suggesting a standalone App feature. No-one wants any security theatre. No-one wants to be locked out of their device if they lose their hardware token (this is what the master password is for, so this makes no sense as it's not involved with a Yubikey).
Every possible complication or obstruction seems to be raised in these threads by AgileBits reps, time after time. Every possible misinterpretation seems to be pursued, rather than the plain English that we've posted, with AgileBits reps asking us to clarify again and again, or answer unrelated questions, or taking us off onto all of these tangents and exploring potential ways that this cannot work, rather than talking to us sensibly about how this can work.
Regardless, it's a feature that we clearly want, and without access to the source only you guys can come up with an implementation that does not decrease or invalidate the security of your product, and your customers. No-one here is asking that you compromise anyone's security. It's not as difficult as you all seem to be making it, but all of these distractions and unrelated tangents, and having to repeat ourselves and "clarify" previous posts with obvious and clear meaning, in every single thread about Yubikey over the last 4+ years .... it's not good Customer Service. Your competitors are having no problem incorporating this technology into their products, and any competent engineer should be able to figure out how this could work with your product.
Just look at the responses you're getting here in this thread, and in all of the previous threads on this topic! It's beyond a joke, everyone here is clearly very frustrated at not being listened to and taken seriously. I'd think about training up all reps with some basic Customer Service skills, or hire some people who specialise in this aspect of business.
0 -
I'll be blunt, this is a prime example of the arrogance of AB on this topic going back YEARS. NO crypto is perfect and NO security plan is perfect. They can and will be hacked or broken, the only question is when.
@jsfrederick: That's a very arrogant position. But if you can back that up, we'll make it worth your while.
The answer is defense in depth or layers. The more actions a hacker or bad guy needs to take to get to my data, the better.
1Password's security doesn't depend on the bad guys not getting your encrypted data. That wold be negligent.
If someone gets to my laptop, and has my master password, they can get into my 1PW desktop. They can also get into my 1PW family web account. If I have a second factor that is an external hardware device, then this is not an issue.
That's simply not true. At that point, they can get whatever they want from you; they don't even need to be able to sign into your account.
YES, this IS valid use case. And, yes, the is also a problem with my security posture. Having that defense on depth is always a good idea.
Agreed.
we will have to find a way to communicate to the user that the hardware 2FA doesn't actually offer the security it might first appear to.
Do you REALLY believe this?
Yes.
If so, that shows you don't really understand what this request is about.
You will find it otherwise. Your comments above about a second factor protecting you if the machine where you access all of your accounts and sensitive data will protect you is a perfect example illustrating Goldberg's point.
Sure, your security architecture of a master password and secret key is GREAT for encrypting the password store. This is all about access. If someone has the opportunity to access my date by the unfortunate nature of having my account key and Master PW, then I am scr**ed! If I needed an external device, preferably a hardware token like the Yubikey, then it must presented to log into my 1PW account/datastore. Again, no one solution is perfect. We need a layered defense strategy
1Password doesn't depend on "access" for its security. If it did, then you'd be 100% correct: you if someone were able to steal your database, it would be game over for you. Fortunately that's not the case. 1Password is designed with the assumption that someone will steal it, either from you or from us. So it needs to withstand attack even in that case. A second factor could prevent someone from making a sign in attempt, but in your own proposed attack scenario, they don't need to; you've already got the encrypted data on your laptop. So at that point, a second factor doesn't make a difference. They still need to do one of two things:
- Brute force their way into it — infeasible even if only your Master Password were needed, provided it's strong; the Secret Key is icing on the crypt cake, and designed to protect you against a breach of our server; or...
- Capture your data as you access it — it has to be decrypted, by you, for you to use it after all.
When they have control of your laptop, why even bother with a interminable attempts to brute force the data when they can get you to unlock it for them? It would be stupid of us to assume that the attacker will be stupid.
Look at the U2F protocol. REALLY look at it and read it. It offers a lot of additional features such as origin checking. If someone was to put up a fake website that LOOKS like the 1PW website, using U2F would catch that and disallow the authentication. The AppID's would not match and would be caught during the crypto exchange. There are some other optional features such as token binding that also come into play.
As for the desktop client, yes that is a different animal. Maybe some kind of OTP, such as YubicoOTP would be better suited for that, again using a separate hardware token.You're not wrong, but you're completely missing the point. All of that is to prevent someone from getting access in the first place, but you've already said they have control over your laptop. All of this is irrelevant in that scenario. It's just a matter of them either brute forcing or letting you hand stuff over to them. Which would you choose?
Bottom line? Stop telling me what YOU think I should do. Stop telling me what YOU think is best for me. Take off your blinders and open your mind to options.
I'm not sure you understand. You're imagining things. What you do is your business. And I encourage you to take into consideration that the benefits of a second factor aren't relevant to the threats you're trying to defend against, which you've described above.
Look at and study options like U2F and really understand what they bring to the table. U2F is relatively easy to implement for web applications, while providing TREMENDOUS benefit (albeit for web apps right now).
They do offer benefits. You're arguing with some imaginary person whom you think says they don't. They offer a tremendous benefit for accounts when access is effectively the only security, but that simply isn't how 1Password works, or ever has. They don't offer a protection against the threats you've outlined. :(
0 -
No-one is suggesting to use the Yubikey for encryption, we're requesting that it be enabled for 2FA/MFA. Authentication. No-one here seems to be requesting that this feature be online only, or to only work with your charged service 1Password Vaults, but I appreciate where you're coming from. That's not a constraint that your Customers are asking for, we're suggesting a standalone App feature. No-one wants any security theatre. No-one wants to be locked out of their device if they lose their hardware token (this is what the master password is for, so this makes no sense as it's not involved with a Yubikey).
@niallyoung: Thanks for clarifying. We're mostly in agreement, but here's the fundamental problem: if there's a way for the user to "reset" or something to regain access even if the hardware token is lost, it's value as an additional layer of security is questionable. That's how most multifactor authentication "works", and that does generally amount to security theater, as that can also be leveraged by an attacker to get around that requirement.
Every possible complication or obstruction seems to be raised in these threads by AgileBits reps, time after time. Every possible misinterpretation seems to be pursued, rather than the plain English that we've posted, with AgileBits reps asking us to clarify again and again, or answer unrelated questions, or taking us off onto all of these tangents and exploring potential ways that this cannot work, rather than talking to us sensibly about how this can work.
I suggest re-reading.
Regardless, it's a feature that we clearly want, and without access to the source only you guys can come up with an implementation that does not decrease or invalidate the security of your product, and your customers. No-one here is asking that you compromise anyone's security. It's not as difficult as you all seem to be making it, but all of these distractions and unrelated tangents, and having to repeat ourselves and "clarify" previous posts with obvious and clear meaning, in every single thread about Yubikey over the last 4+ years .... it's not good Customer Service.
You seem to think that customer service is about saying "yes" to every request. If we did that, none of us would be here. 1Password would be unusable for all of us. Some suggestions are good ones, some mediocre, and some are downright awful. But for the most part, every one has a kernel of a great feature, but with a lot of messy stuff stuck to it. I know because you want this feature so badly it's probably easier for you to gloss over that, but it's our responsibility to see the problems that can be caused by proposed "solutions". I don't mean that derisively: unless those can be worked around, they're not really solutions at all, not for most people. So, no, we're not going to add Yubikey support to 1Password until we can do so in such a way as to offer a real security benefit that anyone can use (whether or not they choose to) without causing more issues. Maybe that's a clever technical solution. Maybe that's presentation. Often it requires both.
But regardless, if you look at all of our "second factor" feedback over time (you can forget "4 years", because 1Password.com memberships haven't been around for that long, and there is no means to perform "authentication" with local vaults), you'll see that the vast majority of it is for a non-hardware-based solution, which we've implemented. You could actually use a dedicated device for that if you wish, and that would give you similar properties to what you're asking for. But you're asking us to develop, test, and support an additional feature with limited security benefit and even more limited usefulness, as far as most everyone not-you is concerned. We need to focus on making sure 1Password is secure given the ways people actually use it, and since most people are not going out and buying Yubikeys today that can't be a priority even if we added support for it, as 1Password still needs to be secure for everyone else too.
Your competitors are having no problem incorporating this technology into their products, and any competent engineer should be able to figure out how this could work with your product.
I think probably anyone can. There's a lot of great example code for integrating Yubikey and other hardware tokens into both native and web apps. But if you think we thoughtlessly pile on features without vetting them thoroughly — mind you, I'm not talking about Yubikey in particular, but anything we use to augment 1Password, which has very different considerations to most apps, including competitors — then you just don't get it. A lot of people appreciate that, but if you don't, and getting feature X in Y is more important to you, you may be better served by another product that meets your specific requirements. We'd rather you use something else than nothing at all.
Just look at the responses you're getting here in this thread, and in all of the previous threads on this topic! It's beyond a joke, everyone here is clearly very frustrated at not being listened to and taken seriously. I'd think about training up all reps with some basic Customer Service skills, or hire some people who specialise in this aspect of business.
We listen and take everyone's comments, suggestions, and feedback seriously; but if the only way you're going to believe that is if we do whatever you demand, then I can't help you with that. :(
0 -
You seem to think that customer service is about saying "yes" to every request.
@brenty your replies here make extensive use of strawmen, red herrings and other fallacious arguments. This is what I'm referring to when I suggest improving Customer Service - i.e. how you are responding and treating your customers here in this thread, and previous Yubikey threads. Your attitude and style of communication is concerning, but repeatedly misinterpreting what we are saying, putting words (or apparent rationale) into our mouths isn't helping you, or us. Potential, new Customers could be reading this - what do you want them to think? Spend their money elsewhere..?
If you're unable to respond politely, without this passive aggressive tone, without having to repeatedly clarify and argue about every possible, imaginary scenario (rather than what is being actually requested and written by us), without employing fallacious logic and rhetorical language ... then quite simply you are doing "Customer Service" wrong.
Ask yourself: why are we getting so frustrated here, and in every other Yubikey thread over the last 4+ years? Is there a pattern? Is there something that you could be doing better?
if there's a way for the user to "reset" or something to regain access even if the hardware token is lost
No-one has suggested or requested this. This implies an online service, which I've specifically stated that I am not interested in. Authentication does not imply authentication of the Vault, it can also used to authenticate the User or the Device. The Master Password always works, so access is never lost - nothing needs to be reset. I appreciate your subscription 1Password Vaults bring in more revenue for you, so obviously it's in your interest to make new features work with this, or exclusive to your storage service. That's not what I'm asking for, as I've repeatedly stated.
TouchID is a great convenience, and helps to protect my Master Password from observation. The Master Password needs to be protected. TouchID can be defeated by amateurs with a very small budget. Now FaceID can too. I'd like to keep the convenience of TouchID / FaceID, but with better security than is possible today. A U2F challenge-response via Yubikey, in addition to TouchID, seems like a great solution.
You seem to have a very narrow view of what is possible here, and add all sorts of assumptions to what we are actually saying - looking for reasons that this can't work by re-defining our points into strawmen that you can then easily knock down. I don't believe this is deliberate, on your part, but that's the end result. It's really frustrating for us.
This is probably the 15th or 20th thread requesting Yubikey support over the last 4+ years, that I've seen. There are better ways to measure your Customer's satisfaction, and for Customers to request features and improvements, than this discussion forum. All of the other threads have disappeared, yet we keep creating new ones requesting Yubikey support. It seems to be one of the more popular requests. How popular is it? How many of your existing Customers would like this feature? How many new/potential Customers would like this feature? What's the actual, measured cost:benefit? It doesn't sound like you guys are in a position to answer any of these questions, and the only "data" we have here are our repeated, regular requests for Yubikey support - in which we are shot down, distracted, misrepresented, or misunderstood.
Your product's great, I love it, but this 1 small feature would be a game changer for many of us. Perhaps it's way down at the convenience end of the security spectrum, and it doesn't add the level of additional security that you guys would prefer, but it's still something that your Customers want, your Competitors are implementing, and pretty soon the entire Market will be demanding.
0 -
Potential, new Customers could be reading this - what do you want them to think?
That 1Password is secure because its team judiciously engages in effective security measures instead of pursuing methods that are less effective or even counterproductive, just because they're popular with some folks. And also that the success of our efforts can be measured by noting we've had zero instances of encrypted data breaches of 1Password in more than twelve years.
You say elsewhere that you've been following "previous Yubikey threads," so you're likely already aware of our position on it. In fact if you're following all of the threads, then you will notice us repeating ourselves quite a bit, because we seem to be getting asked the same question multiple times - and we do want to give a full answer to each user who asks. If you're noticing a bit of frustration creeping into some of those replies, I sincerely apologize.
It seems to be one of the more popular requests. How popular is it? How many of your existing Customers would like this feature? How many new/potential Customers would like this feature?
My guess would be significantly fewer than it sounds as if you may be imagining. Speaking as someone with access to all of our contact channels (not just this forum), I can tell you that the majority of the newer users finding their way to our digital doorway these days tend to be less like the early adopters who've been around for years in that they're not security people, tech enthusiasts, developers or the like. Many don't have any idea what a Yubikey even IS, let alone a nuanced understanding of the ways in which it is beneficial and the ways in which it is not. But they keep seeing news about password breaches and they also keep hearing more about password managers. In short, they just want increased security.
More to the point, customer requests are not our primary method for determining if a feature will make it into 1Password. It's certainly a factor, but there are so many other things to be considered when determining what goes into our product that gathering data on every feature request is not feasible or useful. Yubikey does seem rather popular with a small segment of users in this forum, but I can tell you that we don't hear requests for this from many users outside these forums.
I mentioned in previous replies in this thread both that the security landscape is constantly evolving and also that therefore, our own individual security process should evolve as well. That's worth repeating here: it's why we rarely slam the door on ideas with a cold "no" -- for that very reason. So I won't say Yubikey support will never happen be part of 1Password even if I think it remains unlikely from the vantage point of today, because things can change based on circumstances changing. What I will say is that as things stand now (and you'll agree if you're taking an honest read of the multiple threads here started infrequently but regularly by a comparatively small but very vocal group of hardware token devotees) is: we've heard you. The Yubikey case has been made many times - often by many of the same people - with variations on the same supporting arguments. So, if your goal was to make your wishes known -- that you'd like this feature -- good news: you've done so! :)
If Yubikey support is a game-changing feature for you, then I'm sorry that I can't give you a better answer right now. If 1Password isn't for you (general you), we'll be happy as long as you're using something, instead of Post-It notes or reusing passwords.
0 -
It's no longer only about Yubikey: https://www.theverge.com/2018/7/25/17613332/google-titan-security-key-login-2fa
0 -
Google's move to push MFA hardware has some of us enterprise customers giving the technology another look. As long as we're likely to pass out hardware for use with G Suite, we're looking at which vendors support it for other uses.
Searching for which password managers support FIDO/U2F was what brought me here today. It would be great to hear that FIDO/U2F support is on your roadmap. I'm trying not to inflict the sadistic UI of your main competitor on more teams than I have to. ;)
0 -
Welcome to the forum, @mcgroarty! Yep, we're keeping track of the Titan developments as well. BTW, if you haven't seen it yet, we did recently add Yubikey support for authenticating to 1password.com accounts. I suspect we'll add Titan key support as well once we're able to get a better look at them, though don't take that as an announcement or promise. :)
0 -
[Question retracted after reading the whole thread and realising that I can't add anything of value here. Feel free to delete this if you are able - I cannnot it seems.]
0
