7 ms·

Google's implementation does not seem to be doing much good anyway. To be fair, it is not just Google -- most companies feel the same pressure of having to impl

Google's implementation does not seem to be doing much good anyway. To be fair, it is not just Google -- most companies feel the same pressure of having to implement MFA but then also make it convenient for clueless users to recover their access. The right way to implement hardware keys is to allow registering multiple of them (so that you can put at least one or two off-site -- in a secure storage) and then not let you recover the access under any circumstances without showing you still own at least one of those keys. If you can recover access without the keys then what is the point of keys in the first place?

carbocation 4y ago
> The right way to implement hardware keys is to allow registering multiple of them Google allows this.
- twawaaay 4y ago
  You missed the second part.
  - carbocation 4y ago
    I see, so you're saying that it's good that Google does the first part, but needs to add the second part. Awareness that Google does the first part wasn't clear from the comment.
    - twawaaay 4y ago
      Any security mechanism is pretty much worthless if it can be trivially circumvented. So yes, the second part is pretty important Actually both parts are important, either is worth little without the other. Having well implemented hardware key is useless if you can't configure more than one -- too much risk having a single piece of hardware that if it fails or you loose it will lock you irrevocably from the account.
    - joshuamorton 4y ago
      It's also possible to do this via advanced protection, it just makes account recovery ~impossible, so you have to explicitly opt in.
roxgib 4y ago
This annoys me a lot - I do sympathise with the fact that these services are regularly bombarded with users unable to log in, but modern authentication tools have existed for a while now and it's time everyone learned to use them. A lot of services insist on including your phone number as a backup authentication method, making you vulnerable to simjacking, or your email address for the same purpose (basically offloading the authentication problem to someone else). That's if you can't bypass it altogether. For services that allow it I have both a TOTP app on my phone and a YubiKey registered, which I figure is sufficient redundancy. Other people could have an old phone registered as well if they don't want to buy a security key. It's a very minor hassle to set up and I can't see why people can't do it.
- Brian_K_White 4y ago
  You can duplicate the totp too. Either save the initial seed generated by the site(s), or depending on the app it may provide a way to export the seeds. You don't go through the setup process on the sites again. The sites have no knowledge that you have 1 or 21 new totp apps set up. You just enter the saved seed keys into the app and it starts spitting out the same correct codes as the other apps you already had setup. Gnome authenticator can export a json file containing the keys to all the sites you have in it. You can then take those (just manually read them in a text editor), and enter them into Google Authenticator on a phone, and now you have 2 working authenticator apps, both spitting out the same correct codes every 30 seconds. Further, you take that same json and paste it into a note in a keepass record, or save the individual seed keys in individual site entries just like the passwords, and copy that keepass db file all over the place including cloud drives, and including places you can access without the totp. Now you can reproduce a working authenticator from scratch on any device at any time no matter where you are and no matter what happens to your phone or laptop. Buy a brand new phone or laptop, have a way to get a copy of your keepass db without needing the totp app, and in a couple minutes you have a working totp app again. You never really have to even use the single-use emergency bypass codes. Keeping copies of the initial setup seeds is really no different from keeping copies of the emergency codes, but the setup seeds reproduce a fully working app not just a one-time access to a site. And even if some app doesn't provide an export like gnome authenticator, you can also just record the key the first time it is generated instead of just scanning the qr code. Once you've saved it, you can use it as many times as you want.
tbrownaw 4y ago
Really, there needs to be some way to add a secondary key that's in secure storage without removing it from secure storage.
- twawaaay 4y ago
  In realm of real hardware security modules this is actually simple, at least in theory. (I worked as a security officer for credit card payment company and we had real HSM boxes worth small fortune each). What you do is you initialise the hardware device with same cryptographic material. You can make as many clones as you want, securely. In practice it is a huge headache but it is due to amount of procedures and paperwork you need to do. Now, I am not an expert on Yubikeys and the protocols used by these tokens, but I know they have protection against reply attacks meaning they keep the sequence number that is incremented for each challenge/response. Pretty sure it could be made to support multiple keys. It would be really nice if I was able to initialise multiple yubikeys and use them interchange-ably (and keep two in safe deposit box just in case).

carbocation 4y ago

> The right way to implement hardware keys is to allow registering multiple of them Google allows this.

twawaaay 4y ago
You missed the second part.
- carbocation 4y ago
  I see, so you're saying that it's good that Google does the first part, but needs to add the second part. Awareness that Google does the first part wasn't clear from the comment.
  - twawaaay 4y ago
    Any security mechanism is pretty much worthless if it can be trivially circumvented. So yes, the second part is pretty important Actually both parts are important, either is worth little without the other. Having well implemented hardware key is useless if you can't configure more than one -- too much risk having a single piece of hardware that if it fails or you loose it will lock you irrevocably from the account.
  - joshuamorton 4y ago
    It's also possible to do this via advanced protection, it just makes account recovery ~impossible, so you have to explicitly opt in.

roxgib 4y ago

This annoys me a lot - I do sympathise with the fact that these services are regularly bombarded with users unable to log in, but modern authentication tools have existed for a while now and it's time everyone learned to use them. A lot of services insist on including your phone number as a backup authentication method, making you vulnerable to simjacking, or your email address for the same purpose (basically offloading the authentication problem to someone else). That's if you can't bypass it altogether. For services that allow it I have both a TOTP app on my phone and a YubiKey registered, which I figure is sufficient redundancy. Other people could have an old phone registered as well if they don't want to buy a security key. It's a very minor hassle to set up and I can't see why people can't do it.

Brian_K_White 4y ago
You can duplicate the totp too. Either save the initial seed generated by the site(s), or depending on the app it may provide a way to export the seeds. You don't go through the setup process on the sites again. The sites have no knowledge that you have 1 or 21 new totp apps set up. You just enter the saved seed keys into the app and it starts spitting out the same correct codes as the other apps you already had setup. Gnome authenticator can export a json file containing the keys to all the sites you have in it. You can then take those (just manually read them in a text editor), and enter them into Google Authenticator on a phone, and now you have 2 working authenticator apps, both spitting out the same correct codes every 30 seconds. Further, you take that same json and paste it into a note in a keepass record, or save the individual seed keys in individual site entries just like the passwords, and copy that keepass db file all over the place including cloud drives, and including places you can access without the totp. Now you can reproduce a working authenticator from scratch on any device at any time no matter where you are and no matter what happens to your phone or laptop. Buy a brand new phone or laptop, have a way to get a copy of your keepass db without needing the totp app, and in a couple minutes you have a working totp app again. You never really have to even use the single-use emergency bypass codes. Keeping copies of the initial setup seeds is really no different from keeping copies of the emergency codes, but the setup seeds reproduce a fully working app not just a one-time access to a site. And even if some app doesn't provide an export like gnome authenticator, you can also just record the key the first time it is generated instead of just scanning the qr code. Once you've saved it, you can use it as many times as you want.

tbrownaw 4y ago

Really, there needs to be some way to add a secondary key that's in secure storage without removing it from secure storage.

twawaaay 4y ago
In realm of real hardware security modules this is actually simple, at least in theory. (I worked as a security officer for credit card payment company and we had real HSM boxes worth small fortune each). What you do is you initialise the hardware device with same cryptographic material. You can make as many clones as you want, securely. In practice it is a huge headache but it is due to amount of procedures and paperwork you need to do. Now, I am not an expert on Yubikeys and the protocols used by these tokens, but I know they have protection against reply attacks meaning they keep the sequence number that is incremented for each challenge/response. Pretty sure it could be made to support multiple keys. It would be really nice if I was able to initialise multiple yubikeys and use them interchange-ably (and keep two in safe deposit box just in case).