That's not how 2FA works(shkspr.mobi)
shkspr.mobi
That's not how 2FA works
https://shkspr.mobi/blog/2021/01/thats-not-how-2fa-works/
268 comments
2FA absolutely will protect you from a phishing site using the password it stole.
Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.
Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.
Not all 2nd Factor solutions allow stealing the 2nd factor.
Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means:
- The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an state actor or similar.
- The attack needs to be live in the sense that password and 2FA auth needs to be directly forwarded to the attacked web-application and there it needs to trick any bot detection to make it believe it's not a bot. This also means even if they phish your authentication they only can use it once at the moment they phished you. But to e.g. then to disable U2F they often need to enter another password, so they need to phish you twice in a row, which is harder, but only slightly harder, tbh.
- Alternatively they might hack the service and get their hands on the private webcertificate and clients private key if the service doesn't use a HSM for that. But that is normally much harder and for many attacks unfeasible (and there is normally little reason to phish if you can hack a server that deeply).
Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means:
- The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an state actor or similar.
- The attack needs to be live in the sense that password and 2FA auth needs to be directly forwarded to the attacked web-application and there it needs to trick any bot detection to make it believe it's not a bot. This also means even if they phish your authentication they only can use it once at the moment they phished you. But to e.g. then to disable U2F they often need to enter another password, so they need to phish you twice in a row, which is harder, but only slightly harder, tbh.
- Alternatively they might hack the service and get their hands on the private webcertificate and clients private key if the service doesn't use a HSM for that. But that is normally much harder and for many attacks unfeasible (and there is normally little reason to phish if you can hack a server that deeply).
> Not all 2nd Factor solutions allow stealing the 2nd factor.
The second half of the article goes into detail about the shortcomings of U2F (using "Yubikeys" as it's terminology)
The second half of the article goes into detail about the shortcomings of U2F (using "Yubikeys" as it's terminology)
The article's first and most prominent criticism is that it costs at least $30-$60, which might be a barrier to mass adoption but for most HN readers is not a serious reason not to use it.
I own two (one as a backup in my safe in case I lose this one. They all have the same TOTP stuff and setup in every service side by side where possible), to agree with you. Though it’ll be lovely when your iPhone can be a U2F key through their hardware security chips and some OS support, if I’m dreaming out loud.
Have I got good news for you: https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-... - ICYMI WebAuthn is the successor to U2F.
I do like phones are building in these keys, it makes them way more accessible to the general population, and generally not a pain to use. And then those of us with physical keys get better support too :)
And the third is that they leave their keys in their coat. When I’m at home, I leave my keys (and therefore my yubikey which is on my key ring) on my desk and when I’m out, I always keep them on my person and never unattended.
So that leaves ease of setup and support. Since setup only has to be done once per site, and I only bother with important sites, that’s not a major deal for me either.
So that leaves ease of setup and support. Since setup only has to be done once per site, and I only bother with important sites, that’s not a major deal for me either.
U2F is so infrequently used on public sites compared to SMS and TOTP. Of the things I use regularly, that arn't for work, that have a 2FA option - I think two (Google, and my password manager) supports U2F.
For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again.
For all but the most attentive folks - getting a "Whoops, try again" error when authenticating is probably going to be a semi-regular occurrence anyhow, so adding a fake one in there probably won't trigger any mental alarms.
For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again.
For all but the most attentive folks - getting a "Whoops, try again" error when authenticating is probably going to be a semi-regular occurrence anyhow, so adding a fake one in there probably won't trigger any mental alarms.
Yeah, I really wish more things worked with U2F. I especially hate when I enable U2F on a site it works on (Twitter) and then every time I log in it does an sms code anyway, even though I have U2F enabled and would much prefer to use it, but like having my phone number as a recovery backup.
> Not if it also steals the 2nd factor.
In Webauthn/u2f the 2nd factor is a proof that is unique against the particular site. So stealing the 2nd factor is significantly more difficult since it requires compromise of the computer/endpoint used to access the site to pass the wrong site to the hardware token, or cloning the physical device which should be tamper resistant (but not totally unheard of to clone some devices).
Your statement is true for HOTP/TOTP based 2nd factor like google authenticator on a phone, although the stolen credentials shouldn't provide persistent access.
And password re-use is still a problem if every service isn't covered by Fido2, but we need to start somewhere.
In Webauthn/u2f the 2nd factor is a proof that is unique against the particular site. So stealing the 2nd factor is significantly more difficult since it requires compromise of the computer/endpoint used to access the site to pass the wrong site to the hardware token, or cloning the physical device which should be tamper resistant (but not totally unheard of to clone some devices).
Your statement is true for HOTP/TOTP based 2nd factor like google authenticator on a phone, although the stolen credentials shouldn't provide persistent access.
And password re-use is still a problem if every service isn't covered by Fido2, but we need to start somewhere.
> persistent access
Given a successful login and session, perhaps on some sites this is enough for passwords reassign via some backend (likely intended for mobile apps) API?
Given a successful login and session, perhaps on some sites this is enough for passwords reassign via some backend (likely intended for mobile apps) API?
> The solution is to go only to the right site.
i.e. blame the victim. This generalizes to: the solution to user error is for the user not to make errors.
So no, that is not the solution.
i.e. blame the victim. This generalizes to: the solution to user error is for the user not to make errors.
So no, that is not the solution.
Well, name one error that persists despite not making the error, and you can definitely say I'm wrong. But that wasn't the point. The solution is to go to the right site. You were supposed to use your imagination to come up with ways that might be caused to happen. The article and commenters here suggested password managers that discriminate between the right site and the wrong site, that's an example. "OH SURE BLAME THE VICTIM FOR NOT INSTALLING A PASSWORD MANAGER!" If you're looking for a solution that doesn't whatsoever require the participation of the user, you may meet with some degree of disappointment.
There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.
There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.
Actually better education and training is often the only real solution. It isn't "victim blaming" if the situation is at least theoretically within the victim's control. If some random "plumber" that I didn't call for shows up at my house, asking to be let in to replace some of my pipes, and I say "okay", then he robs me, is it victim blaming to say perhaps I should have been more suspicious of strange plumbers randomly showing up at my house to do work?
> education and training is often the only real solution
No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination.
The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not coming up with a solution, or even implementing it, but convincing everyone to adopt the solution because it doesn't help unless it is widely deployed.
No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination.
The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not coming up with a solution, or even implementing it, but convincing everyone to adopt the solution because it doesn't help unless it is widely deployed.
If the easy part is the implementation and the hard part is convincing people of its value then I can say one or more of the following are true:
- Your solution is not sufficiently great as to be self-evidently great.
- People (i.e. the victim) must be faulted (i.e. blamed) for their inability to be convinced of its inherent majesty.
- Given convincing's similarity and overlap both with educating and with training, you are having a failure of imagination. (Source: Your comment.)
- Your solution is not sufficiently great as to be self-evidently great.
- People (i.e. the victim) must be faulted (i.e. blamed) for their inability to be convinced of its inherent majesty.
- Given convincing's similarity and overlap both with educating and with training, you are having a failure of imagination. (Source: Your comment.)
The problem is that the people who need to be convinced are not the people who are being harmed by phishing. The people who are being harmed by phishing (non-technically-savvy end-users) are powerless. The people who need to be convinced of the merits of the solution are browser vendors and web site operators. Both groups would need to work together to solve the problem. Getting that to happen is the hard part. It's a very real problem, but it's a political problem, not a technical one.
Explain how any solution prevents the user from opting out of yubikey and typing self-XSS into Dev console to get owned.
Unless you have a 100% vendor controlled system, (more than Apple + ChromeOS combine) you have to rely on the user not breaking their own security.
Unless you have a 100% vendor controlled system, (more than Apple + ChromeOS combine) you have to rely on the user not breaking their own security.
> Not if it also steals the 2nd factor.
Sure, but isn't that the point? There's now a second thing they have to steal, and if they only get the first it's pretty worthless, especially if there's monitoring/alerting in place that prompts a password change and/or locks your accounts pre-emptively.
Sure, but isn't that the point? There's now a second thing they have to steal, and if they only get the first it's pretty worthless, especially if there's monitoring/alerting in place that prompts a password change and/or locks your accounts pre-emptively.
As phishing usually includes impersonating a website and making the victim believe they are giving their credentials to the original service, I think it is implied that most victims would willfully provide their second factor, when asked for it.
So, in case of phishing that's not the point. If you're actively logging in yourself a second factor doesn't prevent the attacker from gaining access.
So, in case of phishing that's not the point. If you're actively logging in yourself a second factor doesn't prevent the attacker from gaining access.
I bought my whole family Yubikeys last Christmas for exactly this reason ... you can't trick someone into a hardware token authentication. Now I tell people to use something with U2F. I find myself using software U2F and include the secret key in my password manager so that I don't need a hardware key from my laptops.
How many websites allow U2F as the only 2FA? Every website I tied it wanted a backup authentication app added.
Normally you can create backup hardware recovery keys (or alternate fallback 2F). (EDIT: Keys as in e.g. alphanumeric on time use tokens lie "23430240392")
This is necessary as you would else wise be permanently be locked out if you lose your U2F key.
That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent.
Through I guess for not relevant services. I would still want U2F but allow mail recovery and maybe even U2F _only_ login (or FIDO login without PIN).
Given that people have different opinions about what is important I guess this should be an option for fallback recovery, maybe with some warning around it.
The "workaround" to have no fallback for U2F is to generate recovery keys and then not store them anywhere ;=). But I would not recommend this, except if they have a insecure mail based password/U2F recovery anyway.
This is necessary as you would else wise be permanently be locked out if you lose your U2F key.
That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent.
Through I guess for not relevant services. I would still want U2F but allow mail recovery and maybe even U2F _only_ login (or FIDO login without PIN).
Given that people have different opinions about what is important I guess this should be an option for fallback recovery, maybe with some warning around it.
The "workaround" to have no fallback for U2F is to generate recovery keys and then not store them anywhere ;=). But I would not recommend this, except if they have a insecure mail based password/U2F recovery anyway.
I have 4 keys which are stored safely. I do not want a fallback mechanism because that reduces the security of my account. The downside is I have to manage my keys on each site separately. It is a shame that the original OpenID never stuck around as I could have just had one secure account, without having to be part of the current ID provider cabal.
Or perhaps worse, they want SMS OTP to be added as a backup. Even with tons of messages telling people not to share OTPs, it still happens through social engineering.
> you can't trick someone into a hardware token authentication.
Since when?
Since when?
Well once the authentication token expires, they would need to phish you again to get another 2FA token, so there is that. But that is probably plenty of time to do some harm, and depending on the service, possibly even disable 2fa (although a good site will require another 2fa authentication in order to do so).
Also, I'm a big fan of U2F keys including Yubikeys.
I don't use SMS, deprecated it 10 years ago in favor of e-mail, and would never use SMS for 2FA. I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.
For most people, SMS is hackable, tied to a single battery-powered device, easy to steal (after which for most people in the default phone configuration the SMS verification codes will happily pop-up on the lock screen without unlocking the phone), and hugely inconvenient if you are in front of a desktop computer all day and have to go find your phone (at home for example I pretty much never have my phone next to me). SMS also famously locks people out of their accounts when they go to another country and have to use a different SIM card. Also, if you have a giant desktop in front of you, it's ridiculous to not use that as your 2FA device. You should NEVER have to pick up a 6" handheld device for 2FA when you have a massive immobile, hard-to-steal device in front of you that in my case is also physically locked down to furniture.
Yubikeys and other U2F keys do exactly this.
The article is wrong about one thing:
"But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom."
No. My preferred way to use Yubikeys is to buy one for each immobile device (home/office desktops) that stays plugged in, and ONE mobile key that lives in my wallet. Register all keys with critical services. If any device gets stolen (highly unlikely for the immobile devices, the mobile device is the only one I need to worry about really), go home, log in with another key and remotely disable it.
My main gripe is websites that don't allow multiple Yubikeys. AWS is at the top of my hall of shame.
I don't use SMS, deprecated it 10 years ago in favor of e-mail, and would never use SMS for 2FA. I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.
For most people, SMS is hackable, tied to a single battery-powered device, easy to steal (after which for most people in the default phone configuration the SMS verification codes will happily pop-up on the lock screen without unlocking the phone), and hugely inconvenient if you are in front of a desktop computer all day and have to go find your phone (at home for example I pretty much never have my phone next to me). SMS also famously locks people out of their accounts when they go to another country and have to use a different SIM card. Also, if you have a giant desktop in front of you, it's ridiculous to not use that as your 2FA device. You should NEVER have to pick up a 6" handheld device for 2FA when you have a massive immobile, hard-to-steal device in front of you that in my case is also physically locked down to furniture.
Yubikeys and other U2F keys do exactly this.
The article is wrong about one thing:
"But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom."
No. My preferred way to use Yubikeys is to buy one for each immobile device (home/office desktops) that stays plugged in, and ONE mobile key that lives in my wallet. Register all keys with critical services. If any device gets stolen (highly unlikely for the immobile devices, the mobile device is the only one I need to worry about really), go home, log in with another key and remotely disable it.
My main gripe is websites that don't allow multiple Yubikeys. AWS is at the top of my hall of shame.
> I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.
Really? How? Last time I tried to do this it turned out that apps/sites would not send to these virtual SMS numbers.
Really? How? Last time I tried to do this it turned out that apps/sites would not send to these virtual SMS numbers.
A. Don't use Google Voice
B. Find a different virtual SMS number. Try other countries as well. Sometimes it costs a small monthly fee but I don't want to give in to their idiotic game.
B. Find a different virtual SMS number. Try other countries as well. Sometimes it costs a small monthly fee but I don't want to give in to their idiotic game.
I would love to be a fan of Yubikeys, in fact most people would say I _am_ a fan of Yubikeys, I think I have like 10 of them (due to product evolution and always buying a few when I buy one).
Unfortunately most of the sites I use do not have anything to do with them.
Unfortunately most of the sites I use do not have anything to do with them.
> 2FA absolutely will protect you from a phishing site using the password it stole.
The author is pointing out that they will steal both the password and your 2FA token.
The author is pointing out that they will steal both the password and your 2FA token.
While this is possible, it does require significantly more effort on the part of the attacker and there are many more points of failure. So I'm guessing most phishing sites don't actually do that, even though of course some do.
Phishing has been commoditised, the criminals don't write their own pages anymore.
In fact the phishing toolkits have been doing TOTP passthrough/relay for a few years now. For the attacker, it's a nice feature: victim could be using SMS, authenticator app or even an out-of-band delivered token book - they are all captured and passed along equally well.
U2F and FIDO2 with hardware keys are the only realistic safeguards. On the other hand, I do subscribe to the stated problem, because for most people they are a usability snag. The NFC variant has the potential to address this, though: instead of plugging a key in and touching the blinky button, you just wave your keyring next to the device. Too bad NFC readers are not universally available on phones, tablets or laptops.
In fact the phishing toolkits have been doing TOTP passthrough/relay for a few years now. For the attacker, it's a nice feature: victim could be using SMS, authenticator app or even an out-of-band delivered token book - they are all captured and passed along equally well.
U2F and FIDO2 with hardware keys are the only realistic safeguards. On the other hand, I do subscribe to the stated problem, because for most people they are a usability snag. The NFC variant has the potential to address this, though: instead of plugging a key in and touching the blinky button, you just wave your keyring next to the device. Too bad NFC readers are not universally available on phones, tablets or laptops.
German banking has ubiquitous qr-mediated second channel - the authenticator (app or physical device) reads a qr code, shows the transaction details on screen and if they match user types back a code from the app (which is based on qr content).
All that is required is that they phish in real-time or automate the attack. These attacks are not uncommon in the wild. MITM’ing three fields in a login page is not much harder than writing two fields to a DB. And it’s basically trivial to do it over the phone.
If you look at the context of the article, you should assume that phishing attack is sophisticated enough and responding to that attack with "you should use 2FA" is missing the point (which is exactly what the author claims).
2FA (at least the simple OTP variants) don't protect against phishing, they just protect against sloppy phishing attempts.
2FA (at least the simple OTP variants) don't protect against phishing, they just protect against sloppy phishing attempts.
If it’s a website which supports API key or any token of sorts (without expiry or long expiry), they could do some real damage even if they can’t use the 2FA again. Another thing would be to disable 2FA.
All they have to do to achieve this is to use the phished credentials to immediately login with the original site, trigger 2FA and then show a field to capture it and pass along. Then capture all the cookies.
The best defense against phishing is to use a password manager that does domain matching.
All they have to do to achieve this is to use the phished credentials to immediately login with the original site, trigger 2FA and then show a field to capture it and pass along. Then capture all the cookies.
The best defense against phishing is to use a password manager that does domain matching.
Any such password manager you like? Didn't know they could do domain matching
Not the person you asked, but: 1Password which I like, and Lastpass which I don't, both do domain matching in the browser extension. All iOS password managers that integrate into the system do domain matching as well.
Thanks,
In addition to that, now I noticed that in the blog post:
> I recommend the open source Bit Warden. A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github
In addition to that, now I noticed that in the blog post:
> I recommend the open source Bit Warden. A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github
> 2FA absolutely will protect you from a phishing site using the password it stole.
That's assuming one used a different password for the email or mobile provider.
That's assuming one used a different password for the email or mobile provider.
The attacker could proxy the 2FA request from the real site using the password you enter and therefore you wouldn't be protected.
Yes, you can MITM 2FA, but you can't timeshift 2FA.
Right, they could have access to your account, but not full access. A good website will ask for 2FA again if a user tries to do something destructive (like change password, email, or disable 2FA). They wouldn’t be able to do those things.
> A good website will ask for 2FA again if a user tries to do something destructive (like change password, email, or disable 2FA). They wouldn’t be able to do those things.
The page mocking the login page where you need to answer the 2FA will simply phish your 2FA then, after a little delay pretending there's some lag, would say "wrong code, please try again". Now the person enters a second 2FA (which, due to the delay, would be different than the first one).
As I've just commented in a top-level comment: I've seen sites using a 72 hours delay before any destructive change can be made, coupled with the sending of an email containing a link allowing to unilaterally prevent the change.
I've also seen sites using two 2FA (TOTP style), one for login, one for any setup/destructive change. And there are sites using both techniques.
It's not 100% foolproof but it's better than "one 2FA phished and it's game over".
The page mocking the login page where you need to answer the 2FA will simply phish your 2FA then, after a little delay pretending there's some lag, would say "wrong code, please try again". Now the person enters a second 2FA (which, due to the delay, would be different than the first one).
As I've just commented in a top-level comment: I've seen sites using a 72 hours delay before any destructive change can be made, coupled with the sending of an email containing a link allowing to unilaterally prevent the change.
I've also seen sites using two 2FA (TOTP style), one for login, one for any setup/destructive change. And there are sites using both techniques.
It's not 100% foolproof but it's better than "one 2FA phished and it's game over".
[deleted]
Yes, that’s basically the author’s point. But it does protect you against someone trying to use your password on another site.
[deleted]
Mostly agree with a lot of this, but it's a little unfortunate to lump all WebAuthn authenticators together.
WebAuthn keys--physical dongles you plug into the USB port--are indeed problematic for the reasons the author notes. (A small--but user-visible--cost; the requirement for a spare USB port of the right form factor; loss.)
However, authenticators that are built into the client device (e.g. Apple's support for a TouchID-verified WebAuthn authenticator) solve these problems, to varying degrees: the user doesn't see a marginal cost (it's built into the computer!) and doesn't have to worry about loss, USB ports, etc.
The principle challenge with using (as an example) Safari's WebAuthn support is what how the relying party should support loss of the device. (If you lose your Safari--or claim to--how does your bank authenticate you?)
Ultimately, the lost-device--or new-device bootstrapping--problem is currently what stands in the way of a truly secure ecosystem, but with platform providers increasingly supporting WebAuthn, we can at least reduce phishing risk to "phishing of the platform provider credential." Your iCloud password might get stolen, but at least that's the _only_ thing an attacker can steal to gain access to your other accounts.
For most services, delegating authentication (and anti-phishing) to someone like Apple is a big plus.
WebAuthn keys--physical dongles you plug into the USB port--are indeed problematic for the reasons the author notes. (A small--but user-visible--cost; the requirement for a spare USB port of the right form factor; loss.)
However, authenticators that are built into the client device (e.g. Apple's support for a TouchID-verified WebAuthn authenticator) solve these problems, to varying degrees: the user doesn't see a marginal cost (it's built into the computer!) and doesn't have to worry about loss, USB ports, etc.
The principle challenge with using (as an example) Safari's WebAuthn support is what how the relying party should support loss of the device. (If you lose your Safari--or claim to--how does your bank authenticate you?)
Ultimately, the lost-device--or new-device bootstrapping--problem is currently what stands in the way of a truly secure ecosystem, but with platform providers increasingly supporting WebAuthn, we can at least reduce phishing risk to "phishing of the platform provider credential." Your iCloud password might get stolen, but at least that's the _only_ thing an attacker can steal to gain access to your other accounts.
For most services, delegating authentication (and anti-phishing) to someone like Apple is a big plus.
I also think the most of the issues they bring up I understand as adoption (which gets improved by increased adoption on the user side), tolling maturity, and habits.
TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.
TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.
I use Krypton [0] as a virtual YubiKey, I like it a lot but they got acquired by Akamai and the GitHub accounts have gone worryingly quiet.
[0] https://krypt.co
[0] https://krypt.co
> Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone.
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
https://www.imperialviolet.org/2019/01/01/zkattestation.html
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
https://www.imperialviolet.org/2019/01/01/zkattestation.html
Trusting your HSM vendor is a requirement if you don't want your keys to be exportable, and there's much less risk in doing so compared to trusting Apple for other things like secure communications (iMessage is e2ee but doesn't tell you when your peer changes/adds keys, plus unencrypted backups are on by default).
Also, a lot of people who use Krypton don't know that SSH keys actually don't use the secure enclave because it doesn't support rsa or ed25519: https://github.com/kryptco/krypton-ios/issues/73#issuecommen...
Also, a lot of people who use Krypton don't know that SSH keys actually don't use the secure enclave because it doesn't support rsa or ed25519: https://github.com/kryptco/krypton-ios/issues/73#issuecommen...
Sure, I agree that RPs should not use attestation in most cases. (Enterprise use—where the company has issued specific hardware to clients—is an obvious exception.)
Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass.
That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass.
That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
> Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.
In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.
Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).
I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.
In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.
Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).
Oh, I get your point.
I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).
But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.
I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).
But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.
That's cool. Either I haven't seen this before or I've forgotten. :)
I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
I think that's a fair comment. It would be great to see more device come with built in support for this.
Platform support isn't exactly the problem.
Apple, Microsoft, and Android all support WebAuth (https://blog.mozilla.org/security/2019/03/19/passwordless-we..., https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-..., https://docs.microsoft.com/en-us/windows/security/identity-p..., https://developers.google.com/identity/fido/android/native-a...), so most (??) users are in fact covered.
eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site.
The problem is really that until relying parties can trust that
1. Platforms will backup and restore key material from authenticators 2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows)
they will have to provide some fallback. (Realistically, that means "for the foreseeable future.")
This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.)
What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed.
Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
Apple, Microsoft, and Android all support WebAuth (https://blog.mozilla.org/security/2019/03/19/passwordless-we..., https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-..., https://docs.microsoft.com/en-us/windows/security/identity-p..., https://developers.google.com/identity/fido/android/native-a...), so most (??) users are in fact covered.
eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site.
The problem is really that until relying parties can trust that
1. Platforms will backup and restore key material from authenticators 2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows)
they will have to provide some fallback. (Realistically, that means "for the foreseeable future.")
This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.)
What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed.
Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
One form of securing fallback mechanism is to include a long delay, some 2 days, between reset request and execution. It surely does not fit all use cases, but should be good for a lot of less critical stuff.
Not sure why the author is so negative on Yubikey. His only reason is that an attacker can steal his laptop with the key plugged in. That’s a user error.
I much rather have Yubikey over all other forms of security because it simply forces the attacker to be physically present. Why is that important? Because even if your laptop is stolen with your Yubikey at a local Starbucks, you’re more likely to catch that person versus a completely remote attack. Security isn’t just about attacks. You also need to think about mitigation and recovery following the attack.
I much rather have Yubikey over all other forms of security because it simply forces the attacker to be physically present. Why is that important? Because even if your laptop is stolen with your Yubikey at a local Starbucks, you’re more likely to catch that person versus a completely remote attack. Security isn’t just about attacks. You also need to think about mitigation and recovery following the attack.
Author here. I did provide a few other reasons - mostly around usability of YubiKeys. Try observing a non-techie set one up and tell me if you think it is as easy as it could be.
Realistically, you're probably not going to catch a mugger. Otherwise robberies like that wouldn't occur. Snatching a laptop with a key physically plugged in it is probably easier than snatching a laptop and a separate phone.
Regardless of my opinions on tech, if you think being mugged is "user error" then may I suggest spending a couple of days volunteering for a local Victim Support charity.
Realistically, you're probably not going to catch a mugger. Otherwise robberies like that wouldn't occur. Snatching a laptop with a key physically plugged in it is probably easier than snatching a laptop and a separate phone.
Regardless of my opinions on tech, if you think being mugged is "user error" then may I suggest spending a couple of days volunteering for a local Victim Support charity.
I have helped literally hundreds of people setup Yubikeys across several companies.
Your take is just not my experience at all. Tapping a blinking light it is much easier than fussing with a 2FA app and works when someone's phone is dead. Yubikeys in particular are near indestructible. They even work after you soak them in acetone overnight and melt the plastic off. I tried.
When it says "plug in your device" you plug it in. When it says tap you tap.
Also the mugger comment is not part of a typical threat profile. Yubikeys and similar devices are meant to protect you from remote attackers which is the class of attack 99.9999% of people need to defend against.
If a mugger points a gun at you, no form of 2FA is going to save you.
Also my Yubikey has a pin enabled and fingerprint enabled WebAuthn devices exist. I have several. If you are carrying things so valuable you are worried about being mugged, you can probably afford a higher end model with a fingerprint or pin.
Edit: yes I know random muggings happen, but a hit and run mugger that knows what a Yubikey is and already has your password is a hiiiiighly targeted attack. -That- pretty much never happens unless you are walking around with a $1,000,000 in Bitcoin in which case it has happened a total of 5 times that are public.
Your take is just not my experience at all. Tapping a blinking light it is much easier than fussing with a 2FA app and works when someone's phone is dead. Yubikeys in particular are near indestructible. They even work after you soak them in acetone overnight and melt the plastic off. I tried.
When it says "plug in your device" you plug it in. When it says tap you tap.
Also the mugger comment is not part of a typical threat profile. Yubikeys and similar devices are meant to protect you from remote attackers which is the class of attack 99.9999% of people need to defend against.
If a mugger points a gun at you, no form of 2FA is going to save you.
Also my Yubikey has a pin enabled and fingerprint enabled WebAuthn devices exist. I have several. If you are carrying things so valuable you are worried about being mugged, you can probably afford a higher end model with a fingerprint or pin.
Edit: yes I know random muggings happen, but a hit and run mugger that knows what a Yubikey is and already has your password is a hiiiiighly targeted attack. -That- pretty much never happens unless you are walking around with a $1,000,000 in Bitcoin in which case it has happened a total of 5 times that are public.
If it's so easy why did you have to help hundreds of people across several companies set it up?
You have to (well, I guess if it isn't your job you don't have to but it's polite) help people set up anything. Doesn't mean it isn't easy. Helped my mum set up Zoom (so she could attend virtual church apparently), is Zoom not easy?
Two (three?) jobs back I had to set a bunch of people up on one time passcodes. Those seem pretty easy right? Still had to go there in person and show them.
Two (three?) jobs back I had to set a bunch of people up on one time passcodes. Those seem pretty easy right? Still had to go there in person and show them.
If my Yubikey gets stolen, how do I log in into my accounts?
Serious question; never understood how that works.
Serious question; never understood how that works.
This is akin to asking how do you start your car if you lose your keys? Enter your house? You have backups or other recourse to get things rekeyed.
This was confusing to me until I realized a couple of things:
- you can still have TOTP enabled on the site as a backup 2FA method - you can configure multiple yubi keys for a single site - so I have one on my keychain that does NFC + USB-C for my MBP, and another “Nano” key that is left in my home imac - they are both registered with most of the sites I’ve configured
If my keychain is lost/stolen then I can still login from home or with my TOTP code as a fallback.
- you can still have TOTP enabled on the site as a backup 2FA method - you can configure multiple yubi keys for a single site - so I have one on my keychain that does NFC + USB-C for my MBP, and another “Nano” key that is left in my home imac - they are both registered with most of the sites I’ve configured
If my keychain is lost/stolen then I can still login from home or with my TOTP code as a fallback.
That’s how 2FA works. It’s a physical token.
You either have other 2FA devices or backup codes.
You either have other 2FA devices or backup codes.
Depends. Some have a bunch of magic numbers you can use as alternative "second factor", basically another password for the special purpose of bypassing a real 2nd factor. That's of course stupid and dangerous.
Then there are those where you can register another 2nd factor, e.g. another Fido-Key, SMS-Codes or recovery email. Those might be better or might be worse, depending on the method and circumstances. E.g. SMS is vulnerable to all kinds of SIM-Cloning and redirection stuff, email is vulnerable to whatever your email might be vulnerable to.
The only thing I would accept as really idiot-proof and secure is "go someplace, show a government-issued hard-to-fake ID" (like a passport, not your drivers license...) like banks do. But that only works with physically present businesses and accounts that are strictly tied to one person. And even there, "Joe Smith" might impersonate "Joe Smith"...
Then there are those where you can register another 2nd factor, e.g. another Fido-Key, SMS-Codes or recovery email. Those might be better or might be worse, depending on the method and circumstances. E.g. SMS is vulnerable to all kinds of SIM-Cloning and redirection stuff, email is vulnerable to whatever your email might be vulnerable to.
The only thing I would accept as really idiot-proof and secure is "go someplace, show a government-issued hard-to-fake ID" (like a passport, not your drivers license...) like banks do. But that only works with physically present businesses and accounts that are strictly tied to one person. And even there, "Joe Smith" might impersonate "Joe Smith"...
Second yubikey ;)
The last time I've used the configurators on Windows and Linux they provide the private key material for one to backup.
Some other responders have given you the answer as it currently exists. They are all either inconvenient, weaken security, or both. For that reason, I would only suggest using a security key for a small number of critical services, where it's worth the extra effort to deal with the backup mechanisms.
However, a good solution for this issue is finally in the works: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
However, a good solution for this issue is finally in the works: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Having two keys, one of which you keep in a secure place, seems pretty simple and intuitive to me.
What does your workflow look like when you set up new credentials?
If you mean when registering for a new account, annoyingly you need to physically have each key with you to register it with a new service. Biggest flaw in the spec IMO.
You need both of the devices when you set it up. That is one thing they are working on fixing, and is easily the biggest hassle of the whole thing.
If creating new accounts only when you are at the secure location where your backup key lives works for you that's great, but I suspect that most people in that situation would do one or more of the following:
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
"Secure" is a relative term. ;-)
The location doesn't need to be "secure" in the military sense of the term. Mainly you want it "secure" in the sense that if you lose the one key, you won't have lost the other key at the same time.
In the end, the two keys are equivalent from a risk profile if they are compromised, and for most people, the one they carry with them is going to be the weak link in the chain, so additional security on the other key isn't really accomplishing much.
In truth, if your home isn't secured, there's enough holes in most people's online security that someone in your home could find a way to compromise much of your online security (and from there, most of the rest).
Just keeping the other key tucked away in a drawer has some risk, but is pretty decent for most people. Keeping it locked in a fireproof safe in their home along with other important documents/keys/bits is a better choice and not terribly inconvenient.
If you want to be more thorough, you can always have a third key that you keep locked away in a bank vault, and you do "wing it" with just two keys for a period of time on new accounts.
What you don't want to do is "wing it" with one key (though AWS seems to think that's the way to do things). That can lead to disaster. What you also don't want to do is only use it for a subset of your accounts, because in practice most people are terrible at risk compartmentalization, so invariably a compromise of some of your accounts quickly becomes a compromise in all of them.
In my experience #1 is the right way for most people to go. There are disaster scenarios where you lose both keys, but usually that's a disaster severe enough that recovering your online access is the least of your worries, and it does a great job of mitigating the much larger risk of mismanaging the security of accounts that aren't secured with the key.
The location doesn't need to be "secure" in the military sense of the term. Mainly you want it "secure" in the sense that if you lose the one key, you won't have lost the other key at the same time.
In the end, the two keys are equivalent from a risk profile if they are compromised, and for most people, the one they carry with them is going to be the weak link in the chain, so additional security on the other key isn't really accomplishing much.
In truth, if your home isn't secured, there's enough holes in most people's online security that someone in your home could find a way to compromise much of your online security (and from there, most of the rest).
Just keeping the other key tucked away in a drawer has some risk, but is pretty decent for most people. Keeping it locked in a fireproof safe in their home along with other important documents/keys/bits is a better choice and not terribly inconvenient.
If you want to be more thorough, you can always have a third key that you keep locked away in a bank vault, and you do "wing it" with just two keys for a period of time on new accounts.
What you don't want to do is "wing it" with one key (though AWS seems to think that's the way to do things). That can lead to disaster. What you also don't want to do is only use it for a subset of your accounts, because in practice most people are terrible at risk compartmentalization, so invariably a compromise of some of your accounts quickly becomes a compromise in all of them.
In my experience #1 is the right way for most people to go. There are disaster scenarios where you lose both keys, but usually that's a disaster severe enough that recovering your online access is the least of your worries, and it does a great job of mitigating the much larger risk of mismanaging the security of accounts that aren't secured with the key.
I agree with your definition of secure for this topic. I don't agree that a primary residence qualifies as secure under that definition. Fire, flood, earthquake, etc all put you at risk of losing both keys, as does a search by law enforcement.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
"I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened."
You might care, but most people would have bigger problems at that point.
> I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
Yes, that's the use case where they are working to extend the protocol for using backup keys: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Again, most people aren't on the road a lot, and most of those that do already follow so many other bad security practices when they do so that creating new accounts in that context will already be fraught with peril regardless of the mechanism you use... and they'd probably be increasing their exposure if they used a password manager. I'd advise them to not do it, or to create a temporary account using some low-security, low-tech compartmentalized mechanism (like writing the passwords on a piece of paper ;-) and then delete the whole thing and create a new one from scratch when they get home, because that's probably less likely to be a problem. ;-)
"For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2."
I do use a YubiKey secured password manager for services that do not currently support U2F/Webauthn, so I agree that is really the only practical solution for certain cases. There's an in between space where you can use the SmartCard protocol or hardware based OTP, but... My observation has been that for "most people" the non Webauthn cases are a) not necessary and b) actually far more difficult for them to manage, leading to them simply not using the password manager for a lot of cases.
It turns out the typical person's needs are surprisingly limited, but the risk is enormous as is the number of "pathways to failure".
You might care, but most people would have bigger problems at that point.
> I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
Yes, that's the use case where they are working to extend the protocol for using backup keys: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Again, most people aren't on the road a lot, and most of those that do already follow so many other bad security practices when they do so that creating new accounts in that context will already be fraught with peril regardless of the mechanism you use... and they'd probably be increasing their exposure if they used a password manager. I'd advise them to not do it, or to create a temporary account using some low-security, low-tech compartmentalized mechanism (like writing the passwords on a piece of paper ;-) and then delete the whole thing and create a new one from scratch when they get home, because that's probably less likely to be a problem. ;-)
"For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2."
I do use a YubiKey secured password manager for services that do not currently support U2F/Webauthn, so I agree that is really the only practical solution for certain cases. There's an in between space where you can use the SmartCard protocol or hardware based OTP, but... My observation has been that for "most people" the non Webauthn cases are a) not necessary and b) actually far more difficult for them to manage, leading to them simply not using the password manager for a lot of cases.
It turns out the typical person's needs are surprisingly limited, but the risk is enormous as is the number of "pathways to failure".
> If a mugger points a gun at you, no form of 2FA is going to save you.
https://xkcd.com/538/
https://xkcd.com/538/
Hey I understand but didn’t think other reasons were valid. I apologize if my comment came out curt. I know how that feels. However, I think you should reconsider your opinions on Yubikey. They’re significantly better than all other commercially available security solutions at the moment.
Edit: your comment also gave me an idea. Perhaps there should be a phone-based service that you can dial that locks out your account for a predetermined time period? Or it could even be tied to someone else that you can trust.
Edit: your comment also gave me an idea. Perhaps there should be a phone-based service that you can dial that locks out your account for a predetermined time period? Or it could even be tied to someone else that you can trust.
Your opinion is in this case based on your ignorance and misunderstandings. The main threat model U2F key protects against is phishing, and phishing is the largest threat currently. The password is sufficient to protect you for opportunistic offline attacks like theft or loss.
> may I suggest spending a couple of days volunteering for a local Victim Support charity.
Please try being less condescending.
Losing the keys, due to whatever reason, means losing one factor. If the user loses the key, the "mugger" still needs to get the users' passwords.
2FA = something you know + something you own. Having one factor compromised should not compromise your accounts if the service you are using is configured correctly.
Please try being less condescending.
Losing the keys, due to whatever reason, means losing one factor. If the user loses the key, the "mugger" still needs to get the users' passwords.
2FA = something you know + something you own. Having one factor compromised should not compromise your accounts if the service you are using is configured correctly.
> 2FA = something you know + something you own.
That's not exactly correct. Another factor is something you are, such as a fingerprint or eye. There are three classes of factors from which drawing any two is called 2FA.
There is also a 1.5 factor auth, used for example by many banks, in which there is a server challenge for the very vulnerability stated in the article.
That's not exactly correct. Another factor is something you are, such as a fingerprint or eye. There are three classes of factors from which drawing any two is called 2FA.
There is also a 1.5 factor auth, used for example by many banks, in which there is a server challenge for the very vulnerability stated in the article.
What’s the second factor with yubikey? The site seems to say it’s passwordless.
A yubikey doesn't replace a password.
Oh, it seemed like that was what this site was saying:
https://www.yubico.com/solutions/passwordless/
https://www.yubico.com/solutions/passwordless/
Speaking as an author of a webauthn library who helps users set up their security keys as part of their training, it's about as easy as it can be. We give each of our customers 2 yubikeys for each user when they sign up, tell them to keep one on their keychain and the other in a safe location only accessible to them. If you lose/destroy your main key revoke its access use your backup and buy/setup a new one. No one has had difficulty understanding the process for our site since we show them all the steps up front and describe what to do in common scenarios. If your customers have a problem setting it up, it's a reflection of poor user experience not protocol design.
If your laptop get stolen (with Yubikey in it) you only loose one of your TWO factors. So the thief does not have access to your account since they don't know your passwords.
Also, if a user can't learn how to operate a Yubikey after 10 minutes I don't think there is anything that can keep them safe online.
Also, if a user can't learn how to operate a Yubikey after 10 minutes I don't think there is anything that can keep them safe online.
I've spent a lot of my life around Toxteth and Moss Side, and that doesn't affect my threat model relevant to phishing and FIDO. Mugging is probably less of a threat than break-in anyway, as far as compromised hardware goes. You separate the token when it's at risk, and the setup procedure claimed for FIDO, to the extent it exists, seems about as easy as it could be. It's a key. People can understand physical security to a reasonable degree, and typically not abstract computer security.
I agree on the idea around usability of YubiKeys. I have them also and believe they are great, but I never seem to have them when I need them. Of course, maybe its on another floor or another room and I am being lazy not walking over there, but it is an added inconvenience on a process that needs to be balanced between security and convenience.
Adding a rotating 2FA to a password database, for one.
Being mugged isn't "user error", and the good part about YubiKeys is that the consequences of being mugged are much more intuitive (it's just like I had my keys stolen).
The "I left my keys in my coat" problem you have seems like it has a pretty obvious solution: don't keep your YubiKey on your key chain. Do you have a wallet or cell phone that you carry with you at all times? Put it in the wallet or cell phone case.
The "I left my keys in my coat" problem you have seems like it has a pretty obvious solution: don't keep your YubiKey on your key chain. Do you have a wallet or cell phone that you carry with you at all times? Put it in the wallet or cell phone case.
[deleted]
Fully agree that a physical attack is much less likely.
Also, the use of a PIN or fingerprint[1] to authenticate the yubikey itself and not sent over the network, mitigates the stolen key scenario. [2]
[1] https://www.yubico.com/blog/getting-a-biometric-security-key... [2] https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
Also, the use of a PIN or fingerprint[1] to authenticate the yubikey itself and not sent over the network, mitigates the stolen key scenario. [2]
[1] https://www.yubico.com/blog/getting-a-biometric-security-key... [2] https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
Another issue not mentioned by the author is what happens if the Yubikey is lost or breaks. The story around this type of event is sort of ignored and not understood properly. AFAIK it's not possible to duplicate a key (by design), meaning that the user will have to update all their websites' 2FA (hopefully there is a recovery method available).
Yes. You must have at least two keys registered. However it’s worth noting that most services do not offer priority. Meaning you can use either one. I think it makes sense to designate back up keys and only to be used when user reports lost/stolen primary key.
But what is the story there? You have a backup key, hopefully stored "off site", now you want to enroll in another website. You have to get that backup key before you do that? Or bookkeep which sites you have on the backup key and which you don't?
Actually, this is one area where pgp's use in pass works really well. You use your public key to encrypt passwords. So, adding a new one doesn't need the physical key.
This is a very good point and perhaps something Yubikey and similar services should consider: paired keys. Once paired the backup can always replace original if user reports it missing or lost regardless of when they were paired.
While it's not possible to duplicate an existing key, it is possible to create duplicate keys in the first place - you can't get the secrets out, but you can write identical secrets to two or more keys if you want to.
This adds some convenience, though it also does add some risks e.g. in case of breach you can't tell which token was misused, you can't invalidate a lost key without invalidating others at the same time.
This adds some convenience, though it also does add some risks e.g. in case of breach you can't tell which token was misused, you can't invalidate a lost key without invalidating others at the same time.
Also, Bluetooth based keys exist that don’t have to be plugged in.
All the complaints made about yubikey and webauthn could be made about 2fa 5-10 years ago. Hardware tokens gated by software (ala yubikey + webauthn) are clearly the next step in auth.
It’s an accident of circumstance you even need to buy a yubikey - your iPhone, iPad, laptop, android whatever can do everything a yubikey does. There just needs to be enough demand and time for OS and hardware vendors to come around to shipping and integrating this stuff by default. Suddenly you’ll own 3 or 4 yubikey equivalents without buying any special auth devices.
25 years into the web and our login tools remain pretty barbaric. Maybe in 25 years we’ll have it sorted out. But change is coming. Call it 2fa, webauthn, whatever - regardless of the details username/password auth (on its own) is dead.
It’s an accident of circumstance you even need to buy a yubikey - your iPhone, iPad, laptop, android whatever can do everything a yubikey does. There just needs to be enough demand and time for OS and hardware vendors to come around to shipping and integrating this stuff by default. Suddenly you’ll own 3 or 4 yubikey equivalents without buying any special auth devices.
25 years into the web and our login tools remain pretty barbaric. Maybe in 25 years we’ll have it sorted out. But change is coming. Call it 2fa, webauthn, whatever - regardless of the details username/password auth (on its own) is dead.
Yeah. It is mostly about integrating and standards. Private keys in the secure enclave already does everything Yubikey does. All phones already have it. The OSes just need to support FIDO and then we don't need passwords anymore (assuming a passcode lock on device). Essentially everyone would have 3FA (something you know, something you have and something you are)
Secure enclaves as a second factor break the assumptions of 2FA threat models. If I compromise a single factor (your device) then I can gain both your password and your second factor.
The best second factors are separate devices with their own screens that indicate what you are authenticating to/for before you provide your authentication.
Of course, nothing ever stops a user from deputizing malware.
The best second factors are separate devices with their own screens that indicate what you are authenticating to/for before you provide your authentication.
Of course, nothing ever stops a user from deputizing malware.
I guess I'm not seeing the difference between the secure enclave in a phone and the secure chip in a Yubikey in regards to threat models.
[deleted]
Why don't we just skip to 4fa, now.
(though it might be tough for chimeras who have 2 sets of dna)
(though it might be tough for chimeras who have 2 sets of dna)
Maybe they can pioneer 5fa.
They author makes a few good points, but I find the author's critique of Yubikey weak:
>Cost. The average YubiKey is £50...
If that's too expensive for ensuring your internet security, then either you underestimate the risks, or undervalue your information. If a Yubikey cost 10 times more it would still be a bargain.
>Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.
Pressing the button at the right tight was a joke, right? Although, I admit it may be challenging for people with disabilities. Websites making it hard to find 2FA settings is not a Yubikey's problem, it's a website problem. Setting up a Yubikey is rather straight forward too. The main issue is the inability to clone a Yubikey programmatically, but that's the price of security.
>Convenience. My YubiKey is on my keyring. My keys are in my coat...
That's can't be serious too. I won't even elaborate on this.
>Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
That's actually the only valid point I somewhat agree with. Again, this is largely mitigated by developing the right habits. You don't leave your car keys hanging in your car's lock after leaving the car in a parking lot, right? Then why do it with Yubikey? If developing a new minor habit represents a problem, then either you underestimate the risks, or undervalue your information.
An additional password/fingerprint protection would be nice though. I agree on that.
>Support. WebAuthn is a great standard – but only a few sites support it...
Again, this is not a Yubikey's problem. It's a website problem.
>Cost. The average YubiKey is £50...
If that's too expensive for ensuring your internet security, then either you underestimate the risks, or undervalue your information. If a Yubikey cost 10 times more it would still be a bargain.
>Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.
Pressing the button at the right tight was a joke, right? Although, I admit it may be challenging for people with disabilities. Websites making it hard to find 2FA settings is not a Yubikey's problem, it's a website problem. Setting up a Yubikey is rather straight forward too. The main issue is the inability to clone a Yubikey programmatically, but that's the price of security.
>Convenience. My YubiKey is on my keyring. My keys are in my coat...
That's can't be serious too. I won't even elaborate on this.
>Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
That's actually the only valid point I somewhat agree with. Again, this is largely mitigated by developing the right habits. You don't leave your car keys hanging in your car's lock after leaving the car in a parking lot, right? Then why do it with Yubikey? If developing a new minor habit represents a problem, then either you underestimate the risks, or undervalue your information.
An additional password/fingerprint protection would be nice though. I agree on that.
>Support. WebAuthn is a great standard – but only a few sites support it...
Again, this is not a Yubikey's problem. It's a website problem.
I mean, you say all this, but more or less these are the same complaints I hear from even seasoned IT professionals every single day when it comes to security.
Even the "the key is in my coat" is not a joke at all -- I've had clients who got compromised by a malicious insider because some admin wrote passwords on a sticky note simply because "password managers are cumbersome".
I get what you're saying on each point, but understand that security is as much about discipline as the actual security you implement. You can have the best of the best, but it doesn't mean anything without the discipline to use it, and I suppose that's what the author is trying to convey.
You even touch on it in your response about developing the right habits, and that's the author's port -- without discipline, the Yubikey means nothing.
>Again, this is not a Yubikey's problem. It's a website problem.
On this point I can't really agree at all; Yubikey might have a solid solution for a problem, but if no one is implementing it, then it's a solution looking for a problem. The mythical "average user" won't be persuaded to drop any amount of money on a dongle that does nothing; if it doesn't work for a large majority of their most common sites, then it's just a waste of money.
I'd suggest it __is__ Yubikey's problem as they're not promoting their value to sites in a way that implementation is a no-brainer. Checking on their compatibility list fo common chat-applications, common forums, common message boards/imageboards, and common shops world-wide, the adoption is very limited. Surely the admins of popular sites are aware of Yubikey, but at some point there was a decision not to add functionality -- Yubikey needs to make the efforts to promote adoption and figure out where there resistance comes from.
Of my daily sites that I might expect to be aware of/implement some hardware security, only reddit is on the list of "works with Yubikey", and I pretty rarely use reddit. Listing sites my friends and family use on a day to day basis, only Google Accounts comes up.
That's what the post is talking about. Yubikey does not have the penetration to be viable to "average users", and even for tech persons, the device is useless without the discipline to adjust habits in the first place, which most people just don't have.
Even the "the key is in my coat" is not a joke at all -- I've had clients who got compromised by a malicious insider because some admin wrote passwords on a sticky note simply because "password managers are cumbersome".
I get what you're saying on each point, but understand that security is as much about discipline as the actual security you implement. You can have the best of the best, but it doesn't mean anything without the discipline to use it, and I suppose that's what the author is trying to convey.
You even touch on it in your response about developing the right habits, and that's the author's port -- without discipline, the Yubikey means nothing.
>Again, this is not a Yubikey's problem. It's a website problem.
On this point I can't really agree at all; Yubikey might have a solid solution for a problem, but if no one is implementing it, then it's a solution looking for a problem. The mythical "average user" won't be persuaded to drop any amount of money on a dongle that does nothing; if it doesn't work for a large majority of their most common sites, then it's just a waste of money.
I'd suggest it __is__ Yubikey's problem as they're not promoting their value to sites in a way that implementation is a no-brainer. Checking on their compatibility list fo common chat-applications, common forums, common message boards/imageboards, and common shops world-wide, the adoption is very limited. Surely the admins of popular sites are aware of Yubikey, but at some point there was a decision not to add functionality -- Yubikey needs to make the efforts to promote adoption and figure out where there resistance comes from.
Of my daily sites that I might expect to be aware of/implement some hardware security, only reddit is on the list of "works with Yubikey", and I pretty rarely use reddit. Listing sites my friends and family use on a day to day basis, only Google Accounts comes up.
That's what the post is talking about. Yubikey does not have the penetration to be viable to "average users", and even for tech persons, the device is useless without the discipline to adjust habits in the first place, which most people just don't have.
>security is as much about discipline as the actual security you implement
Totally agree on that. The author's main ranting about Yubikey is that it requires developing new habits, but that's exactly the point.
>they're not promoting their value to sites in a way that implementation is a no-brainer.
That's a good point. Although, poor adoption of hardware tokens even by banks (e.g. no bank in Canada supports Yubikey) is surely not because it's hard to implement. It's a "chicken-or-egg" problem. Organizations don't support hardware tokens because few people use them, and few people use tokens because many organizations don't support them anyway. Yubikey and other hardware token vendors could've done a better job promoting and simplifying using hardware tokens.
Totally agree on that. The author's main ranting about Yubikey is that it requires developing new habits, but that's exactly the point.
>they're not promoting their value to sites in a way that implementation is a no-brainer.
That's a good point. Although, poor adoption of hardware tokens even by banks (e.g. no bank in Canada supports Yubikey) is surely not because it's hard to implement. It's a "chicken-or-egg" problem. Organizations don't support hardware tokens because few people use them, and few people use tokens because many organizations don't support them anyway. Yubikey and other hardware token vendors could've done a better job promoting and simplifying using hardware tokens.
> YubiKeys have no password lock of their own
I don't know if the author of the blog post means something else but if you're using 2FA tokens (i.e. Yubikey Authenticator) you can put password protection for additional security.
I don't know if the author of the blog post means something else but if you're using 2FA tokens (i.e. Yubikey Authenticator) you can put password protection for additional security.
Yubikeys have PIN for FIDO2 passwordless auth, see `ykman fido set-pin` command (IIRC, there a GUI for this as well but I don't have a single passwordless login - to best of my awareness, no single website on the web that I use seem to support this).
This is different from typical U2F operations, though, where website asks for a password ("know") and a hardware token ("have"). For those, password is the secret part already.
If someone phished someone's password AND stole one's Yubikey - well, this is a very peculiar situation, where, indeed, the scenario fails. If someone steals a laptop with Yubikey plugged in - they (hopefully) don't have passwords. Unless someone had set it up to login and open their password manager with just a touch of the said Yubikey, without anything extra. Which is, again, quite a peculiar situation.
This is different from typical U2F operations, though, where website asks for a password ("know") and a hardware token ("have"). For those, password is the secret part already.
If someone phished someone's password AND stole one's Yubikey - well, this is a very peculiar situation, where, indeed, the scenario fails. If someone steals a laptop with Yubikey plugged in - they (hopefully) don't have passwords. Unless someone had set it up to login and open their password manager with just a touch of the said Yubikey, without anything extra. Which is, again, quite a peculiar situation.
In some scenarios, Windows 10 will also require a PIN to use a key:
https://docs.microsoft.com/en-us/azure/active-directory/user...
https://docs.microsoft.com/en-us/azure/active-directory/user...
The Yubikey/WebAuthn comments are really ignorant and discouraging people from the best defense against this sort of attack that exists.
First of all you can get WebAuthn devices for as little as $10 now.
Second, there is no app to configure. You plug it in when it says register and tap it. Done.
Third, if the WebAuthn device gets stolen the attacker presumably lacks a password. You can't use the device by itself. Also the vast majority of attacks are remote, not IRL.
Fourth: fingerprint or pin authenticated WebAuthn devices exist if your threat model worries about physical access.
IRL attacks are a radically different threat profile.
I can't even with this article.
First of all you can get WebAuthn devices for as little as $10 now.
Second, there is no app to configure. You plug it in when it says register and tap it. Done.
Third, if the WebAuthn device gets stolen the attacker presumably lacks a password. You can't use the device by itself. Also the vast majority of attacks are remote, not IRL.
Fourth: fingerprint or pin authenticated WebAuthn devices exist if your threat model worries about physical access.
IRL attacks are a radically different threat profile.
I can't even with this article.
Could you let me know where I can buy a well supported WebAuthn key for that price?
Looking at Amazon UK - https://amzn.to/3oWGYe4 - the cheapest appears to be about £30. Unless I want to risk my security to some no-name brand with zero customer support.
When I got my YubiKey, it told me I had to download an Android app to make it work. So, perhaps better documentation is needed?
I'm sorry you didn't like my post, I'll try to do better in future.
Looking at Amazon UK - https://amzn.to/3oWGYe4 - the cheapest appears to be about £30. Unless I want to risk my security to some no-name brand with zero customer support.
When I got my YubiKey, it told me I had to download an Android app to make it work. So, perhaps better documentation is needed?
I'm sorry you didn't like my post, I'll try to do better in future.
The HYPERFIDO Mini keys (8 GBP[0,1]) are certified by the FIDO Alliance: https://fidoalliance.org/showcase/hyperfido-mini/.
[0]: https://www.amazon.co.uk/HYPERFIDO-MINI-FIDO2-HOTP-Security/...
[1]: https://www.hypersecu.com/products/hyperfido
[0]: https://www.amazon.co.uk/HYPERFIDO-MINI-FIDO2-HOTP-Security/...
[1]: https://www.hypersecu.com/products/hyperfido
The HyperFIDO is basically fine, it's obviously your choice to insist on the expensive famous brand products, but it seems a bit crazy to on the one hand insist those are too expensive and then reject perfectly good cheap options.
If I had a corporate budget to spend maybe I'd order trays of Yubico Security Keys or Google's Feitian rebrand. But I just wanted to have more than one vendor so I have this product (well not this one, but it's the same product under different branding) and it works fine.
If I had a corporate budget to spend maybe I'd order trays of Yubico Security Keys or Google's Feitian rebrand. But I just wanted to have more than one vendor so I have this product (well not this one, but it's the same product under different branding) and it works fine.
Conor sold U2F Zero's for less than 10 dollars (years ago) and has a kick starter now to fund his new Solo keys:
https://www.kickstarter.com/projects/conorpatrick/solo-the-f...
https://u2fzero.com/
I have a few U2F Zeros and they have been working fine for years. These are simple devices. You don't need to overpay for them.
Edit: Conor was building the U2F Zero tokens for $2.26 USD per unit. Read more here:
https://www.conorpp.com/u2f-zero-year-in-review/
https://www.kickstarter.com/projects/conorpatrick/solo-the-f...
https://u2fzero.com/
I have a few U2F Zeros and they have been working fine for years. These are simple devices. You don't need to overpay for them.
Edit: Conor was building the U2F Zero tokens for $2.26 USD per unit. Read more here:
https://www.conorpp.com/u2f-zero-year-in-review/
I don't think the kickstarter is relevant now. You just buy them from solokeys.com. There's been Somu since that, and Solo2 is in the offing, with plenty of storage, apparently. I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version).
In answer to the expense question, two Solo keys appear to set you back 38 quid at the current exchange rate. I don't know how they compare with HYPERFIDO, which I don't think I'd come across before.
In answer to the expense question, two Solo keys appear to set you back 38 quid at the current exchange rate. I don't know how they compare with HYPERFIDO, which I don't think I'd come across before.
I can confirm what you and _wldu are saying and yes, the latest project is https://solokeys.com/v2 and is launching end of this month.
From an economic perspective, unfortunately, it's really hard to focus on reducing the cost, there's simply no incentive.
First, consider that the biggest cost in the customer getting a security key is basically shipping + packaging. Imagine a key that costs <$3... even packaging with a polybag + printed label + padded envelop gets to a cost that has a significant % of the production cost.
Next, it's features. To stay on par with competition, people expect the same features (see, e.g., openpgp mentioned above - the code currently doesn't fit in the stm32l4 flash), both firmware and hardware. As a result we have to look at the latest & greatest micro, but of course that alone has a significant cost.
And finally, there's the overall viability. We all know that open source projects die without a business model. The numbers in the U2FZero review simply don't add up, that was clearly unsustainable and that's why we made SoloKeys. A business has expenses other than manufacturing and if you don't account for that, the business dies together with your dream project.
Anyway, thank you both (and all others) for the great support. One step at a time, we'll get to a stronger and eventually also cheaper product!
From an economic perspective, unfortunately, it's really hard to focus on reducing the cost, there's simply no incentive.
First, consider that the biggest cost in the customer getting a security key is basically shipping + packaging. Imagine a key that costs <$3... even packaging with a polybag + printed label + padded envelop gets to a cost that has a significant % of the production cost.
Next, it's features. To stay on par with competition, people expect the same features (see, e.g., openpgp mentioned above - the code currently doesn't fit in the stm32l4 flash), both firmware and hardware. As a result we have to look at the latest & greatest micro, but of course that alone has a significant cost.
And finally, there's the overall viability. We all know that open source projects die without a business model. The numbers in the U2FZero review simply don't add up, that was clearly unsustainable and that's why we made SoloKeys. A business has expenses other than manufacturing and if you don't account for that, the business dies together with your dream project.
Anyway, thank you both (and all others) for the great support. One step at a time, we'll get to a stronger and eventually also cheaper product!
Ah, I didn't know about the PGP code size. Point taken about the cost, and I hope you can sell to organizations. I'm surprised I can buy a competitor for £8, but then I can't run the proprietary programming software or, I assume, re-flash it. I'm happy to support a free software project anyhow. I wish I could register my Somu with the work Duo system rather than the display-a-number-you-type HOTP keys they reluctantly issue as the expensive alternative to expecting us to use personal phones for such purposes. Phishing, we've heard of it.
Nice try, but I will never attach an usb device for frequent usage that sticks out like the Solokeys v2. The size of the Somu * is fine, as it doesn't need to removed when transporting a laptop.
Integrated in to the laptop it would be great, like an Apple Watch allows https://support.apple.com/guide/imac/unlock-and-approve-with...
* https://solokeys.com/collections/all/products/somu-tiny-secu...
Integrated in to the laptop it would be great, like an Apple Watch allows https://support.apple.com/guide/imac/unlock-and-approve-with...
* https://solokeys.com/collections/all/products/somu-tiny-secu...
I hear you.
The stm32 used in v1 was 3x3mm, while the new nxp lpc55s6x used in v2 is 5x5mm. Plus we added 2mb of flash, though it's optional.
If anyone wants to try to packing the components into a somu v2, that'd be a nice addition to the *omu family [1] and we'd be more than happy to help with manufacturing. Same for a somu for usb-c.
[1] https://tomu.im
The stm32 used in v1 was 3x3mm, while the new nxp lpc55s6x used in v2 is 5x5mm. Plus we added 2mb of flash, though it's optional.
If anyone wants to try to packing the components into a somu v2, that'd be a nice addition to the *omu family [1] and we'd be more than happy to help with manufacturing. Same for a somu for usb-c.
[1] https://tomu.im
> I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version).
It is sad that with PGP being so horribly broken, it still casts its shadow over security products.
PGP should have been dead and buried eons ago.
It is sad that with PGP being so horribly broken, it still casts its shadow over security products.
PGP should have been dead and buried eons ago.
> It is sad that with PGP being so horribly broken, it still casts its shadow over security products.
How is ssh with a PGP key horribly broken? There's no shadow over Solo/Somu from where I'm standing.
How is ssh with a PGP key horribly broken? There's no shadow over Solo/Somu from where I'm standing.
The key is fine. PGP--not so much.
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
So what's the problem, and what's the alternative anyway (in the absence of FIDO support in the case of ssh)?
AMAZON AFFILIATE LINK. Please delete....
Disappointed but not surprised when reading this. To be really honest, I can't remember the last time I read something that criticized so called "techbros" and actually said something reasonable.
As for the U2F devices, the idea of just leaving them in, the small yubikeys and all that, seem to just be a bad idea from the get-go.
As for the U2F devices, the idea of just leaving them in, the small yubikeys and all that, seem to just be a bad idea from the get-go.
You can leave them in, but you still have to tap/touch them for every authentication action (user interaction); the small YubiKey Nano included.
What is your objection to just leaving a yubikey plugged in? It eliminates most of the ways an attacker could impersonate me besides literally stealing my laptop, which is a high bar. Most people are valuable enough targets to phish or infect with malware or something, but not to plan a computer heist.
If stealing the computer is enough, someone's seriously screwed up already — it's supposed to be 2FA, not 1FA.
Stealing the computer is usually enough, as a browser cookie serves as proof of authentication all on its own. Some destructive operations require extra auth, but in terms of data exfiltration, stealing a laptop gives you everything you need.
What exactly does that have to do with YubiKeys though? Every time you use one you need to enter password. And you can also immediately revoke it as soon as you notice its stolen.
I kind of omitted that part. Having a YubiKey in or not in the laptop won't really affect things (other than the fact that you will need to get into your account somehow without the yubikey if the yubikey is stolen).
Found the techbro.
most people have a phone that can leverage webauthn, so you don't even need to buy anything.
On top of that, webauthn can be configured to prevent phishing as well
Plus, iPhones already support webauthn via Face ID, and I assume MacBooks will support it via Touch ID at some point.
It is disappointing that touch id doesn't support this yet, it would be great. I put my ssh keys on touch id but my webauthn and gpg are on the yubikey and I have to remember which to touch. And the yubikey with finger print reader isnt out yet and I already have pretty much the right hardware in the mac...
For the reasons listed in the article and more, Yubikeys and similar devices aren’t likely to ever be popular.
To give future security devices along the same vain a better chance at gaining popularity and being widely adopted (which will hopefully bringing us a more stable, less stressful society), the designs of these new devices must solve or workaround the issues the author describes.
It’s really annoying when individuals such as yourself respond so very negatively and unconstructively while others are trying to discuss the issues with existing designs — an act necessary for us (collectively) to develop new designs.
The author may not provide strong evidence for their claims, but neither do you provide strong evidence (or extensive reasoning) for yours. The net gain here is negligible, expect for showing that contrary opinions exist, but that’s not particularly helpful as for every opinion held it is inevitable that someone holds the polar opposite.
I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
To give future security devices along the same vain a better chance at gaining popularity and being widely adopted (which will hopefully bringing us a more stable, less stressful society), the designs of these new devices must solve or workaround the issues the author describes.
It’s really annoying when individuals such as yourself respond so very negatively and unconstructively while others are trying to discuss the issues with existing designs — an act necessary for us (collectively) to develop new designs.
The author may not provide strong evidence for their claims, but neither do you provide strong evidence (or extensive reasoning) for yours. The net gain here is negligible, expect for showing that contrary opinions exist, but that’s not particularly helpful as for every opinion held it is inevitable that someone holds the polar opposite.
I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
I use a Yubikey daily and the OP is greatly exaggerating the issues in my opinion. Vanguard for example it took less than a minute to set up. I don't have an "application" installed locally for the Yubikey, it was plug & play. No special software needed.
I honestly think Yubikey type devices' largest problems are - 1. Marketing. People simply do not know they exist or how they work (simple or not). 2. Support - Many websites do not support Webauthn yet. We really need developers and businesses to consider this a priority.
I have bought some keys for my family members and they love them once I demonstrate how they work.
I honestly think Yubikey type devices' largest problems are - 1. Marketing. People simply do not know they exist or how they work (simple or not). 2. Support - Many websites do not support Webauthn yet. We really need developers and businesses to consider this a priority.
I have bought some keys for my family members and they love them once I demonstrate how they work.
Price. Yubikey's "best seller" goes for $45, that's grotesque. I would be surprised if the hardware costs exceeds $2 per unit and the software (or similar) can be had for free.
It's not about the hardware. In spite of the fact that they can nominally be broken into, most modern USB microcontrollers can easily implement being a security key.
The expense is that the security world hasn't converged on anything remotely approaching a single standard. So, a key has to support ... PGP, OpenSSH, FIDO, FIDO2, U2F ...
For example, you couldn't use some of the older YubiKeys with AWS because AWS only supported time-based TOTP.
That's a LOT of software work, and you can't be "Startup Sloppy" with your code or someone will break it.
The expense is that the security world hasn't converged on anything remotely approaching a single standard. So, a key has to support ... PGP, OpenSSH, FIDO, FIDO2, U2F ...
For example, you couldn't use some of the older YubiKeys with AWS because AWS only supported time-based TOTP.
That's a LOT of software work, and you can't be "Startup Sloppy" with your code or someone will break it.
The PGP thing is wildly different than the other applications in that it is a complete airgapped system on a key. The decryption and signing is actually done on key so the private key isn't exposed. PGP is pretty much the only thing that does this and as a result can be held up as an example of where we do in fact have a unique standard.
> I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
Please don't go there. You're both adding to the discussion, maybe some strong words here and there, but this turn of phrase you used is a huge conversation destroyer.
Please don't go there. You're both adding to the discussion, maybe some strong words here and there, but this turn of phrase you used is a huge conversation destroyer.
I think Yubikey (and similar physical solutions) will eventually gain popularity. Carrying a key is pretty much a standard practice across the globe and benefit is more than negligible because it forces physical attack versus remote/virtual.
Until keys become cloneable they will never gain popularity.
Nobody wants to re-setup every site ever because they lost their laptop that they kept it plugged into, so they won't. either this means using their backup until they lose it without even revoking the original and then swearing off the entire concept while telling all their friends to do the same, or just not using hardware tokens after the first lost of keys.
Also the "back up code" they will also get, guess where thats going! save as -> downloads or print2pdf -> downloads.
When it comes to personal account security by end users, hardware tokens will never take off, and this is why they get so much hate.
There is a real problem here that really needs to be really solved, wrt to end users and phishing/hack resistant credentials, and as long as we legitimize the lie that yubikey solves it, we gimp progress towards actually solving it.
Nobody wants to re-setup every site ever because they lost their laptop that they kept it plugged into, so they won't. either this means using their backup until they lose it without even revoking the original and then swearing off the entire concept while telling all their friends to do the same, or just not using hardware tokens after the first lost of keys.
Also the "back up code" they will also get, guess where thats going! save as -> downloads or print2pdf -> downloads.
When it comes to personal account security by end users, hardware tokens will never take off, and this is why they get so much hate.
There is a real problem here that really needs to be really solved, wrt to end users and phishing/hack resistant credentials, and as long as we legitimize the lie that yubikey solves it, we gimp progress towards actually solving it.
I don't think cloneable is a good idea. If some 3rd party clones your token and uses it to commit a crime there is no way to prove that happened.
There are other solutions. Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day. Should you lose your daily driver, just sign another one. This still suffers from the "one true name" problem though - if someone steals that bank vault ID, you're gone.
Another approach is servers allowing a client to register multiple ID's, and later delete them. Since there are multiple ID's, there isn't one true name any more. If one is lost you cancel it, and replace it with another. The approach is already built into the FIDO2 protocol, so they've already thought about your concerns and solved them, and IMHO solved them in a better way than you propose.
A more robust approach still would be a combination of the idea above: FIDO2 multiple ID's solution, plus proxies. One key could then provide multiple ID's to every server you log into, signed by different masters that are stored in different places. Keys can't be copied, but a lost key can be replaced by signing it with the master. A compromised master can be have all it's ID's dropped by logging in with an ID proxying other master. You could think of it as RAID for 2FA's.
There are other solutions. Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day. Should you lose your daily driver, just sign another one. This still suffers from the "one true name" problem though - if someone steals that bank vault ID, you're gone.
Another approach is servers allowing a client to register multiple ID's, and later delete them. Since there are multiple ID's, there isn't one true name any more. If one is lost you cancel it, and replace it with another. The approach is already built into the FIDO2 protocol, so they've already thought about your concerns and solved them, and IMHO solved them in a better way than you propose.
A more robust approach still would be a combination of the idea above: FIDO2 multiple ID's solution, plus proxies. One key could then provide multiple ID's to every server you log into, signed by different masters that are stored in different places. Keys can't be copied, but a lost key can be replaced by signing it with the master. A compromised master can be have all it's ID's dropped by logging in with an ID proxying other master. You could think of it as RAID for 2FA's.
> Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day.
Yes, clonable tokens. Exactly.
When people ask for clonable tokens. This is an acceptable solution.
(But skip the bank vault. This is for avg Joe, not Jeff bezos. The closest safe will do)
Yes, clonable tokens. Exactly.
When people ask for clonable tokens. This is an acceptable solution.
(But skip the bank vault. This is for avg Joe, not Jeff bezos. The closest safe will do)
I am not understanding your concern. You definitely don’t want the keys to be “cloneable”. You need at least two keys, sure, but I don’t see that as an inconvenience. And you should be using a password manager (with passwords cycled on a periodic basis) that is bound to your physical key.
Instead of a hardware authenticator to be carried on a keyring, they should be put into rings, i.e., the things meant to be worn on your fingers, i.e., the things that most people use for providing input to their computing devices, whether they sit on a desk or are held in one's hands.
I had one twenty years ago, a Java Ring. Apparently they are still being made today.
This is actually brilliant.
I've long thought that U2F should be incorporated into phones, since everyone has one of those. Even not well off people in third world countries. In order for U2F to proliferate, everyone should have access to it. A $10 FIDO key probably won't be given a consideration if they think a free password is good enough.
WebAuthn is the modern replacement for U2F. Do not deploy greenfield U2F, it's a legacy technology only.
A modern iPhone or high-end Android phone already does WebAuthn secured with your fingerprint or (on some iPhone models) facial recognition, like your lock screen or contactless payments.
A modern iPhone or high-end Android phone already does WebAuthn secured with your fingerprint or (on some iPhone models) facial recognition, like your lock screen or contactless payments.
> Buy a device, register it, install the app,
What u2f app is this referring to? I've never needed anything more than chrome to use u2f on windows or ubuntu. Also seems weird to complain about setting up an app, when a few sentences before that they recommend installing a password manager...
What u2f app is this referring to? I've never needed anything more than chrome to use u2f on windows or ubuntu. Also seems weird to complain about setting up an app, when a few sentences before that they recommend installing a password manager...
YubiKey recommended that I install Yubi Auth https://play.google.com/store/apps/details?id=com.yubico.yub... and YubiClip https://play.google.com/store/apps/details?id=com.yubico.yub...
Should I not have?
Should I not have?
If you had used one of the $10 USD Webauthn (aka U2F) tokens, it wouldn't have asked you to install any applications.
The "problem" is the expensive Yubikeys that you were whining about has lots of extra functionality that has nothing to do with U2F, and that's what the extra applications are all about.
I happen to use a Yubikey because I want that extra functionality, including using it to secure the keys I use for ssh and for digitally signing git tags so I can securely push git pull requests. But that's because I'm a developer, and it's why I'm happy to purchase multiple Yubikeys (one for my desktop, one for laptop, backups including one that is on a keychain, etc.) Perhaps you were reading web sites that was giving advice for developers as opposed to for consumers?
The "problem" is the expensive Yubikeys that you were whining about has lots of extra functionality that has nothing to do with U2F, and that's what the extra applications are all about.
I happen to use a Yubikey because I want that extra functionality, including using it to secure the keys I use for ssh and for digitally signing git tags so I can securely push git pull requests. But that's because I'm a developer, and it's why I'm happy to purchase multiple Yubikeys (one for my desktop, one for laptop, backups including one that is on a keychain, etc.) Perhaps you were reading web sites that was giving advice for developers as opposed to for consumers?
OpenSSH >= 8.something natively supports U2F. No need for extra functionality.
However, to use native FIDO the SSH server must accept it (GitHub does not for example)
Whereas if you have RSA keys on the "full fat" Yubikey, they can be used regardless.
Whereas if you have RSA keys on the "full fat" Yubikey, they can be used regardless.
For U2F specifically you don't need apps except support in the browser. The apps you listed are used for other types of functionality provided by the yubikey, like OTP and TOTP.
No.
2FA is designed to authenticate that this is you logging in. Wrong off the bat.
The "they just use your login token" is akin to "they just hacked the CIA's database". Just.
I also don't see how the author thinks that the same users who struggle with yubikey won't simply search for the github.com login on githud.com in their password manager. Bitwarden and co are great but the default domain creates a problem where login.signup.domain.com does not match login.domain.com and so users are used to searching.
The bit that completely lost me was the lamenting of convenience with the YubiKey.
Security and convenience are polar opposites.
Coupled with the "tech bros" comment, I am not sure this is in good faith at all
2FA is designed to authenticate that this is you logging in. Wrong off the bat.
The "they just use your login token" is akin to "they just hacked the CIA's database". Just.
I also don't see how the author thinks that the same users who struggle with yubikey won't simply search for the github.com login on githud.com in their password manager. Bitwarden and co are great but the default domain creates a problem where login.signup.domain.com does not match login.domain.com and so users are used to searching.
The bit that completely lost me was the lamenting of convenience with the YubiKey.
Security and convenience are polar opposites.
Coupled with the "tech bros" comment, I am not sure this is in good faith at all
> The "they just use your login token" is akin to "they just hacked the CIA's database". Just.
He's saying that they can basically MITM you, which is true. GitHub asks attacker for token, attacker asks you, attacker gives token to GitHub on the spot, presto.
He's saying that they can basically MITM you, which is true. GitHub asks attacker for token, attacker asks you, attacker gives token to GitHub on the spot, presto.
Ah, I did overlook that one.
That said: I remain unconvinced that 2FA is a trivial thing to beat. Now we're talking about an active attempt to impersonate you, as opposed to a general catch-all-the-2fa-less-logins
Put another way: If you ran this phishing site, would you focus your time on the logins with 2FA enabled (which if I've understood correctly means you'd have to catch them in the window the token is valid for) or the logins without?
That said: I remain unconvinced that 2FA is a trivial thing to beat. Now we're talking about an active attempt to impersonate you, as opposed to a general catch-all-the-2fa-less-logins
Put another way: If you ran this phishing site, would you focus your time on the logins with 2FA enabled (which if I've understood correctly means you'd have to catch them in the window the token is valid for) or the logins without?
If you use your phished credentials immediately (e.g. inline with it being phished), then it doesn't make a difference if they are using 2FA. You use the credentials they entered to login from a backend system automatically, and then if that ends up with a 2FA prompt, you show the victim the 2FA phishing page next, instead of redirecting them to the real app/whatever.
This obviously does have its own downsides (you have to maintain a login infrastructure, as well as your phishing infrastructure), but this was even seen before 2FA became common to detect if an incorrect password was entered into the phishing site.
It is definitely an improvement, but TOTP doesn't provide much protection from phishing, and as it becomes more popular more phishers will need to accomodate for them in their campaigns, further reducing their effectiveness here.
This obviously does have its own downsides (you have to maintain a login infrastructure, as well as your phishing infrastructure), but this was even seen before 2FA became common to detect if an incorrect password was entered into the phishing site.
It is definitely an improvement, but TOTP doesn't provide much protection from phishing, and as it becomes more popular more phishers will need to accomodate for them in their campaigns, further reducing their effectiveness here.
> 2FA is designed to authenticate that this is you logging in. Wrong off the bat.
Pretty sure you are in agreement with the post here. IOW, 2FA isn't to authenticate the site.
Most of 2FA I use won't help you assuming the credentials I just gave the phishing site are immediately forwarded to the real thing. I will see a login verification, just like I expected, from the site I expected it to come from. Maybe, just maybe, I might notice that the login location is not where I am, for 2FA implementations that tell you that.
Pretty sure you are in agreement with the post here. IOW, 2FA isn't to authenticate the site.
Most of 2FA I use won't help you assuming the credentials I just gave the phishing site are immediately forwarded to the real thing. I will see a login verification, just like I expected, from the site I expected it to come from. Maybe, just maybe, I might notice that the login location is not where I am, for 2FA implementations that tell you that.
I might be, I took the article at it's title to mean "2FA does not protect you from your password being leaked"
2FA prevents harvesting of passwords - but it just means that they have to be actively (or programmatically) attacking
I suppose if they AlSO have protections against proxying (forbid more than X login/login attempts from a given IP) it might help - but certainly not against spearphishing. Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
Certificate based authentication in theory allows both sides to Authenticate the Other.
I suppose if they AlSO have protections against proxying (forbid more than X login/login attempts from a given IP) it might help - but certainly not against spearphishing. Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
Certificate based authentication in theory allows both sides to Authenticate the Other.
> Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
WebAuthn. The article author dismisses it as basically too inconvenient (they apparently keep their Security Key somewhere out of reach and they struggle to remember the complicated user interaction of... pressing a button)
But WebAuthn is completely effective against phishing.
The closest to plausible attacks are: The bad guys take over the target servers (no reason to phish you); The bad guys persuade you to physically send them your authentication device (truly not everybody can be helped...); The bad guys persuade you to install software under their control on a general purpose PC (this won't work on a Phone) and then you follow their bad instructions to "use" your authenticator with their software to get them in.
Mutually authenticated TLS is in principle viable, and I have used it in machine-to-machine systems, but the UX is atrocious and it has grave privacy problems.
WebAuthn. The article author dismisses it as basically too inconvenient (they apparently keep their Security Key somewhere out of reach and they struggle to remember the complicated user interaction of... pressing a button)
But WebAuthn is completely effective against phishing.
The closest to plausible attacks are: The bad guys take over the target servers (no reason to phish you); The bad guys persuade you to physically send them your authentication device (truly not everybody can be helped...); The bad guys persuade you to install software under their control on a general purpose PC (this won't work on a Phone) and then you follow their bad instructions to "use" your authenticator with their software to get them in.
Mutually authenticated TLS is in principle viable, and I have used it in machine-to-machine systems, but the UX is atrocious and it has grave privacy problems.
I think the conundrum is that such a device uses either a simple UI (like pressing the button), which then is unable to convey to the user which transaction is to be signed off on (the desktop/laptop/phone might be compromised) or the device has its own display and multiple-choice input that'll be too expensive and cumbersome for all to carry around all the time, everywhere.
> Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
It can, simple as that. Some make it moderately more difficult by showing you, say, 9 pictures and asking you to pick the one that's yours. But, again, dead easy to proxy.
It can, simple as that. Some make it moderately more difficult by showing you, say, 9 pictures and asking you to pick the one that's yours. But, again, dead easy to proxy.
Others also ask you to put in only some characters of your password, which is even more troubling because at best they hash them in various configurations when you change password, at worst - they keep it in plaintext.
That’s a really good idea, we should be asking sites to verify themselves with a second factor. Do you know if that’s in use anywhere?
With PAKE schemes such as OPAQUE, you verify the site as well, IIRC, and that can be used to derive a shared secret, I think.
It is my understanding that U2F and Webauthn can't be proxied either, but I forgot the specifics and would appeciate if someone could enlighten me.
Conceptually, you just have to generate a keypair using Diffie-Hellman, and sign a challenge after the session has been opened, so that the server can double-check you have the right key (it already has your public key).
It is my understanding that U2F and Webauthn can't be proxied either, but I forgot the specifics and would appeciate if someone could enlighten me.
Conceptually, you just have to generate a keypair using Diffie-Hellman, and sign a challenge after the session has been opened, so that the server can double-check you have the right key (it already has your public key).
In WebAuthn (and U2F but that's obsolete and you should just implement WebAuthn on a green field system) your credentials are inherently tied to an FQDN yes.
There are two tricks involved. Firstly, your web browser is co-opted to do this work. It knows this is news.ycombinator.com much better than you do. If this wasn't in fact news.ycombinator.com, but looked correct and behaved as expected, you likely would not notice, but the browser checks the name matches for every single individual HTTP transaction.
So if the site fakebank.example tries to do a WebAuthn validation for realbank.example it just plain doesn't work.
Next, for a Security Key or similar FIDO1 device, where you can enroll an unlimited number of sites on a single authenticator since they aren't actually stored on the authenticator - the keys used are encrypted with that FQDN. So if bad guys stole your real authentication database enties at Real Bank (maybe from a backup) they not only can't use them, they can't even play them back to you and have you use them - they only work at all on the real site they were for, they're just random garbage on any other site.
This relies on a two encryption technologies. 1. Public Key Signatures (mostly using elliptic curves but that isn't essential). I can pick two related numbers, tell you one, and then in future you can challenge me to prove I know the other one on different occasions, and you'll know I do even though you don't learn the number. Your Security Key can prove to GitHub that it is still the same Security Key that visited before, despite GitHub not knowing which one that is.
2. AEAD Authenticated Encryption. Modern symmetric encryption not only keeps your data confidential, it can also simultaneously authenticate it, your Security Key knows when given back an encrypted "ID" that it's a real one it issued to this web site, because random IDs will fail the authentication step.
Either of these tricks would arguably achieve our basic security goals, but they are both adding further strengths to the system, so why not have both.
[Edited to clarify some details]
There are two tricks involved. Firstly, your web browser is co-opted to do this work. It knows this is news.ycombinator.com much better than you do. If this wasn't in fact news.ycombinator.com, but looked correct and behaved as expected, you likely would not notice, but the browser checks the name matches for every single individual HTTP transaction.
So if the site fakebank.example tries to do a WebAuthn validation for realbank.example it just plain doesn't work.
Next, for a Security Key or similar FIDO1 device, where you can enroll an unlimited number of sites on a single authenticator since they aren't actually stored on the authenticator - the keys used are encrypted with that FQDN. So if bad guys stole your real authentication database enties at Real Bank (maybe from a backup) they not only can't use them, they can't even play them back to you and have you use them - they only work at all on the real site they were for, they're just random garbage on any other site.
This relies on a two encryption technologies. 1. Public Key Signatures (mostly using elliptic curves but that isn't essential). I can pick two related numbers, tell you one, and then in future you can challenge me to prove I know the other one on different occasions, and you'll know I do even though you don't learn the number. Your Security Key can prove to GitHub that it is still the same Security Key that visited before, despite GitHub not knowing which one that is.
2. AEAD Authenticated Encryption. Modern symmetric encryption not only keeps your data confidential, it can also simultaneously authenticate it, your Security Key knows when given back an encrypted "ID" that it's a real one it issued to this web site, because random IDs will fail the authentication step.
Either of these tricks would arguably achieve our basic security goals, but they are both adding further strengths to the system, so why not have both.
[Edited to clarify some details]
This is called a site key and was made popular by Bank of America. I'm not sure if they still do it.
https://en.wikipedia.org/wiki/SiteKey
https://en.wikipedia.org/wiki/SiteKey
This is a weird post. Yubikeys are absolutley the solution here, also a password manager. A decent password manager will check the URL for you.
There are many legitimate situations in which a login domain is changed and a password manager no longer works. So then you manually open the password manager, look for the password, copy+paste, and save the new entry.
How can you be completely confident that this isn't an attacker?
How can you be completely confident that this isn't an attacker?
Right. One of the good decisions in WebAuthn is that this type of nonsense simply isn't possible. It's designed so that you can't do this. When the big boss absolutely insists that ourcorp.example must rename to xp4ifis.example because of whatever nonsense, there's nothing to argue about, it won't technically work, it can't be done. Like if they decided it would be better branding if up was down, too bad.
In almost all cases these were just about vanity (e.g. the university where I studied and had some of my first jobs renamed itself and gave every web site new URLs, purely out of vanity, at considerable cost with no benefit) and so when they discover it can't be done technically they just give up and continue to use the old name for authentication, meaning your security posture is intact. In the few other cases you're now going to have to have a conversation with your users about why you broke everything and need to begin over. I sure hope the gain to your organisation was worth it.
In almost all cases these were just about vanity (e.g. the university where I studied and had some of my first jobs renamed itself and gave every web site new URLs, purely out of vanity, at considerable cost with no benefit) and so when they discover it can't be done technically they just give up and continue to use the old name for authentication, meaning your security posture is intact. In the few other cases you're now going to have to have a conversation with your users about why you broke everything and need to begin over. I sure hope the gain to your organisation was worth it.
Not too long Scottrade (2 or 3 't'?) got bought by Ameritrade. All Scottrade accounts are now accessed exclusively under the new domain name.
Recently Ameritrade and Charles Schwab Corp. merged ...
Recently Ameritrade and Charles Schwab Corp. merged ...
In that rare case you just check the URL. Contact the company if it is a high value login. You can also verify by searching for the site and clicking through to see what their webpage offers as ground truth.
Another aspect that people always forget is that 2FA protects only the login process.
Any successful attack against your browser (or any other application on your workstation) allows the attacker use existing and future browsing sessions.
The attacker can simply wait until you log onto your bank account and remotely control your browser.
Any successful attack against your browser (or any other application on your workstation) allows the attacker use existing and future browsing sessions.
The attacker can simply wait until you log onto your bank account and remotely control your browser.
Something people here are missing is that unless the phishing site uses your credentials right then and there within the existing session, they can't do much even if they do capture your 2nd factor.
But if the site just captures your credentials and puts them in a database of site/username/passwords, they are useless later, even if they also store your 2nd factor of the moment. The next time someone tries to authenticate with your stolen username and password, and the MFA challenge comes up, they will be stuck. The factor they captured phishing has long expired, and the site has no ability to provide the correct value for your 2nd factor at a later time.
So in other words, 2FA does provide additional protection in this scenario, unless the malicious party has programmed the system to also hijack your session.
I honestly can't say for sure how often the phishing sites use session hijacking vs. just collecting for later use. If the first scenario is most common then no, 2FA doesn't help much. If the second scenario is typical, then 2FA provides significant additional protection over just username/password.
But if the site just captures your credentials and puts them in a database of site/username/passwords, they are useless later, even if they also store your 2nd factor of the moment. The next time someone tries to authenticate with your stolen username and password, and the MFA challenge comes up, they will be stuck. The factor they captured phishing has long expired, and the site has no ability to provide the correct value for your 2nd factor at a later time.
So in other words, 2FA does provide additional protection in this scenario, unless the malicious party has programmed the system to also hijack your session.
I honestly can't say for sure how often the phishing sites use session hijacking vs. just collecting for later use. If the first scenario is most common then no, 2FA doesn't help much. If the second scenario is typical, then 2FA provides significant additional protection over just username/password.
This is true for all 2FA methods but not for FIDO security keys. With FIDO, the hostname of the site you're browsing is signed in the assertion, therefore the attacker -even with automation- can't reuse it on the target site.
This is why FIDO claims protection against phishing.
What the author says is that the attacker, when you're using a FIDO security key, can simply say it's not working and force the user to switch to a different 2FA method, therefore in the end phishing the user.
This is why FIDO claims protection against phishing.
What the author says is that the attacker, when you're using a FIDO security key, can simply say it's not working and force the user to switch to a different 2FA method, therefore in the end phishing the user.
Session jacking can also allow disabling MFA unless sites are careful to re-verify the MFA before doing so. Or before changing the password or adding additional tokens / generating backup codes.
Security is hard. And features make it porous.
Security is hard. And features make it porous.
Yeah, a site needs to issue an MFA challenge to any MFA change attempt.
Nice blog post with interesting views.
I leave my YubiKey plugged in all the time. It's basically a permanent part of the computer.
I leave my YubiKey plugged in all the time. It's basically a permanent part of the computer.
Same, and many websites have support for multiple keys so enroll a couple of the cheap $10 ones (per device) and then you can use TOTP or just printed codes as a backup.
Even if your device is stolen 1) it's unlikely by a technically savvy bad actor (and if you're at risk, you probably have had special data security training anyway) 2) you're still only stealing one factor. Your device should also be encrypted with a password which would protect any passwords [managers] on the device
Even if your device is stolen 1) it's unlikely by a technically savvy bad actor (and if you're at risk, you probably have had special data security training anyway) 2) you're still only stealing one factor. Your device should also be encrypted with a password which would protect any passwords [managers] on the device
Time to implement Password Authenticated Key Exchange, e.g. Secure Remote Password, in the browser?
Here is what I suggest. Let there be a field <input type=pake challenge=blah />. Whatever is typed into that field is unavailable to the front-end code. Instead, the browser computes a one-way function of the password, challenge and origin, and makes that available to the front-end.
The devil is in the details, but I'm pretty sure that a robust security analysis could eventually produce a solution that allows any user to type any password in a "super-password" field, and rest assured that the phishers are out.
The next issues would be: - How to prevent "downgrade" attacks, i.e., the user should immediately notice if a legacy password field is used. - How to convince the Internet to adopt this.
Here is what I suggest. Let there be a field <input type=pake challenge=blah />. Whatever is typed into that field is unavailable to the front-end code. Instead, the browser computes a one-way function of the password, challenge and origin, and makes that available to the front-end.
The devil is in the details, but I'm pretty sure that a robust security analysis could eventually produce a solution that allows any user to type any password in a "super-password" field, and rest assured that the phishers are out.
The next issues would be: - How to prevent "downgrade" attacks, i.e., the user should immediately notice if a legacy password field is used. - How to convince the Internet to adopt this.
+1 for bitwarden as password manager. It did indeed save me a few weeks ago from a phishing attempt. After reporting it to my employer and warning all my colleagues it turned out to be the tech department doing a white hat test to educate the employees :)
"Security Key by Yubico" is significantly cheaper than YubiKey, and supports open-source protocols ("U2F and FIDO2/WebAuthn") but not corporate 2FA protocols. It doesn't address the keychain/password issues though.
> Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
The key is only the second factor. You need to lose the key *and* have your password stolen in order to have your accounts compromised. At that point, think about what you're doing wrong as a user.
The key is only the second factor. You need to lose the key *and* have your password stolen in order to have your accounts compromised. At that point, think about what you're doing wrong as a user.
Correct me if I'm wrong but I've seen oauth implementations that require you to be redirected to the site you're giving credentials for to finish the flow of authentication. Wouldn't this make it a lot easier to determine that you're being phished, if you have to go to a whole different web site that warns you that you are giving external parties access to your credentials?
Indeed, using OAuth everywhere would make the success of such an attack less likely. However, I feel strongly about not letting a single organization act as my identity provider. I don't like putting all eggs in the same basket.
> The average YubiKey is £50. There are a few around the £30 price point. That’s a huge expense given the small number of sites that support them.
A wide variety of sites support them. I'd estimate around 1/3rd of the services I use daily (both personally and for work) support them. (That said, I got mine for $30 by signing up for a magazine subscription, and wouldn't have paid significantly more. And, of course, some of my services have been chosen because they differentiated themelves from the competition by Yubikey support.)
> Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.
Except, with U2F, that's not true. It's just "buy a device, plug it in, find the place on the website, wait for a prompt, press a button".
> Convenience. My YubiKey is on my keyring. My keys are in my coat.
That's a pretty personal problem. For me, my keys are either on my belt loop or on my desk, which means it's always handy. Of course, you can also get one of the models which is designed to stay plugged in, if that is compliant with your threat model.
> Risk. YubiKeys have no password lock of their own. ... if you’ve stolen my laptop and the YubiKey is plugged in
True, which is why they're not generally suitable for standalone use; only as a second credential. Also, if your threat model has you worried about them being stolen together, simply don't leave them plugged in together.
> Support. WebAuthn is a great standard – but only a few sites support it.
That's still as false it was when it was your first point.
> If fake-github.com said “Hmmm we’re having problems with our WebAuthn backend – please use a one-time code from your authenticator app for added security” would you be fooled?
At the very least, it would probably cause me to double-check that I was on a legit site.
Overall: I don't think you give enough credence to the fact that it's real, secure, convenient 2FA. No more digging your phone out of your pocket, unlocking it, navigating to the app, and then setting your phone down so you can type in the code. And then locking your phone and putting it back away.
Personally, my Yubikey goes into my laptop at the start of the work day (the first time I use it), and it doesn't come out until I'm done working (well, or if I need to use my keys). All I have to do is tap the button after I put my password in.
A wide variety of sites support them. I'd estimate around 1/3rd of the services I use daily (both personally and for work) support them. (That said, I got mine for $30 by signing up for a magazine subscription, and wouldn't have paid significantly more. And, of course, some of my services have been chosen because they differentiated themelves from the competition by Yubikey support.)
> Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.
Except, with U2F, that's not true. It's just "buy a device, plug it in, find the place on the website, wait for a prompt, press a button".
> Convenience. My YubiKey is on my keyring. My keys are in my coat.
That's a pretty personal problem. For me, my keys are either on my belt loop or on my desk, which means it's always handy. Of course, you can also get one of the models which is designed to stay plugged in, if that is compliant with your threat model.
> Risk. YubiKeys have no password lock of their own. ... if you’ve stolen my laptop and the YubiKey is plugged in
True, which is why they're not generally suitable for standalone use; only as a second credential. Also, if your threat model has you worried about them being stolen together, simply don't leave them plugged in together.
> Support. WebAuthn is a great standard – but only a few sites support it.
That's still as false it was when it was your first point.
> If fake-github.com said “Hmmm we’re having problems with our WebAuthn backend – please use a one-time code from your authenticator app for added security” would you be fooled?
At the very least, it would probably cause me to double-check that I was on a legit site.
Overall: I don't think you give enough credence to the fact that it's real, secure, convenient 2FA. No more digging your phone out of your pocket, unlocking it, navigating to the app, and then setting your phone down so you can type in the code. And then locking your phone and putting it back away.
Personally, my Yubikey goes into my laptop at the start of the work day (the first time I use it), and it doesn't come out until I'm done working (well, or if I need to use my keys). All I have to do is tap the button after I put my password in.
I think password managers are the first step you should take and FIDO/U2F hardware keys are the second similar important step.
With that even if your password manager get hacked you still have a secure account as they didn't got the U2F at the same time a password manager is a must have as it's prevents a lot of phishing attacks from even getting any chance and is quite convenient, too.
The problem with hardware keys is that for many people they are not so easy:
- You MUST generate and safely store recovery keys, storing them in your password manager is suboptimal, but better then not having them. (Not having them means potentially losing account access permanently.)
- You often need to enable it.
- You should store it with your keys, which dependent on habit might not be around your PC (in my case they always are in my pocket so :=) ).
- If your site doesn't support U2F/FIDO you might need an additional phone + app, or laptop app to get the numbers out of your key.
So while I think it's a must have for every developer to have a hardware security token lie a Yubikey it's not something I could convince e.g. my Dad or Sisters to use.
With that even if your password manager get hacked you still have a secure account as they didn't got the U2F at the same time a password manager is a must have as it's prevents a lot of phishing attacks from even getting any chance and is quite convenient, too.
The problem with hardware keys is that for many people they are not so easy:
- You MUST generate and safely store recovery keys, storing them in your password manager is suboptimal, but better then not having them. (Not having them means potentially losing account access permanently.)
- You often need to enable it.
- You should store it with your keys, which dependent on habit might not be around your PC (in my case they always are in my pocket so :=) ).
- If your site doesn't support U2F/FIDO you might need an additional phone + app, or laptop app to get the numbers out of your key.
So while I think it's a must have for every developer to have a hardware security token lie a Yubikey it's not something I could convince e.g. my Dad or Sisters to use.
Let's say I've got 2FA enabled. I get a confirmation link to my e-mail. I click the link. Because the e-mail is sent by the real site, the link leads to the non-phishing site. The scammer has my password, but is still unable to access the site. How does that not help?
Of course if it's a 6-digit code or something, then they are able to stole my it like they did with the password.
Of course if it's a 6-digit code or something, then they are able to stole my it like they did with the password.
I wouldn’t call sending codes by email “true” 2FA, though, since your email address can also be used to reset your password.
Although I agree that 2FA like Google Auth/Authy/etc. doesn't authentify the site, I'd like to comment on this:
> Then the fake site uses your real token and logs in as you. > > Game Over.
Depending on how the site's security work, it's not totally game over. I've seen sites, optionally (you still have to turn the feature on), requiring a 72 hours delay before any setup change is taken into account (like, say, a password change). During this time a warning is sent by email and you can at any time during these 72 hours, unilaterally, prevent the change from happening.
So it may be "game over" in that the attacker can login and see all you account/activity/data (which, yes, is really bad) but it's not totally "game over" as in it doesn't mean "logged out of your account" (unless the attacker also compromised your email ofc, but now we're talking about something else).
> Then the fake site uses your real token and logs in as you. > > Game Over.
Depending on how the site's security work, it's not totally game over. I've seen sites, optionally (you still have to turn the feature on), requiring a 72 hours delay before any setup change is taken into account (like, say, a password change). During this time a warning is sent by email and you can at any time during these 72 hours, unilaterally, prevent the change from happening.
So it may be "game over" in that the attacker can login and see all you account/activity/data (which, yes, is really bad) but it's not totally "game over" as in it doesn't mean "logged out of your account" (unless the attacker also compromised your email ofc, but now we're talking about something else).
You don't need a $50 Yubikey token to do U2F, there are ones in the $10-15 range.
Most sites that support U2F support enrolling multiple tokens, so just have one in each machine.
Theft of a machine still needs your password to access the accounts, so it's not "keys to the kingdom" as the article suggests.
I feel that this article is... wrong.
Most sites that support U2F support enrolling multiple tokens, so just have one in each machine.
Theft of a machine still needs your password to access the accounts, so it's not "keys to the kingdom" as the article suggests.
I feel that this article is... wrong.
There is another issue, I think, with Cloudflare serving in the middle.
For many websites the Cert is owned by Cloudflare and shows Cloudflare as the Organization and not the website owner. In that case there is no way for me to figure out whether I'm on the actual site or a phished site.
For example see this (it is the Visa opt-out website that was posted a few days ago on HN): https://marketingreportoptout.visa.com/OPTOUT/request.do
Supposedly the above it authentic, but the Cert is showing Cloudflare as the Organization. Now unless the claim is that Cloudflare will never serve phished websites, which I doubt unless Cloudflare is doing a human validation for each client, this is a problem.
For many websites the Cert is owned by Cloudflare and shows Cloudflare as the Organization and not the website owner. In that case there is no way for me to figure out whether I'm on the actual site or a phished site.
For example see this (it is the Visa opt-out website that was posted a few days ago on HN): https://marketingreportoptout.visa.com/OPTOUT/request.do
Supposedly the above it authentic, but the Cert is showing Cloudflare as the Organization. Now unless the claim is that Cloudflare will never serve phished websites, which I doubt unless Cloudflare is doing a human validation for each client, this is a problem.
This is an issue with any domain-verified TLS certificate, which make up the overwhelming majority of certificates in use. Only CAs which offer organization-verified (OV) or extended-verified (EV) certificates, typically at exorbitant prices, does the TLS certificate attest the publisher of the website.
> Only CAs which offer organization-verified (OV) or extended-verified (EV) certificate, typically at exhorbitant prices, does the TLS certificate attest the publisher of the website.
Even so, I’ll expect financial institutions to have that.
Note: I’m not saying the above is a Cloudflare issue, perhaps someone at Visa was being stingy - I’m just saying it’s an issue and would be bad if that becomes the mainstream.
Even so, I’ll expect financial institutions to have that.
Note: I’m not saying the above is a Cloudflare issue, perhaps someone at Visa was being stingy - I’m just saying it’s an issue and would be bad if that becomes the mainstream.
2FA can actually prevent phishing, though it requires close integration with the app and the authenticator. It's actually quite similar to CSRF prevention. On the site itself, display a random nonce to the user for confirmation then send an request for authentication to the authenticator with said nonce which the user can confirm. The battle.net authenticator does this.
For added protection, you can prompt the user to select which nonce is correct to force them to verify it is correct. The Microsoft authenticator does this sometimes.
The downside of this approach is that it requires a constant connection between the second factor the service. It also relies on the fact that the service authenticates itself via TLS or some other means, though that is a relatively minor issue.
For added protection, you can prompt the user to select which nonce is correct to force them to verify it is correct. The Microsoft authenticator does this sometimes.
The downside of this approach is that it requires a constant connection between the second factor the service. It also relies on the fact that the service authenticates itself via TLS or some other means, though that is a relatively minor issue.
FIDO is a subset of 2FA, and it's one of the protocols that yubikeys etc. implement. While it won't protect you from all attacks, it does make the standard MITM harder.
To take the OP's example, if by mistake you are tricked into visting githud.com or something, they can get your password (bad!) but if they try and MITM the FIDO, they'll send a digitally signed message for githud.com on to github.com. This will not work as intended (except for the user, because their github account isn't compromised yet.)
Indeed the point of FIDO as I see it is that it's less security critical for the end user to validate the identity of the site, which optimistically speaking about 95% of users will fail at anyway.
To take the OP's example, if by mistake you are tricked into visting githud.com or something, they can get your password (bad!) but if they try and MITM the FIDO, they'll send a digitally signed message for githud.com on to github.com. This will not work as intended (except for the user, because their github account isn't compromised yet.)
Indeed the point of FIDO as I see it is that it's less security critical for the end user to validate the identity of the site, which optimistically speaking about 95% of users will fail at anyway.
I recently experimented with the Yubikey OTP feature. Like TOTP, it can be proxied through as there's no challenge that includes signing the website name like FIDO. Also.. The Yubico OTP feature types using QWERTY with letters and no numbers. As I use dvorak, this resulted in considerable confusion as two yubikeys behaved the same.
Interestingly, copying the credentials between Yubikeys will not result in an accepted yubikey OTP. The serial seems to be used somewhere in the calculation.
A yubikey, using the CLI tool, can have TOTP credentials stored inside. This can be used in conjunction with grep and sed for any CLI scripts that may interactively request a TOTP.
Interestingly, copying the credentials between Yubikeys will not result in an accepted yubikey OTP. The serial seems to be used somewhere in the calculation.
A yubikey, using the CLI tool, can have TOTP credentials stored inside. This can be used in conjunction with grep and sed for any CLI scripts that may interactively request a TOTP.
Is there potential for a simple popup in, say, 1Passwordx Chrome extension that, if the base url doesn't exist in any key chains, that reminds us to watch for phishing sites?
I have a question: if a website is clearly involved in phishing how does one report such a website and what is the process of blocking the domain name and chasing the owner?
I think the negative aspects stated by the "hardware authentication device" is overkill. It's really easy to use and cost is relative (gets cheaper with use). May be real issue is that we're not using these new solutions and are still relying on unnecessarily complex passwords to save with master passwords. In some cases, 2FA can be a pain in the butt to manage when you have hundreds of them. A couple hardware keys and voila.
https://www.amazon.in/Auto-ePass-2003-FIPS-Token/dp/B00S7LUL...
does anyone know if its posible to reuse these fips pki tokens? they are cheap enough.....
does anyone know if its posible to reuse these fips pki tokens? they are cheap enough.....
It's essentially a smartcard (certificate storage) in a more convenient form factor for most users, so you could use them to store your RSA keys - though personally I would not trust them - but they are not FIDO/FIDO2 so they are almost useless in the context of the article.
> WebAuthn and hardware tokens are probably the future. And they’re probably the best way we have to verify site legitimacy. But they’re also currently a poorly supported usability disaster.
I was looking for the punchline but it seems like there isn't one. Complaining about hardware tokens and then saying they are the future doesn't contribute much...
I was looking for the punchline but it seems like there isn't one. Complaining about hardware tokens and then saying they are the future doesn't contribute much...
The author of this article has no idea how 2FA works or why it's used.
2FA is used to prevent or mitigate the impact of phishing or other attacks where a password is compromised (password reuse, random guessing, keylogger, etc.). The author does bring up one hypothetical attack -- a man-in-the-middle attack -- where someone can trick a user into providing their 2FA or triggering an authorization (like with a Duo push). This requires the ability to execute a real-time attack.
FIDO/U2F/Webauthn (I still haven't figured out exactly what you're supposed to call them) security tokens solve that use case by allowing the website to authenticate directly to the token. That can't be phished -- even if you're tricked into a fake website and given a fake webauthn prompt, AFAIK there's no known way to proxy or otherwise intercept that second factor authentication to allow a phishing attack to succeed.
His complaint that the token doesn't have a password is largely pointless -- the token is the second factor, the password on the site is the first. If you're using passwordless FIDO2 logins, then it does have a PIN.
Long story short, this guy is full of crap.
2FA is used to prevent or mitigate the impact of phishing or other attacks where a password is compromised (password reuse, random guessing, keylogger, etc.). The author does bring up one hypothetical attack -- a man-in-the-middle attack -- where someone can trick a user into providing their 2FA or triggering an authorization (like with a Duo push). This requires the ability to execute a real-time attack.
FIDO/U2F/Webauthn (I still haven't figured out exactly what you're supposed to call them) security tokens solve that use case by allowing the website to authenticate directly to the token. That can't be phished -- even if you're tricked into a fake website and given a fake webauthn prompt, AFAIK there's no known way to proxy or otherwise intercept that second factor authentication to allow a phishing attack to succeed.
His complaint that the token doesn't have a password is largely pointless -- the token is the second factor, the password on the site is the first. If you're using passwordless FIDO2 logins, then it does have a PIN.
Long story short, this guy is full of crap.
Slightly OT: Odd timing but one of my services sent me a push notification earlier about setting up a "personalised code" which would be included in all emails. I thought this to be a novel way that could _help_ with the email phishing problem, if adopted and implemented properly.
The user still has to notice that the personal code is missing in the phishing emails.
If you could trust users with "always check for this personal code in the emails, ignore emails without it" we could also trust them with "your bank will never email you a login link"
If you could trust users with "always check for this personal code in the emails, ignore emails without it" we could also trust them with "your bank will never email you a login link"
for one, html email is vicious, terminal email clients can help to not fool you with visual alignment.
I like the feature `From: <> via <>` in the view, maybe this tipped her off - "palette.cloud" is an unlikely envelope-sender for github mail. Reactivating an old gmail account, I can't see how to enable the feature.
In a muttrc, you can get context with showing you more headers.
I like the feature `From: <> via <>` in the view, maybe this tipped her off - "palette.cloud" is an unlikely envelope-sender for github mail. Reactivating an old gmail account, I can't see how to enable the feature.
In a muttrc, you can get context with showing you more headers.
ignore *
unignore from: to: cc: date: subject: user-agent: x-mailer: return-path: authentication-results:
hdr_order date: from: return-path: to: subject: user-agent: x-mailer: authentication-results:
Fake 2FA works if it's stateless, eg entering a code from Authy or a physical token.
However, stateful 2FA like sending an SMS to your phone, or popping up a notification on your banking app is much harder to spoof, and would have protected the user here.
However, stateful 2FA like sending an SMS to your phone, or popping up a notification on your banking app is much harder to spoof, and would have protected the user here.
Is GPG Auth the answer?
It is tied to the site keys and not the address nor even the CAs.
It forces you to check and think before doing your thing.
And It is easier to use than 2FA, since it is one factor, open your key one time, the key auths you as long as you want.
It is tied to the site keys and not the address nor even the CAs.
It forces you to check and think before doing your thing.
And It is easier to use than 2FA, since it is one factor, open your key one time, the key auths you as long as you want.
This is why password managers are so important.
A password manager won't offer to auto-complete if the protocol/domain does not match with what you've saved. This is an immediate red-flag that something fishy is up.
A password manager won't offer to auto-complete if the protocol/domain does not match with what you've saved. This is an immediate red-flag that something fishy is up.
The author recommends BitWarden, but it seems like it's run by one guy. How do I know he doesn't go away? Get hit by a bus?
You don't but any good password manager should have an option to migrate away from it quickly.
run your own instance of Bitwarden.. there's a nice dockerized server available written in Rust
>>> The top result on Google is invariably an advert for a scam site.
Wait what now?
Wait what now?
The criticism of YubiKey seems kind of unfair. For one thing, it doesn't actually explicitly state that they totally address the major issues in the article.
Instead it's "in theory" and "can help". No, it totally addresses the issue of phishing your 2FA token and it does so in practice.
The pricepoint mentioned is over twice what the cheapest Yubikey is - $24.99 [0]. The author states the "average" cost is £50 and "there are a few around £30". Again, 24.99USD for USB + NFC yubikeys that support U2F/webauthn.
'usability' and 'convenience' are the same thing but split into two points, which give the impression that there's a whole other issue, but it's really the same thing.
> Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time
So for TOTP it's install the app, configure it, find the setting on the website, enable it. So Yubikey adds the one additional step of "buy it", all of the others are the same for all other forms of 2FA. "Press the button at the right time" come on... as opposed to "find the TOTP and type it in on time" ?
The 24.99 USB Yubikey also supports NFC, so like, "has USB or NFC" is the requirement - I'm seriously struggling to think of a device that doesn't meet this requirement.
The author states that leaving the yubikey in the laptop increases risk. I find this to be a mixing of threat models personally - we've solved credential phishing with the 2FA token, but now you're talking about a threat where the attacker has unfettered physical access? I just don't see why that's relevant, sorry.
And for support, I think it's important to note that most sites are not sensitive. But a couple of important sites are. The most important is probably email, since email is effectively an auth mechanism for most other sites via account recovery. So just by protecting email you're protecting every other site. That's really important.
IMO,
Yes, Yubikeys should get cheaper. I certainly hope they do. At my company I give every employee 2 Yubikeys and they are theirs to keep - they're free to use them for personal accounts. I hope more companies do this in the future, essentially distributed U2F to the workforce.
But, otherwise, I really think that the benefits are being drastically undersold and I think that the criticisms are really not particularly fair.
[0] https://www.yubico.com/product/security-key-nfc-by-yubico/
Instead it's "in theory" and "can help". No, it totally addresses the issue of phishing your 2FA token and it does so in practice.
The pricepoint mentioned is over twice what the cheapest Yubikey is - $24.99 [0]. The author states the "average" cost is £50 and "there are a few around £30". Again, 24.99USD for USB + NFC yubikeys that support U2F/webauthn.
'usability' and 'convenience' are the same thing but split into two points, which give the impression that there's a whole other issue, but it's really the same thing.
> Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time
So for TOTP it's install the app, configure it, find the setting on the website, enable it. So Yubikey adds the one additional step of "buy it", all of the others are the same for all other forms of 2FA. "Press the button at the right time" come on... as opposed to "find the TOTP and type it in on time" ?
The 24.99 USB Yubikey also supports NFC, so like, "has USB or NFC" is the requirement - I'm seriously struggling to think of a device that doesn't meet this requirement.
The author states that leaving the yubikey in the laptop increases risk. I find this to be a mixing of threat models personally - we've solved credential phishing with the 2FA token, but now you're talking about a threat where the attacker has unfettered physical access? I just don't see why that's relevant, sorry.
And for support, I think it's important to note that most sites are not sensitive. But a couple of important sites are. The most important is probably email, since email is effectively an auth mechanism for most other sites via account recovery. So just by protecting email you're protecting every other site. That's really important.
IMO,
Yes, Yubikeys should get cheaper. I certainly hope they do. At my company I give every employee 2 Yubikeys and they are theirs to keep - they're free to use them for personal accounts. I hope more companies do this in the future, essentially distributed U2F to the workforce.
But, otherwise, I really think that the benefits are being drastically undersold and I think that the criticisms are really not particularly fair.
[0] https://www.yubico.com/product/security-key-nfc-by-yubico/
> A second factor allows a site to better authenticate you. It does not help you identify the site.
That's correct. On the first visit (or enrolment).
All subsequent visits (many more!) do identify the site, or rather they tell you that you're logging in to the same site as all those times before.
That's correct. On the first visit (or enrolment).
All subsequent visits (many more!) do identify the site, or rather they tell you that you're logging in to the same site as all those times before.
With an email link or a Yubikey it might, but with SMS or an Authenticator app it doesn't add any extra way for me to identify the site.
> All subsequent visits (many more!) do identify the site, or rather they tell you that you're logging in to the same site as all those times before.
I don't understand what you mean. Something about 2FA does this? How?
I don't understand what you mean. Something about 2FA does this? How?
The U2F protocol (that Yubikey and others use) is based on a cryptographic challenge-response mechanisms, and it includes the domain of the service you're logging into, as supplied by the browser.
The details are complicated, but basically: If you register the key at github.com and later get phished to visit githubverification.com, then the authentication will fail no matter what the phisher does.
The details are complicated, but basically: If you register the key at github.com and later get phished to visit githubverification.com, then the authentication will fail no matter what the phisher does.
Specifically, the phisherman's options for a typical Security Key (a physical authenticator device you buy and maybe plug into a USB port) are:
* Spew random crap claiming it is your githubverification.com key ID, ask you to sign in with this ID. Your authenticator won't recognise this ID and it doesn't work
* Proxy your real ID from github.com and present that from githubverification.com asking you to sign in. Your authenticator won't recognise this ID because it's for the wrong site, though it doesn't know that's why. It doesn't work.
* Proxy the ID from github.com and insist this is github.com. Your browser says "Er, no? This isn't github.com fool" and the UX doesn't fire.
Notice that the attacker not only doesn't get working credentials for signing into GitHub, they don't even get broken failed credentials that don't work, they just get a Javascript error at best.
* Spew random crap claiming it is your githubverification.com key ID, ask you to sign in with this ID. Your authenticator won't recognise this ID and it doesn't work
* Proxy your real ID from github.com and present that from githubverification.com asking you to sign in. Your authenticator won't recognise this ID because it's for the wrong site, though it doesn't know that's why. It doesn't work.
* Proxy the ID from github.com and insist this is github.com. Your browser says "Er, no? This isn't github.com fool" and the UX doesn't fire.
Notice that the attacker not only doesn't get working credentials for signing into GitHub, they don't even get broken failed credentials that don't work, they just get a Javascript error at best.
What about certificates? The fake GitHub almost certainly does not have a valid certificate. Isn’t that our one defense against these things?
The problem that a certificate just assures us this is indeed https://githubverification.com/ which it is
This leaves a human to try to make deductions about whether githubverification.com is github.com which is something humans are terrible at, so game over.
If you have WebAuthn then your browser also takes responsibility for only letting you use your github.com credentials on github.com and not even bothering you with any other possibilities that you might think could be safe and are not. That's why WebAuthn prevents phishing.
This leaves a human to try to make deductions about whether githubverification.com is github.com which is something humans are terrible at, so game over.
If you have WebAuthn then your browser also takes responsibility for only letting you use your github.com credentials on github.com and not even bothering you with any other possibilities that you might think could be safe and are not. That's why WebAuthn prevents phishing.
This is a good article about the weaknesses of the trust models of navigation on the web. The author uses a password manager that also fulfills the role of a personal 'have I seen this site before?' database, which helps them associate a URL to its conceptual entity, in their quest to determine if the site they visited was the site they intended to visit.
In this exact form, this is a feature that's absent from mainstream browsers today. Because browsers do not have this, people instead turn to all sorts of other signals to judge the site's identity, but each one of those signals is designed for another purpose, and ought to not to be used directly by the user to make such determination. But no other signals are available, so they get used nonetheless.
Some people look at the URL before clicking it, or the URL bar in the browser after they've already navigated to the site, and try to judge from the URL whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including: (1) people often read visually instead of comparing codepoint-by-codepoint, so reading errors or homoglyph attacks are possible, and browsers can only meaningfully mitigate against the latter; (2) very few people keep a computerized allow-list, so they check against expectations in their head; and (3) some organizations will make use of domain names that greatly differ from their own name, which works contrary to the instinct of a URL-judging user who consider themselves 'cautious', and it's difficult to stay aware of all this.
Some people look at the TLS certificate, and try to judge from the information displayed by the browser about the cert whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including (1) DV certs only prove that someone (i.e. anyone) had control of the domain at the time near the cert's issuance, so its value as a trust signal to the user ought to be zero and immediately reduce to the prior case of mentally validating the URL by its character content; (2) EV certs validate against a legal entity in some jurisdiction, but as the 'stripe.ian.sh' stunt has demonstrated, jurisdiction-by-juristiction registries of legal entities are a tool for a different use-case and were never intended to collectively ensure globally unique Organization names; and (3) in their rush to ensure widespread TLS deployment on all sites, and their involvement with efforts to bring short-lived cost-free DV certs to everyone, browser-makers began de-emphasizing the UI distinctions between DV certs and EV certs some time before the true shortcomings of EV as a user-facing trust signal were widely demonstrated.
Some people look for the visual design of the website. This is trivial to fake.
Some people will rely on browser-resident bookmarks, browser history, or 'top sites' tiles to navigate to common sites they've visited before (or to sites the browser-maker pre-loaded into the listing). This is a great way to preserve the trust chain and reduce the likelihood that the user arrives at an unintended site by mistake. But these features do not directly address the case of a person navigating to a URL they were linked or provided from an arbitrary source, such as the example raised in the article.
Building blocks exist today that could be used by publishers and browser-makers to aid users in judging URLs. Some of these will require past UX decisions to be undone.
For example, top sites could become their own Root Certificate Authorities [1] and be listed in browser trust stores; these companies would be expected to issue certs for sites associated to themselves. This would eventually reshape the cert landscape so that a parent-child relationship between issuer and subject could be meaningfully distinguished from a 'provider and customer' relationship. Companies that provide services to others, such as payment processors, could also become root CAs and sign for their customers. These changes, and a browser UX that once again shows the cert issuer, would go a long way towards reducing the likelihood that users are fooled by sites trying to impersonate top sites.
If this were to come to pass, other CAs would be expected to pivot to minting certs that play the role of a trustmark, by conferring a degree of ongoing assurance that's useful to the user (which, in fairness, was the original point behind EV certs). They would do this by establishing strong brands around their trustmark, issue certs for a short lifetime, and monitor the site on an ongoing basis to see if it's still deserving of their trustmark. This would result in a business model similar to those of EV certs, but a trust model that's based on the user's trust in the CA's exercise of good judgment befitting their brand.
[1] https://news.ycombinator.com/item?id=13495262
In this exact form, this is a feature that's absent from mainstream browsers today. Because browsers do not have this, people instead turn to all sorts of other signals to judge the site's identity, but each one of those signals is designed for another purpose, and ought to not to be used directly by the user to make such determination. But no other signals are available, so they get used nonetheless.
Some people look at the URL before clicking it, or the URL bar in the browser after they've already navigated to the site, and try to judge from the URL whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including: (1) people often read visually instead of comparing codepoint-by-codepoint, so reading errors or homoglyph attacks are possible, and browsers can only meaningfully mitigate against the latter; (2) very few people keep a computerized allow-list, so they check against expectations in their head; and (3) some organizations will make use of domain names that greatly differ from their own name, which works contrary to the instinct of a URL-judging user who consider themselves 'cautious', and it's difficult to stay aware of all this.
Some people look at the TLS certificate, and try to judge from the information displayed by the browser about the cert whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including (1) DV certs only prove that someone (i.e. anyone) had control of the domain at the time near the cert's issuance, so its value as a trust signal to the user ought to be zero and immediately reduce to the prior case of mentally validating the URL by its character content; (2) EV certs validate against a legal entity in some jurisdiction, but as the 'stripe.ian.sh' stunt has demonstrated, jurisdiction-by-juristiction registries of legal entities are a tool for a different use-case and were never intended to collectively ensure globally unique Organization names; and (3) in their rush to ensure widespread TLS deployment on all sites, and their involvement with efforts to bring short-lived cost-free DV certs to everyone, browser-makers began de-emphasizing the UI distinctions between DV certs and EV certs some time before the true shortcomings of EV as a user-facing trust signal were widely demonstrated.
Some people look for the visual design of the website. This is trivial to fake.
Some people will rely on browser-resident bookmarks, browser history, or 'top sites' tiles to navigate to common sites they've visited before (or to sites the browser-maker pre-loaded into the listing). This is a great way to preserve the trust chain and reduce the likelihood that the user arrives at an unintended site by mistake. But these features do not directly address the case of a person navigating to a URL they were linked or provided from an arbitrary source, such as the example raised in the article.
Building blocks exist today that could be used by publishers and browser-makers to aid users in judging URLs. Some of these will require past UX decisions to be undone.
For example, top sites could become their own Root Certificate Authorities [1] and be listed in browser trust stores; these companies would be expected to issue certs for sites associated to themselves. This would eventually reshape the cert landscape so that a parent-child relationship between issuer and subject could be meaningfully distinguished from a 'provider and customer' relationship. Companies that provide services to others, such as payment processors, could also become root CAs and sign for their customers. These changes, and a browser UX that once again shows the cert issuer, would go a long way towards reducing the likelihood that users are fooled by sites trying to impersonate top sites.
If this were to come to pass, other CAs would be expected to pivot to minting certs that play the role of a trustmark, by conferring a degree of ongoing assurance that's useful to the user (which, in fairness, was the original point behind EV certs). They would do this by establishing strong brands around their trustmark, issue certs for a short lifetime, and monitor the site on an ongoing basis to see if it's still deserving of their trustmark. This would result in a business model similar to those of EV certs, but a trust model that's based on the user's trust in the CA's exercise of good judgment befitting their brand.
[1] https://news.ycombinator.com/item?id=13495262
> The top result on Google is invariably an advert for a scam site.
Um... no?
Um... no?
Try browsing the web without an ad blocker. The top results on Google search are always adverts. And, quite often, they link to scam sites.
There are loads of copycat websites which appear in the top slot - especially for government site. https://www.which.co.uk/consumer-rights/advice/how-to-spot-a...
It's particularly prevalent in the UK, where you see companies proxying legitimate services and charging premium rate for phone calls - https://www.theguardian.com/money/2017/feb/04/beware-call-co...
There are loads of copycat websites which appear in the top slot - especially for government site. https://www.which.co.uk/consumer-rights/advice/how-to-spot-a...
It's particularly prevalent in the UK, where you see companies proxying legitimate services and charging premium rate for phone calls - https://www.theguardian.com/money/2017/feb/04/beware-call-co...
Can you give me an actual example of this with a google search right now?
In the UK there was a problem of commercial companies setting up look-alike websites and charging a fee to do stuff that is free to do via the correct gov website. It's not as common now, partly because UK orgs put pressure on Google to fix it.
Here's an example:
[change name deed poll]
https://www.google.co.uk/search?sxsrf=ALeKk00J9KQR_SH1ZlvHgi...
For me the top four links are clearly marked ads. (Although some people may miss that [ad] marker). After the ads there are two links to the proper gov.uk website. Then there's a link to a commercial site called "Deed Poll Office", who charge for a services that's free.
In the past that TheDeedPollOffice link ranked higher.
Similar things used to happen for passports and tax self assessment.
Here's an example:
[change name deed poll]
https://www.google.co.uk/search?sxsrf=ALeKk00J9KQR_SH1ZlvHgi...
For me the top four links are clearly marked ads. (Although some people may miss that [ad] marker). After the ads there are two links to the proper gov.uk website. Then there's a link to a commercial site called "Deed Poll Office", who charge for a services that's free.
In the past that TheDeedPollOffice link ranked higher.
Similar things used to happen for passports and tax self assessment.
I just did an ingonito search for "!g ETA",
I got 3 results on the screen
CanadianTravel - ETA Ad·www.canadaonlineapplication.org/
CanadianTravel - ETA Ad·www.canadatravelvisa.com/
CanadaETA - for UK citiziens - canadian-etavisas.com Ad·www.canadian-etavisas.com/
Which all look the same, and seem to charge $99 for the 'service' of filling in a form the Canadian government charges $7 for.
After that there is a wikipage for the Spanish terrorist group, two more wiki pages, then finally
The official site: Electronic Travel Authorization (eTA): How to apply - Canada.ca
Searching google for "Canada ETA" gives the above 3 adverts and also a link to https://www.etatocanada.com/ which charges £69 for the service.
I got 3 results on the screen
CanadianTravel - ETA Ad·www.canadaonlineapplication.org/
CanadianTravel - ETA Ad·www.canadatravelvisa.com/
CanadaETA - for UK citiziens - canadian-etavisas.com Ad·www.canadian-etavisas.com/
Which all look the same, and seem to charge $99 for the 'service' of filling in a form the Canadian government charges $7 for.
After that there is a wikipage for the Spanish terrorist group, two more wiki pages, then finally
The official site: Electronic Travel Authorization (eTA): How to apply - Canada.ca
Searching google for "Canada ETA" gives the above 3 adverts and also a link to https://www.etatocanada.com/ which charges £69 for the service.
So.... not a scam, in that you get exactly what you pay for. And certainly not phishing, which this article was talking about.
How is this not a scam? The company is just presenting their form to ask for the same information, relaying it to the government, and charging you $90 for the privilege.
To me a scam involves paying money and then not getting anything for it. You get exactly what you pay for.
These is just competing businesses / orgs vying for your custom, where one org (the govt) is charging $0, so you should totally use them, but won't if you're foolish.
Regardless, one tiny example of all google results (goverment form services) is... the vast minority of google search results. It is certainly not "invariably" a scam.
These is just competing businesses / orgs vying for your custom, where one org (the govt) is charging $0, so you should totally use them, but won't if you're foolish.
Regardless, one tiny example of all google results (goverment form services) is... the vast minority of google search results. It is certainly not "invariably" a scam.
How can this pass through Google's quality controls that scam sites can get advertising?
...quality controls? They're paying customers, Google has no incentive to prevent scam sites, which is why the results and adverts are infested with them, and have been for decades.
It seems to be against AdSense's rules, however.
Apparently they aren't so enforced.
Good thing that Google is still going after you if your website has nudity on it it, however. — 'tis very important.
Apparently they aren't so enforced.
Good thing that Google is still going after you if your website has nudity on it it, however. — 'tis very important.
That is quite incorrect. Google has more incentive than anyone else to deliver only the best results and ads to searchers. Delivering them to scams harms their reputation and would eventually erode the CTR.
Yes, 2FA won't protect you from being phished by a site if you aren't careful. 2FA absolutely will protect you from a phishing site using the password it stole.
So no, when someone says "Use 2FA if you might be phished" you shouldn't be replying "That's not how 2FA works", you should reply "That's right! But let me explain why you are still at risk of password theft and should still be careful."