Beyond Passwords: 2FA, U2F and Google Advanced Protection(troyhunt.com)
troyhunt.com
Beyond Passwords: 2FA, U2F and Google Advanced Protection
https://www.troyhunt.com/beyond-passwords-2fa-u2f-and-google-advanced-protection/
174 comments
>IMHO the UX for all this stuff is very confusing to non technical users
It's quite confusing for technical users as well. Google has or is in the process of deprecating TOTP, and will make new users/accounts to use something else based on their android app (which is quite likely proprietary and/or tied to gms, push notifications etc.) if they don't use hardware keys. Or they'll force you to use SMS, which is also worse than TOTP. I think it is still possible to use TOTP if you jump through some hoops, but this is yet another case of some rubbish policy. Ref: https://github.com/andOTP/andOTP/issues/219
It's quite confusing for technical users as well. Google has or is in the process of deprecating TOTP, and will make new users/accounts to use something else based on their android app (which is quite likely proprietary and/or tied to gms, push notifications etc.) if they don't use hardware keys. Or they'll force you to use SMS, which is also worse than TOTP. I think it is still possible to use TOTP if you jump through some hoops, but this is yet another case of some rubbish policy. Ref: https://github.com/andOTP/andOTP/issues/219
It would be great if sites had an option to remove reset support for your account permanently. One that is literally impossible to reset. But I'm not sure how to do that without implementing complete user data encryption.
> It would be great if sites had an option to remove reset support for your account permanently.
That falls apart pretty quick when you attach things like recurring billing to your account. Nobody is perfect and at some point somebody, somewhere is going to want to cancel that billing but not have access to their account and checked your "never reset this account" box.
How do you deal with that very real edge case? Especially since that edge case can easily escalate to a lawsuit depending on the account in question.
That falls apart pretty quick when you attach things like recurring billing to your account. Nobody is perfect and at some point somebody, somewhere is going to want to cancel that billing but not have access to their account and checked your "never reset this account" box.
How do you deal with that very real edge case? Especially since that edge case can easily escalate to a lawsuit depending on the account in question.
You empower support to be convinced over the phone to cancel recurring billing, but not to reset 2FA.
That way in the very worst case if support gets socially engineered into removing the credit card details from the account the customer will get mildly annoyed as they have to login and reset it, but their whole account won't be taken over.
That way in the very worst case if support gets socially engineered into removing the credit card details from the account the customer will get mildly annoyed as they have to login and reset it, but their whole account won't be taken over.
And then eventually the account will delete itself if you can verify billing info as part of removing billing.
If an account that doesn't have this feature turned on is hijacked, the hijacker could turn this on to permanently lock out the owner of the account.
... which has some potential downsides for the customer, but also has some potentially huge privacy upsides as well, yeah?
Will it work in Firefox? Because I've see too many implementations that only work in Chrome. My Yubikey is still collecting dust in the drawer because of this.
You have to turn U2F support on with a hidden config at the moment if you want to use it in Firefox: https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-f...
I believe it’s default on with the latest versions.
Currently works on Chrome, Firefox, Edge. Safari is under development: https://webkit.org/status/#feature-web-authentication
It works in Firefox, I seem to recall it worked out of the box?
IMO a good balance between never resetting 2FA and resetting 2FA with a simple call to tech support: The customer calls in to reset it, you then wait 24 hours, and attempt to contact them through all known contacts for them at the end of 24hrs. If they then approve the reset OR you can't contact them (i.e. lost phone) THEN reset it. Sorry if I wasn't very clear.
> I can do everything right and still get compromised because some underpayed support contractor falls for some social engineering hack.
Security isn't binary, it's a spectrum and requires tradeoffs. 2FA isn't a silver bullet.
Security isn't binary, it's a spectrum and requires tradeoffs. 2FA isn't a silver bullet.
at least you'll be notified about the compromise, as surely everyone that resets the u2f will get notifications through all available channels, right?
Not if those channels require U2F to access them.
But that's only really a concern for your email provider, right? Like, as long as I know that resetting my login on service X will trigger an email, then I'm okay with it.
And if you're the email provider, you probably already have my phone number anyway and could/should send a text message to notify me about anything like this.
And if you're the email provider, you probably already have my phone number anyway and could/should send a text message to notify me about anything like this.
I went through the Google Advanced Protection setup a few weeks ago. My only advice is that if you use Android, download the Smart Lock app before enabling Advanced Protection. If you don’t, you’ll get signed out of your Google account on your phone without a way to log back in (the Play Store won’t work without a linked Google account).
If you make this mistake, you need to then disable Advanced Protection, re-login to your phone, then download the Smart Lock app, and THEN re-enable Advanced Protection to get things working. Otherwise you’ll be locked out of your phone.
If you make this mistake, you need to then disable Advanced Protection, re-login to your phone, then download the Smart Lock app, and THEN re-enable Advanced Protection to get things working. Otherwise you’ll be locked out of your phone.
I've been looking for a new Android phone for a while now, and my primary selection criterion has become NFC because advanced account protection uses U2F over it. It's frustrating when otherwise decent products are unusable due to the lack of a common feature.
I carefully chose a phone supporting NFC as well. But then installed LineageOS and, as it turns out, it now does not pass Google's SafetyNet test and Google Pay refuses to work.
Does the phone need to pass SafetyNet to use a Yubikey over NFC with it?
Does the phone need to pass SafetyNet to use a Yubikey over NFC with it?
it work fine just use magisk to pass safety net and in Hide panel check google pay. i'm using it everyday
New Pixels now have the hardware built-in so you don't need a separate Yubikey anymore.
U2F also works over usb on Android. Not sure it's very usable, but it works.
How will you be able to setup a new phone then? Let's say next year you buy a phone. Will you have to disable advanced protection on you account to add the phone to your account?
Most phones nowadays support NFC so this shouldn't be an issue. Just use your NFC key to log into the phone. Alternatively you can also use a Bluetooth U2F key instead of a NFC key. Both of those keys have a regular USB port in addition to NFC/Bluetooth so you can set them up on your laptop and then use them with your phone.
On my Pixel 2 you can (though not conveniently) plug a typical USB-A Security Key into the USB-C port via an adaptor and of course it just works.
I enrolled a key this way (USB-A key plugged into an adaptor on the USB-C port) once just to see if it works. Bizarrely Google will let you do that, but, having proved that it works, they then immediately tell you that you need to install Desktop Chrome before you can enroll any other keys. No idea why they think that's a good idea let alone necessary.
I enrolled a key this way (USB-A key plugged into an adaptor on the USB-C port) once just to see if it works. Bizarrely Google will let you do that, but, having proved that it works, they then immediately tell you that you need to install Desktop Chrome before you can enroll any other keys. No idea why they think that's a good idea let alone necessary.
Clearly an improvement but let's face it - once you loose/break the keys you will have to go through an extensive verification process (up to 3 days according to google) and there is no guarantee you will pass that stage either. Let's be mindful that more security is at the expense of less accessibility and in some places this is simply not going to cut it.
Note that this is only for a login from a new device. If you have your phone, you can change the settings easily. Same if you have a browser already logged in.
Generally having backup keys is recommended so you don't have this single point of failure.
If you are in a foreign country and your mobile phone was stolen...
How often does that happen? For the average user this is very very unlikely.
The average person worries about plenty of things that are very very unlikely to happen to them, but it still worries them enough to pick an option that is more likely to harm them, but in a less scary way.
Then you pull the printed backup codes out of your wallet.
Your backup key is the second hardware token. You don't have any other backup keys :)
You can have more than two hardware tokens on your account, the lowest limit I've ever seen is 5. If you break 5 keys at once, I think having to go through some verification is warranted.
Sure. That will be the case in extreme circumstances like your tokens for the AWS root account, etc. The average consumer will have only two at best.
But how likely is it that they loose two keys at once, especially since one is basically made to be part of the keychain...
And if your second key is not convenient to access, the typical user will not remember to link it to their account as a backup.
Which is why Google Advanced Protection requires you two register two keys for it to work, not only one.
It’s lovely when this is the case, but not always (though keeping accounts/keys in sync gets messy)
Unfortunately, for an AWS root or IAM account, the limit is still one per https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...
Unfortunately, for an AWS root or IAM account, the limit is still one per https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...
lost my aws 2fa on a free tier account, after 12 months it started charging around $5/month, they wouldn't let me shut down my account without a signed document from a lawyer identifying me (this would have cost me £60 and a load of time/hassle), this went on for months until my credit card expired and they stopped billing me.
That's really the fault of AWS having a bad security policy (U2F standard documents recommends storing multiple keys for this purpose)
Too bad someone has to use only Chrome for U2F access. I wish Firefox was able to handle it in the same.way of Chrome's way.
Not even Chromium can work with it, at least not on Linux.
You can enable u2f in Firefox if you go to about:config and toggle the security.webauth.u2f property. Been using it for a couple of months and it's working great.
I tried that this week, and Google still complains that "you must use Chrome" when I tried to register it. The Yubikey works OK on other pages, also with u2f (e.g. gitlab & github). I read somewhere that one can do the registration on Chrome once and later use Firefox to login. But I don't want to install Chrome even once, that's why I am using Fx in the first place!... :(
Yup, I can confirm that it works fine once enrolled, I use Firefox for work and they require MFA so I enrolled the FIDO token on my keychain, I don't run Chrome.
I don't like how fragile this situation is (not being able to use my preferred systems to enroll) so I did not enroll my non-work accounts, whereas for systems like GitHub where Security Keys just work fine, of course both my work and personal accounts are enrolled.
I don't like how fragile this situation is (not being able to use my preferred systems to enroll) so I did not enroll my non-work accounts, whereas for systems like GitHub where Security Keys just work fine, of course both my work and personal accounts are enrolled.
Yeah, just another instacne of either shitty or evil design by google. What a surprise.
I can confirm that. I've been using Krypton for my second factor because of the added convenience and Firefox has had zero issues. I can't wait for WebAuthn.
Did you register it on Google via Firefox too? (The first time?) For me, Google complains "must use Chrome" even though I have the u2f in about:config enabled, and it works on other sites. I read somewhere it works via Fx for login later, but for 1st registration step, they still seem to require Chrome :(
I think I did? I remember registering for a site in Chrome, though, but I don't remember which one that was. It's terrible that they detect browsers instead of functionality.
I’ve been using it for at least a year and the only problem was way back when Google had a hard-coded user agent check.
WebAuthn is supposed to replace this right? I hope Google will implement this soon
[deleted]
Can someone confirm, what is actual market coverage of U2F/Yubikey? I am reading about it for some time now and it looks to me that only few web pages and/or applications is actually supporting it. If that's only to get secure access to Google or GitHub then it seems an overkill to me. Am I missing something?
https://twofactorauth.org/ has a list of websites which support two-factor authentication, including using hard tokens.
This is a nice site but people need to know that half of listed resources will only work in Chrome and its derivatives. Firefox does support U2F for example but Google, Facebook and others does not support U2F via FF on their resources. This situation is at least 1-2 year old and I suspect will keep like that for a long time.
What about other Chromium-based browsers such as Brave, Vivaldi, Opera?
Google does support U2F on Firefox. Just not for registering the key.
My personal opinion: it's enough and you should recommend it on Google & Facebook, particularly to protect against phishing, and especially to non-tech people.
Security keys are supported on Google and Facebook on (almost) all browser/devices. Almost means you still need to be a bit careful when you buy the key to check exactly the support, but you'll find the right combination that works for you. If you want some extra websites, you also have Twitter, Dropbox, Github, etc.
This said, I personally wouldn't want to enable my security keys on too many websites, because loosing or breaking a key it's a major pain. I much prefer to use oauth and delegate authentication to Google or Facebook, and keep these two highly protected.
Security keys are supported on Google and Facebook on (almost) all browser/devices. Almost means you still need to be a bit careful when you buy the key to check exactly the support, but you'll find the right combination that works for you. If you want some extra websites, you also have Twitter, Dropbox, Github, etc.
This said, I personally wouldn't want to enable my security keys on too many websites, because loosing or breaking a key it's a major pain. I much prefer to use oauth and delegate authentication to Google or Facebook, and keep these two highly protected.
My assessment matches yours, very few online account login systems support U2F. Heck, many don't even support using a TOTP or SMS second factor.
But the real value is for the most critical logins, such as to Google, or similar, where a breach would be tremendously harmful to you.
But the real value is for the most critical logins, such as to Google, or similar, where a breach would be tremendously harmful to you.
It works with password managers like Lastpass.
U2F does not work with LastPass, sadly.
Edit: here https://lastpass.com/support.php?cmd=showfaq&id=8126
U2F works with dashlane I think?
Edit: here https://lastpass.com/support.php?cmd=showfaq&id=8126
U2F works with dashlane I think?
You can use a Yubikey with GPG and even SSH but the Google account is for many people by far the most important online asset, especially for Android users, so is it an overkill to spend a hundred bucks?
I got a yubikey a few weeks ago and enabled U2F wherever I could. You can also get yubico authenticator, which replaces google authenticator, but stores all your TOTP codes on the yubikey instead. I was always afraid of losing my phone with all my TOTP codes on it, since I wasn't very consistent about saving backup codes. Now all my TOTP codes are on two yubikeys and they are only visible if I swipe the key near my phone.
tl;dr: You can use the yubikey to replace google authenticator wherever you're using standard TOTP codes.
tl;dr: You can use the yubikey to replace google authenticator wherever you're using standard TOTP codes.
One can also save the QR codes and or secret keys at enrollment in password managers for future proofing the totp auth codes against phone loss.
Why is SQRL [1] not more popular?
[1] https://www.grc.com/sqrl/sqrl.htm
[1] https://www.grc.com/sqrl/sqrl.htm
Reference source in assembly, sponsor not particularly popular or known in the silicon valley. It's a pity because I think the concept is really smart and practical. I would not run it on a windows machine though.
Not sure about Silicon Valley, but Steve Gibson is well known in the security community. He has been working on this for years now, and has had beta testers for the past year I believe.
SQRL (as a whole deliverable package) is not finished yet though.
SQRL (as a whole deliverable package) is not finished yet though.
It ends up with the same gap as the TOTP approaches. The user is _supposed_ to verify that this is goodguy.example, their bank's site. But they don't. Humans are very, very bad at spotting that a routine course of events didn't happen.
If the human doesn't do this apparently pointless busywork, their security is secretly destroyed. If you ignore the fact that the SQRL says "goodguy.example" but the phishing site you're on says "badguy.example" then you authorise the bad guys to log into your bank account. Oops.
In WebAuthn and U2F this doesn't work because the web browser was brought in to the party. "This" says the browser, "is badguy.example", and the user isn't asked to do any busywork with a risk of getting themselves in trouble. The bad guys get nowhere.
Railway example:
Train drivers do the same routes over, and over, and over. They get used to things that they know intellectually are just patterns, routines, not set down anywhere as facts. Hypothetical example: maybe at Oakwood junction on the Down Fast with the Express you always get a Caution, never Clear or Danger, if you're on time, because the signaller is moving a local out of your way ahead. Without any computer assistance, drivers, despite being trained about this specific problem, will look at a signal showing Danger at Oakwood junction on the Down Fast, and their brain says "No, this is always Caution" and _even though they saw a Danger signal_ and even though they are trained that if they aren't sure they must treat signals as "Danger" - they act as though it was definitely Caution.
With a computer helping, the driver can be "shaken" out of this mistake, for example the computer can sound an audible alarm that the train seems not to be slowing appropriately, and then since this alarm doesn't normally sound, the driver may go "Wait, was that Caution? Actually I think it was Danger! Oops" and brake. But we must be cautious with such aids, most of the British railways have a system that sounds a horn each time you're shown a signal that is NOT Clear. The driver acknowledges the horn, or if they do not the train autonomously brakes to a halt. But both "Caution" and "Danger" are not Clear, at our hypothetical Oakwood junction the driver would get used to hearing the horn, because the signal says "Caution", except today it is "Danger" ...
If the human doesn't do this apparently pointless busywork, their security is secretly destroyed. If you ignore the fact that the SQRL says "goodguy.example" but the phishing site you're on says "badguy.example" then you authorise the bad guys to log into your bank account. Oops.
In WebAuthn and U2F this doesn't work because the web browser was brought in to the party. "This" says the browser, "is badguy.example", and the user isn't asked to do any busywork with a risk of getting themselves in trouble. The bad guys get nowhere.
Railway example:
Train drivers do the same routes over, and over, and over. They get used to things that they know intellectually are just patterns, routines, not set down anywhere as facts. Hypothetical example: maybe at Oakwood junction on the Down Fast with the Express you always get a Caution, never Clear or Danger, if you're on time, because the signaller is moving a local out of your way ahead. Without any computer assistance, drivers, despite being trained about this specific problem, will look at a signal showing Danger at Oakwood junction on the Down Fast, and their brain says "No, this is always Caution" and _even though they saw a Danger signal_ and even though they are trained that if they aren't sure they must treat signals as "Danger" - they act as though it was definitely Caution.
With a computer helping, the driver can be "shaken" out of this mistake, for example the computer can sound an audible alarm that the train seems not to be slowing appropriately, and then since this alarm doesn't normally sound, the driver may go "Wait, was that Caution? Actually I think it was Danger! Oops" and brake. But we must be cautious with such aids, most of the British railways have a system that sounds a horn each time you're shown a signal that is NOT Clear. The driver acknowledges the horn, or if they do not the train autonomously brakes to a halt. But both "Caution" and "Danger" are not Clear, at our hypothetical Oakwood junction the driver would get used to hearing the horn, because the signal says "Caution", except today it is "Danger" ...
I mean SQRL does help with the fact that if you scan the login of a bad site that is portraying as a good guy then you log in with different credentials as the site url is embedded in the QR login image.
If your talking about iframing goodguys website inside of badguy website, then yes this is an issue that goodguy should not allow iframing of their login page.
If your talking about iframing goodguys website inside of badguy website, then yes this is an issue that goodguy should not allow iframing of their login page.
No, the scenario goes like this:
1. You, the victim, go to badguy.example, perhaps as a result of a phishing email, a sponsored link, or it's a typo squatter.
2. badguy.example tells you it's Good Guys. You need to log in (as is usual with Good Guys) so you go to the login screen...
3. When you do this the Bad Guys connect to goodguy.example and ask to log in too, they get a SQRL code for goodguy.example
4. Bad Guys (still pretending to be Good Guys) show you the SQRL code to log in to goodguy.example
5. You scan the SQRL code and press OK
6a. Now the Bad Guys are successfully logged in as you since this was their SQRL code for your account.
6b. You receive some error message or other stalling tactics to buy them some time.
The SQRL user has been taught, over, and over, and over, that they need to check the domain name shown in SQRL. They did, it said goodguy.example, as they expected. Unfortunately that was worthless because what mattered is that they were visiting badguy.example in their web browser.
Gibson is aware _this_ can only be fixed the way U2F/ WebAuthn fixed it, which is to modify the user's web browser, not just add a fun phone app. And once you've done that modification (Firefox, Chrome, Edge in beta, Safari to come) the QR code and phone app plays no useful role. It's a hangover from Gibson's original idea that doesn't quite make any sense once you fix the actual problem.
1. You, the victim, go to badguy.example, perhaps as a result of a phishing email, a sponsored link, or it's a typo squatter.
2. badguy.example tells you it's Good Guys. You need to log in (as is usual with Good Guys) so you go to the login screen...
3. When you do this the Bad Guys connect to goodguy.example and ask to log in too, they get a SQRL code for goodguy.example
4. Bad Guys (still pretending to be Good Guys) show you the SQRL code to log in to goodguy.example
5. You scan the SQRL code and press OK
6a. Now the Bad Guys are successfully logged in as you since this was their SQRL code for your account.
6b. You receive some error message or other stalling tactics to buy them some time.
The SQRL user has been taught, over, and over, and over, that they need to check the domain name shown in SQRL. They did, it said goodguy.example, as they expected. Unfortunately that was worthless because what mattered is that they were visiting badguy.example in their web browser.
Gibson is aware _this_ can only be fixed the way U2F/ WebAuthn fixed it, which is to modify the user's web browser, not just add a fun phone app. And once you've done that modification (Firefox, Chrome, Edge in beta, Safari to come) the QR code and phone app plays no useful role. It's a hangover from Gibson's original idea that doesn't quite make any sense once you fix the actual problem.
I was just reading about this problem here:
https://www.grc.com/sqrl/phishing.htm
Gibson give a pretty honest assessment of the problem and what the weaknesses are under the various configurations. When the login agent is on the same machine as the browser (which would be the normal case), the problem mostly goes away (if I understand it correctly).
https://www.grc.com/sqrl/phishing.htm
Gibson give a pretty honest assessment of the problem and what the weaknesses are under the various configurations. When the login agent is on the same machine as the browser (which would be the normal case), the problem mostly goes away (if I understand it correctly).
SQRL is not finished yet. Steve has said he will do an SN episode on it when its finished, soon(tm).
FIDO U2F has a great anti phishing mechanism by incorporating the hostname.
However:
It's too difficult to setup FIDO U2F for your own webserver. There is still no Apache module or nginx plugin that allows you to protect a directory of your document root.
Also U2F is not available for PHPBB. There is a plugin that appears to be unfinished and buggy since 2015.
However:
It's too difficult to setup FIDO U2F for your own webserver. There is still no Apache module or nginx plugin that allows you to protect a directory of your document root.
Also U2F is not available for PHPBB. There is a plugin that appears to be unfinished and buggy since 2015.
Using an OpenID connect provider with one of Hans Zandbelt's plugins for Apache (mod_auth_openidc) or Nginx (lua-resty-openidc) would give you centralized authentication which could use U2F or any other supported 2FA mechanism.
I can echo this comment. Protecting websites with lua-resty-openidc was very easy and required no changes to the actual application code.
> The value proposition of a U2F device like the YubiKey is that not only must you have it present, it's not subject to the TOTP being disclosed like with tokens that require the user to enter a password into a third-party service which could still be a phishing page
Could someone shed some light on this? What is it that prevents a phising page from basically proxying the crypto challenge from the website to your key and present your answer back?
Could someone shed some light on this? What is it that prevents a phising page from basically proxying the crypto challenge from the website to your key and present your answer back?
U2F is a two step process - you need to register the device first (through challenge-response process called ENROLLMENT), then you can use it by issuing authentication challenge (U2F authentication is NOT the same as user authentication, they labeled the process as ENROLLMENT - AUTH process).
During registration you receive several pieces of info, such as keyHandle, public key you use to verify future device responses and an attestation certificate so you can verify the device vendor.
The interesting part is this: when you challenge the u2f device to sign AUTHENTICATION request, what it does is keep a counter tied to your appId (the domain where the .js that deals with this is executed) and it produces encoded json which is signed by the device, using an EC private key.
The counter increases every time the device is challenged by that particular appId. The response is signed using the counter and a private key that's on the device (which you can't tamper with).
So, the phishing / mitm should have the value of private key and the moving part (counter) that's tied to a specific appId. That's difficult since it SHOULD do this during enrollment process and every subsequent authentication request.
What's important that not only does it protect against phishing but from replays too. Naturally, the u2f device isn't standalone responsible for this, the verifying server implementation is a crucial part of the process.
Disclaimer: I'm not affiliated by Yubico, but have implemented U2F (the dreaded js part and backend part) in 2015, several months after Chrome 38 has been released, the first version supporting u2f protocol.
During registration you receive several pieces of info, such as keyHandle, public key you use to verify future device responses and an attestation certificate so you can verify the device vendor.
The interesting part is this: when you challenge the u2f device to sign AUTHENTICATION request, what it does is keep a counter tied to your appId (the domain where the .js that deals with this is executed) and it produces encoded json which is signed by the device, using an EC private key.
The counter increases every time the device is challenged by that particular appId. The response is signed using the counter and a private key that's on the device (which you can't tamper with).
So, the phishing / mitm should have the value of private key and the moving part (counter) that's tied to a specific appId. That's difficult since it SHOULD do this during enrollment process and every subsequent authentication request.
What's important that not only does it protect against phishing but from replays too. Naturally, the u2f device isn't standalone responsible for this, the verifying server implementation is a crucial part of the process.
Disclaimer: I'm not affiliated by Yubico, but have implemented U2F (the dreaded js part and backend part) in 2015, several months after Chrome 38 has been released, the first version supporting u2f protocol.
Last time I checked (more than a year ago) most of the websites didn't care about the counter value.
(If you use a Ledger device for U2F and subsequently restore a new (or a reset) device from your private seed the counter will be reset. Trezor has the same issue but allows you to manually set the counter to work around it.)
(If you use a Ledger device for U2F and subsequently restore a new (or a reset) device from your private seed the counter will be reset. Trezor has the same issue but allows you to manually set the counter to work around it.)
I haven't got any info on websites caring about the counter value. It seems.. pointless to use U2F if you just disregard the counter value. You need to extract it from the response in order to construct the binary data to verify the signature. If one disregards the counter value, they can just outright drop the whole U2F.
> If one disregards the counter value, they can just outright drop the whole U2F.
It's not pointless. Disregarding the counter only enables replay attacks, that is: the attacker must previously have captured a challenge/response. The phishing resistance is still retained because it relies on the browser passing the origin to the u2f device and the browser can't be fooled by similar URLs while a human entering a TOTO token can.
It's not pointless. Disregarding the counter only enables replay attacks, that is: the attacker must previously have captured a challenge/response. The phishing resistance is still retained because it relies on the browser passing the origin to the u2f device and the browser can't be fooled by similar URLs while a human entering a TOTO token can.
U2F isn't as trivial to implement as RFC4226 OTP. It takes effort. Implementing the counter check is trivial. Disregarding the counter and stating "that only enables replays" is absolutely unacceptable. If one is so irresponsible to the point they're enabling a replay attack - then there's no excuse and no valid argument to support the use of U2F at all. If you (not YOU, personally) can't implement the protocol fully, don't half-ass it and plant mines. That's my take on it, and anyone who implements this protocol to secure people's accounts MUST (not SHOULD) think the same. There is NO excuse for deliberate irresponsibility.
The origin of the page is part of the signed payload. So if another website presented the challenge, the origin part wouldn't match.
That does assume the thing communicating with the security key is not compromised though (the browser/OS).
Not entirely sure about how Google Smart Lock on iOS works in this regard - since it communicates over BLE and could specify any origin, and then the process of going between the app/web on iOS can't be secured particularly well.
Also unclear how origins would work with regards to non-web applications. e.g. URL schemes aren't unique/owned/defendable.
That does assume the thing communicating with the security key is not compromised though (the browser/OS).
Not entirely sure about how Google Smart Lock on iOS works in this regard - since it communicates over BLE and could specify any origin, and then the process of going between the app/web on iOS can't be secured particularly well.
Also unclear how origins would work with regards to non-web applications. e.g. URL schemes aren't unique/owned/defendable.
Essentially it borrows the protections from TLS. Here's a link to the relevant part of the spec: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...
(Sorry if this comes across as RTFM, but I figured the source is better than my attempt at explaining)
(Sorry if this comes across as RTFM, but I figured the source is better than my attempt at explaining)
Not at all, the specification is indeed very clear. Thanks for the link!
Channel ID has been depreciated and replaced by Token Binding but I'm sure U2F sites don't use either. The real protection is quite simple: incorporating the origin (domain name) in the protocol. So phishers would get a bad response from the token.
The hostname of the website you're visiting is cryptographically signed by the security key.
So, if by accident you're on phishing.com, the key will generate a signature containing phishing.com. When the attacker forwards it to google.com, Google won't verify the signature, and thus the attacker won't get access to your account.
So, if by accident you're on phishing.com, the key will generate a signature containing phishing.com. When the attacker forwards it to google.com, Google won't verify the signature, and thus the attacker won't get access to your account.
I wish that SmartCards were used more for this purpose https://github.com/OpenSC/OpenSC/wiki
There's an applet you can load into your own JavaCard presumably https://github.com/LedgerHQ/ledger-u2f-javacard
There's an applet you can load into your own JavaCard presumably https://github.com/LedgerHQ/ledger-u2f-javacard
They died when everybody ditched Java applets for web.
I wish they were more useful and programmable without a Java applet (eg. Custom C/C++ driver)
I wish they were more useful and programmable without a Java applet (eg. Custom C/C++ driver)
Smartcards aren't dead, they are all around us in sim cards and credit cards.
> They died when everybody ditched Java applets for web.
How's that relevant? Are you saying no one uses Java anymore?
> They died when everybody ditched Java applets for web.
How's that relevant? Are you saying no one uses Java anymore?
Many smart cards use an extremely minimal version of java, so I imagine that java applets were able to interact with them more easily.
I'm not saying that writing for Javacards is easy, but that's not the problem here. There is plenty of software written already
https://github.com/EnigmaBridge/javacard-curated-list
It's just didn't catch on, there's no thriving community around it. You have the software, you have the hardware (search for JCOP21 or JCOP3 on Aliexpress), but no users.
https://github.com/EnigmaBridge/javacard-curated-list
It's just didn't catch on, there's no thriving community around it. You have the software, you have the hardware (search for JCOP21 or JCOP3 on Aliexpress), but no users.
The JubiKeys support a smart-card functionality.
There is a similar thing in SIM-cards, but that is under-utilized as well.
There is a similar thing in SIM-cards, but that is under-utilized as well.
You mean YubiKey? I know, but it's hard for me to view YubiKey as anything other than a proprietary solution. It's great they built a business out of it, but at the same time I want open-source options to exist.
Enter Solokeys [0]. They support U2F out of the box, and they say OpenPGP (can be used for SSH) is in the works.
I've yet to receive mine, so I don't know if they work or not..
[0] https://solokeys.com
I've yet to receive mine, so I don't know if they work or not..
[0] https://solokeys.com
> There is a similar thing in SIM-cards
Got any good resources on this subject? I'd be interested to know more :)
Got any good resources on this subject? I'd be interested to know more :)
I'm not entirely sure what he means by that, but SIM-cards are smartcards.
https://en.wikipedia.org/wiki/Subscriber_identity_module#/me...
And you can buy smartcards in this formfactor e.g. https://www.cardomatic.de/epages/64510967.sf/en_GB/?ObjectPa...
https://en.wikipedia.org/wiki/Subscriber_identity_module#/me...
And you can buy smartcards in this formfactor e.g. https://www.cardomatic.de/epages/64510967.sf/en_GB/?ObjectPa...
Look into EAP-SIM and EAP-AKA for some concrete examples.
I believe mobile payment also uses the SIM card, but I'm not sure.
For a more general overview see https://en.wikipedia.org/wiki/Universal_integrated_circuit_c....
There is apparently a toolkit to design applications to run on the SIM https://en.wikipedia.org/wiki/USIM_Application_Toolkit
I don't know of any other implementations. An SSH auth module using SIM would be pretty cool.
I believe mobile payment also uses the SIM card, but I'm not sure.
For a more general overview see https://en.wikipedia.org/wiki/Universal_integrated_circuit_c....
There is apparently a toolkit to design applications to run on the SIM https://en.wikipedia.org/wiki/USIM_Application_Toolkit
I don't know of any other implementations. An SSH auth module using SIM would be pretty cool.
For some reason Google Smart Lock doesn't allow you to use a U2F Yubikey as a backup to the phone-based prompt. Seems totally absurd as a Yubikey is the perfect backup to a lost phone.
Also did I mention that if you use 2FA, Google's "find my phone" functionality asks you to use your phone to authorize the login before you can find it?
Yes. You heard that right. Use your phone to find your phone. Don't ask me how I know.
Also did I mention that if you use 2FA, Google's "find my phone" functionality asks you to use your phone to authorize the login before you can find it?
Yes. You heard that right. Use your phone to find your phone. Don't ask me how I know.
I feel your pain. Did the exact same thing to myself before enrolling two u2f keys. I turned that off after switching to hardware keys and printing out the back up codes.
Well, presumably you are using 2FA because you don't want anyone that stole your password to be able to access your account, so do you really want anybody with access to your password to track your location?
Even though my intuition is that the lousy product manager who made that decision did it because of this reasoning, I would venture that 99.999% of the people prefer to find their phone when they lose it than having this guarantee by default.
If someone has my password and is trying to track me down, all you have to do is let me know that this is happening with a notification on my phone so I can rapidly change my password by using the device I am holding in my hand.
If you are the kind of person where this small time window of physical location disclosure is a significant vulnerability, you shouldn't carry a Google-manufactured phone without putting it in an RF-proof bag anyway.
If someone has my password and is trying to track me down, all you have to do is let me know that this is happening with a notification on my phone so I can rapidly change my password by using the device I am holding in my hand.
If you are the kind of person where this small time window of physical location disclosure is a significant vulnerability, you shouldn't carry a Google-manufactured phone without putting it in an RF-proof bag anyway.
Isn't the that, in the lost phone case, you can never answer that query?
Google prompts you (maybe even requires) to enable at least two distinct ways to get in. Now, of course it's possible you've tied both of those to your phone, but I put it to you that this makes it your fault.
If my other method works, even if it's a huge pain (e.g. maybe my other FIDO key is at home and I've flown to Tokyo) then I do still have options. Maybe not options I _love_ but that's security for you. If you have a massive house fire that both destroys your bank documents and leaves you so badly burned you can hardly talk let alone sign your name, good luck the first time you try to withdraw cash from that bank account.
If you set Advanced Protection both distinct ways have to be FIDO Security Keys, and whilst it's conceivable you could own a phone that functions as _one_ FIDO key (I would expect Apple to do this for example) it doesn't make any sense to have a single phone serving as _both_ your keys, even a non-technical person can hopefully spot that.
If my other method works, even if it's a huge pain (e.g. maybe my other FIDO key is at home and I've flown to Tokyo) then I do still have options. Maybe not options I _love_ but that's security for you. If you have a massive house fire that both destroys your bank documents and leaves you so badly burned you can hardly talk let alone sign your name, good luck the first time you try to withdraw cash from that bank account.
If you set Advanced Protection both distinct ways have to be FIDO Security Keys, and whilst it's conceivable you could own a phone that functions as _one_ FIDO key (I would expect Apple to do this for example) it doesn't make any sense to have a single phone serving as _both_ your keys, even a non-technical person can hopefully spot that.
Regarding the first point, I assume that has to do with the lack of support for NFC based U2F on Apple devices. Bluetooth is still the lowest common denominator.
NFC has nothing to do with this as I am talking about a regular U2F YubiKey that I could use by physically plugging into a computer in the rare scenario where I might lose my phone.
Really hope apple adds u2f (native/safari) support at some point in the nearish future.
I'd like to see another article showing the steps to go through if you lose your keys.
This is my biggest concern about 2FA. On Google I have TOTP 2FA enabled, with my phone number as a backup. But everything goes through my phone - I'm not really worried about some stealing my phone to gain access, but what happens if I break or lose my phone.
A few years ago I was travelling abroad and had my suitcase stolen - which had my laptop (with FDE) and passport inside. Fortunately I had my phone and wallet on me, otherwise I really don't know what I would have done - I probably wouldn't even have remembered the name of the hotel I was staying at that night.
A few years ago I was travelling abroad and had my suitcase stolen - which had my laptop (with FDE) and passport inside. Fortunately I had my phone and wallet on me, otherwise I really don't know what I would have done - I probably wouldn't even have remembered the name of the hotel I was staying at that night.
Google allows you to print a set of codes [1] that can be used to access your account if your device is lost. I printed a set and have them stored in a secure place at home. Some people keep them in their wallet/bag/similar.
[1] https://support.google.com/accounts/answer/1187538
[1] https://support.google.com/accounts/answer/1187538
According to [1]
Advanced Protection uses a stricter implementation than
Google has offered in the past: Only those physical
keys—along with a password—will unlock your account. If
you lose them, you can't use a printed out backup code
(Presumably your [1] reference is this: https://www.wired.com/story/google-advanced-protection-locks... )
Good point, although I think the parent comment was about Google's existing 2FA rather than the new advanced protection setting.
Good point, although I think the parent comment was about Google's existing 2FA rather than the new advanced protection setting.
That's the text making me want a follow-up article.
Yes I have those printed and stored securely, and also my landline set as a backup phone number, but that doesn't really help alleviate my concern of "what happens if I'm abroad and no longer have access to my phone".
I guess keeping the codes with my at all times would work, but doesn't seem like that great an option (paper is easy to lose and easy to destroy). Maybe I should memorize some of them?
I guess keeping the codes with my at all times would work, but doesn't seem like that great an option (paper is easy to lose and easy to destroy). Maybe I should memorize some of them?
When setting up TOTP you can copy the private key (basically the QR code) to a secure storage so you can restore it if your device gets lost or stolen.
However, Google Advanced Protection uses only U2F, not TOTP, so that isn't an option if you're using the advanced protection.
I'm using an alternate OTP app called andOTP that lets you make AES encrypted backups. I save the backup file inside my password manager.
I've been using U2F where possible for about a year, and I have a secondary Yubikey registered everywhere I have the primary registered.
I am going to be switching to a USB-C one soon, though, and it only now occurred to me that I haven't really been keeping a "list" of all the sites where I've got them registered. Right now, not a lot of sites support it so it won't be too tough to find them. But I should probably be keeping a list so I at least can be sure when I've definitely replaced registered the new Yubikey in all places the old one was registered.
That doesn't really address your question as to what happens when you lose your keys, but it's perhaps relevant that there are a few warts around replacing even keys you haven't lost.
I am going to be switching to a USB-C one soon, though, and it only now occurred to me that I haven't really been keeping a "list" of all the sites where I've got them registered. Right now, not a lot of sites support it so it won't be too tough to find them. But I should probably be keeping a list so I at least can be sure when I've definitely replaced registered the new Yubikey in all places the old one was registered.
That doesn't really address your question as to what happens when you lose your keys, but it's perhaps relevant that there are a few warts around replacing even keys you haven't lost.
You register more than one key, and use your backup. If the site lets you in without one of the keys you registered, it's a security theater :)
Google states there is a process to go through if you lose both keys that takes up to 3 days. The question is, how strict is this, and how easy is it to lock yourself out.
You use a less convenient backup authentication.
The specifics depend on the use case, but even if you fall back to something less secure like an email and TOTP, you still come out ahead overall because most authentications are done by U2F.
The specifics depend on the use case, but even if you fall back to something less secure like an email and TOTP, you still come out ahead overall because most authentications are done by U2F.
Yeah. That is the million dollar question.
It continues to be an annoyance that we have this great technology in the form of U2F, but Office365/Azure (where troyhunt.com's MX records currently point by the way) doesn't support it. In fact their UX still strongly pushes you towards SMS if you don't know where to look.
$20 for one in a bundle? Why is it so expensive? I get a 4-core 1.3GHz 1GB RAM SBC I can run desktop and all the crypto in the world on, incl. shipping from China for less than the price of a single U2F knob.
I'd pay $2-3 max per piece. Especially since you need more than a few in order not to cause yourself more trouble than this is worth (to someone who already uses random unique passwords and emails for services).
I'd pay $2-3 max per piece. Especially since you need more than a few in order not to cause yourself more trouble than this is worth (to someone who already uses random unique passwords and emails for services).
The goal is really nonclonable key storage with a minimal CPU and purpose specific firmware, i.e. a sim card. The USB u2fs are about $10 which is pretty reasonable for a newish card with ECC algorithms.
Why is it a goal though? I don't care.
U2F to me is useful for protecting from stolen credentials on the web. These attackers will never have physical access to my u2f device to clone it.
If you fear people getting physical access to your u2f, they can simply use it if they also know the password. No need for cloning. And if they don't know the password, it's still useless. From that attacker's perspective, your security was reduced to password only. Which is still good, if you take care of your passwords.
U2F to me is useful for protecting from stolen credentials on the web. These attackers will never have physical access to my u2f device to clone it.
If you fear people getting physical access to your u2f, they can simply use it if they also know the password. No need for cloning. And if they don't know the password, it's still useless. From that attacker's perspective, your security was reduced to password only. Which is still good, if you take care of your passwords.
[deleted]
Does anyone know if Google allows registering more than 2 keys?
Like what if i want to register 3 or 4 keys for advanced protection?
Like what if i want to register 3 or 4 keys for advanced protection?
Yes google does.
The spec strongly encourages providers to allow multiple keys, and allow you to nickname them.
As far as I know everyone allows as many keys as you like except Vanguard and Amazon AWS (which both also only accept Yubico keys)
The spec strongly encourages providers to allow multiple keys, and allow you to nickname them.
As far as I know everyone allows as many keys as you like except Vanguard and Amazon AWS (which both also only accept Yubico keys)
> Does anyone know if Google allows registering more than 2 keys? Like what if i want to register 3 or 4 keys for advanced protection?
Most sites do. Google and Github both allow multiple U2F keys (note that this means any key can be used to unlock your account, not that all are required).
Of all the large and popular sites that support U2F, the only one that I'm aware of that only allows one key is Twitter.
Most sites do. Google and Github both allow multiple U2F keys (note that this means any key can be used to unlock your account, not that all are required).
Of all the large and popular sites that support U2F, the only one that I'm aware of that only allows one key is Twitter.
Yep, they do. I’ve registered 6 without a problem.
Six seems like a lot. Why do you need so many?
It’s cheap insurance against getting locked out of my Google account forever.
Sure but you're diluting the second factor. The more tokens you have, the easier it is to get one and without you noticing.
There's always a tradeoff between convenience and security, but I'm relatively unworried about someone, say, breaking into my bank compared to someone spoofing my phone number.
Just to be clear: it only requires ONE key to be present. Supporting multiple keys is for BACKUP, not additional layers of security (if you were thinking of distributing two keys, one to each person, to make it required for both parties to be present to auth).
Yes no problem
> Now, hopefully the problem here is already self-evident but let's just be crystal clear anyway: adding a second step to authentication should not be seen as an excuse to weaken the first step. I'm hesitant to call this guy's approach 2FA (if it's true MFA at all), it's more like 1.5FA or something thereabouts. The point is, use the approaches above as additional security controls, not as an excuse to weaken existing ones!
Well, right now I use passwords of the form j6lqPKQKQ1RHv87PES4iy5; it'd be nice if using U2F meant that I could securely switch to something like 'correct horse battery staple' instead …
Well, right now I use passwords of the form j6lqPKQKQ1RHv87PES4iy5; it'd be nice if using U2F meant that I could securely switch to something like 'correct horse battery staple' instead …
Amidst all the potential ways in which even 2FA can be compromised, I am surprised no one is mentioning the biggest benefit of using 2FA- the ephemeral nature of 2nd password. Not only it protects against misuse of stolen credentials, but it also allows to centrally disable the 2nd password should any leak occur. Is this one of the stated goals of 2FA design?
In my view, this makes 2FA an essential security feature, not just a nice improvement over 1FA.
In my view, this makes 2FA an essential security feature, not just a nice improvement over 1FA.
Here's what I'd like to see in a 2FA "something you have" device: You could just leave it in your pocket, and you wouldn't have to interact with it. It would also unlock your computer when you sit down at your desk and lock it when you leave.
You mean like an Apple Watch does with a macOS machine?
An app that would turn an Apple Watch into a U2F 2FA device would be great. It would also need to work as such a device for logins to Google and AWS.
https://krypt.co/ kinda does this (not affiliated)
Well you can use the Authy Apple Watch app for TOTP but I am not aware of anything that works like Microsoft or Google's prompt system.
I wonder if you could do that with your phone via bluetooth? I mean most people have bluetooth capable phones on them and I can already connect to mine by clicking an icon on the computer.
I'd prefer to have a really small device, like something I'd leave on a physical keychain. I don't always take my phone with me when I step away from the desk.
Does anyone know if Smart Lock for iOS works with the new Yubikey 5 NFC, or is it still necessary to use the Feitian Bluetooth device?
Smart Lock on iOS does not support NFC currently. BLE only.
This is complicated(even for developers) and requires additional devices. People hate extra devices. Verdict: fail!
Has anyone seen external reported audits of code & hardware for keys like Yubikey, Google Titan?
I wonder if he'll do an article on webauthn... that seems fairly promising as well!
WebAuthn is the spec that enables U2F tokens in browsers. When he adds the keys to his account in Chrome, and when he logs into Gmail on Chrome, that's all utilizing WebAuthn in the background as a technical detail.
Am I correct in seeing that U2F can't be enabled for G-Suite accounts yet? I can't find the setting in the Admin panel.
No, you can definitely enroll U2F keys in GSuite accounts.
Yup. To the extent I use gsuite, I use it with a yubikey for authentication.
U2F can, but the Advanced Protection program can't currently.
Advanced Protection changes your relationship with the administrators (Google). But for GSuite the administrators are some other member of your organisation, so Google can't make a web page that changes that relationship.
If your company decides that the New York employee named "Steve Smith" and the London employee "Stephen Smith" are the same person, and either should be able to request account password reset for [email protected], both of these chaps are going to have a bad time. Google can _tell_ them this is a terrible idea, but GSuite is a company product, so ultimately it's their terrible idea if that's what they want to do.
The _technical_ features of Advanced Protection seem to be mostly: Use FIDO Security Keys (U2F/ WebAuthn), disable stuff we know is useful but insecure. You can opt into those technical changes for your GSuite, either for everybody or a selected group e.g. "Company Security Nerds" or "Executive Level Employees" or "Everybody except Pamela. Damn it Pamela". But the non-technical feature is hard and probably just not replicable at all.
If your company decides that the New York employee named "Steve Smith" and the London employee "Stephen Smith" are the same person, and either should be able to request account password reset for [email protected], both of these chaps are going to have a bad time. Google can _tell_ them this is a terrible idea, but GSuite is a company product, so ultimately it's their terrible idea if that's what they want to do.
The _technical_ features of Advanced Protection seem to be mostly: Use FIDO Security Keys (U2F/ WebAuthn), disable stuff we know is useful but insecure. You can opt into those technical changes for your GSuite, either for everybody or a selected group e.g. "Company Security Nerds" or "Executive Level Employees" or "Everybody except Pamela. Damn it Pamela". But the non-technical feature is hard and probably just not replicable at all.
Yes essentially the issue is that it's possible to permanently and irrecoverably lose access to your account with the Advanced Protection program enabled. But that clearly wouldn't work when your account admin can just reset things.
So you can have an equivalent set of options configured, but it isn't exactly the same.
So you can have an equivalent set of options configured, but it isn't exactly the same.
from https://landing.google.com/advancedprotection/ :
I’m interested in Advanced Protection for my work account - Can I enroll a G Suite Account in Advanced Protection?
With the help of your Administrator, it’s possible to replicate the features of Advanced Protection on a G Suite account. Take a look at this help center article to get started.
the help center link: https://support.google.com/a/answer/9010419
I’m interested in Advanced Protection for my work account - Can I enroll a G Suite Account in Advanced Protection?
With the help of your Administrator, it’s possible to replicate the features of Advanced Protection on a G Suite account. Take a look at this help center article to get started.
the help center link: https://support.google.com/a/answer/9010419
from https://landing.google.com/advancedprotection/ :
I’m interested in Advanced Protection for my work account - Can I enroll a G Suite Account in Advanced Protection?
With the help of your Administrator, it’s possible to replicate the features of Advanced Protection on a G Suite account. Take a look at this help center article to get started.
the help center link: https://support.google.com/a/answer/9010419
I’m interested in Advanced Protection for my work account - Can I enroll a G Suite Account in Advanced Protection?
With the help of your Administrator, it’s possible to replicate the features of Advanced Protection on a G Suite account. Take a look at this help center article to get started.
the help center link: https://support.google.com/a/answer/9010419
Generally yes, but the admin has the power to either enforce it (for some or all users) or disable it domain wide.
If you were to create a new GSuite domain today, it'd be allowed for all users.
If you were to create a new GSuite domain today, it'd be allowed for all users.
> Password and SMS
I see no mention of SS7 attacks, is that a solved problem?
I see no mention of SS7 attacks, is that a solved problem?
"SIM porting"
How will SIM porting help in such attacks?
It doesn't help: it exemplifies the full scale of the problem which is bigger than ss7. SIM porting attack is social-engineering. You don't even need to "fix" ss7 to port out of some carriers, because humans are in the loop to do it for you because tears on the phone.
IMHO the UX for all this stuff is very confusing to non technical users. People lose their phones, don't print out the codes, or simply don't understand how this works and do silly things like trying to use codes from the wrong account.
Since introducing 2FA , requests of people to reset their 2fa are a very regular thing for our support people. Especially when it concerns paying users, saying no is not really an option. So, resets are a common thing. I've since educated our people to at least not do this blindly but obviously, social engineering is a big problem with all this stuff. If this happens to us, you can bet it is an extremely regular thing for basically everything that has 2fa.
But my biggest worry with this stuff on my own accounts is somebody talking support into resetting 2FA on my accounts. I can do everything right and still get compromised because some underpayed support contractor falls for some social engineering hack.