7 ms·

I would advise against Google Authenticator as a backup as it really defeats the point of a hardware token. Google Authenticator stores the TOTP secret in plai

by lrvick 10y ago

I would advise against Google Authenticator as a backup as it really defeats the point of a hardware token. Google Authenticator stores the TOTP secret in plaintext on your device where the potential exists for it to be stolen. An adversary that exploits your phone can generate TOTP tokens as they like and ignore the fact you have a hardware token. If you are going to use Google Authenticator it is your weakest link and a security token buys you no added security, only ease of use. The typical goal of a security token is to be able to assert: "No one can log into my account without this physical device or an offline backup token from my safe" To acheive this consider a device with built-in TOTP support in addition to U2F. All current Yubikeys fit the bill here as as well as some Nitrokey models. Desktop or Android users can use the either USB or NFC devices but it is worth noting that iOS lacks support for either which means you would need a desktop or Android device to fetch TOTP tokens for an iPhone. You can use the open source "Yubico Authenticator" apps to store your TOTP secrets in your key alongside your U2F secret. Now both methods use the same hardware and your phone/computer only get handed OTP codes from the key if present, but can't generate them itself. Added bonus is now you can now use security token backed login even on the majority of sites/browsers today that lack U2F support. Extra bonus is these keys can be used for ssh without any server changes. Security token all the things :)

kasey_junk 10y ago
If only there were a similar guide to getting gpg agent working with the yubikey stored gpg keys and ssh. I've done it, but for the life of my I couldn't tell you how as it was mostly just trying magic incantations of things until it started working.
- lrvick 10y ago
  Here you go: Simple GPG setup: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/GPG/Simple_Setup.md https://github.com/lrvick/security-token-docs/blob/master/Us... Advanced GPG setup with backups: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/GPG/Advanced_Setup.md https://github.com/lrvick/security-token-docs/blob/master/Us... SSH Setup: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/SSH.md https://github.com/lrvick/security-token-docs/blob/master/Us... I also will be adding an alternate "quick ssh setup" guide via PKCS#11 flows to just store an existing ssh private key. Still I think GPG is the way to go in general given all the other use cases it opens up. Please file issues with anything you want to see! I have a lot of unpublished content I can get polished/up if people care.
  - tptacek 10y ago
    "You should disable any other keys that aren't backed by a security token" ... why? You don't need a security token to physically secure a backup key; just put it on a USB drive and stick it in a safe (or a sock drawer). Security tokens are a nice little bonus for security, and they're a major corrective for the kinds of real-world attacks that screw real people over, like phishing (and dumb passwords). But they're pretty marginal against the kinds of attackers who will target SSH keys. Don't get fetishistic about them; at bottom, for serious systems security, they're mostly cosmetic. It feels good to say that all your SSH keys are held in secure devices, but it doesn't mean much.
    - lrvick 10y ago
      It means a lot because I have to physically touch the device every single time I ssh. I can even do agent fowarding taboos and know an attacker can't go creating new connections on that agent without a physical action from me each and every time. Compare this to how ssh keys are normally used. You use it once, type in a keyloggable passphrase, and the key is unpacked plaintext into system memory for, in most cases, the rest of the time the system is booted. You could invalidate the passphrase after every connection but this puts an unreasonable amount of work on the developer. Simply tapping once for each connection and having no way for an attacker to avoid that is a great middle ground, imo. Particularly for high level production keys.
      - tptacek 10y ago
        You're making a comparison to an example I didn't cite. I'm not saying that you should have software-only SSH keys on your computer alongside your Y4 SSH pubkey.
        lrvick 10y ago
        I was mostly responding to: "But they're pretty marginal against the kinds of attackers who will target SSH keys." I am arguing it is not all that marginal. If the only non 0-day way into production is via ssh to a bastion host with a touch-based hardware token then their lives are more than marginally harder than an on-disk key.
brightball 10y ago
Are there any safe software alternatives to Google Authenticator? Duo? LastPass?
- lrvick 10y ago
  Yubico Authenticator and cryptostick.oauth are the only open solutions I am aware of that one can easily verify don't ever expose your secret key. Both of course assume you have the secret key on a Yubikey, Nitrokey or similar. Any app-only TOTP solution has to expose your private key somewhere by design and thus are best avoided in favor of hardware-backed solutions when possible.
- ptha 10y ago
  I use Authy: https://www.authy.com/ https://www.authy.com/ Now I'm wondering are there similar security concerns here as with Google Authenticator?
  - tptacek 10y ago
    Yes. But those concerns don't really matter. Just use whatever TOTP application you're most comfortable with, and, because even experts can be phished, try to use the security key as much as you can.
    - lrvick 10y ago
      You can only use U2F for what, github and google? I am a big fan, but the 30 other services I need to access to do my job use TOTP. We need all the help we can get on that until TOTP is finally phased out.
  - lrvick 10y ago
    Authy has the same core issues because the problem is they have to store the secret key in plain text somewhere for TOTP to work. Worse: it is closed source and does not allow itself to be easily audited so we don't even get to know for sure where the key is stored and how beyond what the docs promise. Security is hard enough when everything is open source. Closing foundational security tools so only a select few biased individuals can deem them secure on a deadline is never a good plan.
rubatuga 10y ago
Do you have a citation for the fact that google authenticator stores the keys in plain text? Furthermore, for the case of google authenticator on an iPhone, any files on the user partition are encrypted anyway, and I know from experience that the google authenticator app does not back up keys to either iCloud or iTunes backup. This should mean you are safe on iOS
- j_s 10y ago
  tokenizerrr | https://news.ycombinator.com/item?id=14105616 https://news.ycombinator.com/item?id=14105616 Even without root. Just run a backup and extract it from that. You can do it with just adb or helium. -- I can't quickly find any examples online that don't specifically mention requiring rooting the phone. Just this anecdote: https://community.spiceworks.com/topic/465582-google-authenticator-move-to-another-device?page=1#entry-3147863 https://community.spiceworks.com/topic/465582-google-authent... If you do a backup (even if not rooted you can use ADB to backup your apps and data,) then you can simply restore the app and data to your new phone and the codes for the device come with it. This article appears to contain the most detailed instructions, stating that both Titanium backaup and manual extraction require root: https://www.howtogeek.com/130755/how-to-move-your-google-authenticator-credentials-to-a-new-android-phone-or-tablet/ https://www.howtogeek.com/130755/how-to-move-your-google-aut... If your Android is rooted, you can use Titanium Backup, which we’ve written about before, to take a backup of your Google Authenticator app data. [...] If you have root access to your device, you can actually extract the credentials manually It was at one point possible to extract from iPhone backups: https://dpron.com/recovering-google-authenticator-keys-from-ios-backups/ https://dpron.com/recovering-google-authenticator-keys-from-...
  - discreditable 10y ago
    ADB backups won't export the secrets from Google Authenticator. The app is configured to disallow that. Source: I've tried.
  - lrvick 10y ago
    Well the scenario we are wanting to defend against is an attacker that can remotely (or even locally) exploit/root the phone (see long list of vulns for ios and android that have allowed exactly this). How many of these still exist not yet patched? Depending on who you work for, someone might just burn a 0-day on you. It all depends on your threat profile. Putting the secret in a hardware token gives you easy to reason about assurances a mobile phone OS vendor can't ever offer. Also this means when you get a new phone, you just install app and tap key. No setup required. Easier for you, and far more secure. Win/win.
tptacek 10y ago
The attacker who gets access to the filesystem of your phone can almost certainly defeat any "encryption" a TOTP authenticator would use to protect secrets, so the premise of phone-based authenticators is that your phone isn't going to get compromised. This is reasonable when you consider that if your computer --- the least secure device you own --- is compromised, your attacker is virtually certain to get your email account with it, because you'll have (at some near point) a logged-in session. Meanwhile: the #1 concern that laypeople have about security tokens is that they'll be locked out of their account when they lose the token. Authenticator (or Duo) is a perfectly sane answer to that concern. Finally, it's worth adding that at least the last time I helped someone set this up, you can't remove your phone number as a factor from your Google account until you have TOTP set up. Your phone number is an extremely insecure login factor. We use, and recommend, Google Authenticator as a backup login factor. We do not recommend Yubikey 4 keys for normal users. Nerds on HN might get a kick out of them; I say, go ahead and enjoy yourself. We're trying to solve problems for people who aren't computer experts.
- lrvick 10y ago
  Yubico Authenticator is a fork of Google Authenticator and is a drop-in replacement. I have never had any problem helping someone that has used google authenticator set this up. Scan barcode and tap. Also users have a much easier time when they get a new phone. Just tap to new phone and get codes. There is no data to transfer. As for people getting locked out, that is what the printable backup codes are for, or a secondary key, depending on your threat profile. In a corporate setting this is a non-issue as an admin can bail you out.
  - tptacek 10y ago
    That's a desktop TOTP application. Now not only do they have to have their computer with them to log into their Google account from their phone, but they have to have 2 security keys on the account to remove their phone number from it, and all their backups are physically separated from them, so unless they bring their backup codes with them when they travel, if they lose their key, they're boned. And all this for what real additional security? If you want to nerd out and get your security key to do pet tricks like handling your TOTP secrets, I do not have a problem with that. But please don't tell ordinary users they're wrong when they don't do that.
sametmax 10y ago
It's not as good as having a hardware key, but they still need your username and password and pwn your phone. That's a lot of trouble. So for most people, TOTP software is good enough security.
- lrvick 10y ago
  I agree mobile app 2FA it is probably good enough for most people. This article however is about using a hardware token for login. If you have a need for hardware tokens, use them end to end. Using a hardware token and having a less secure backup method means you are only as secure as that less secure backup method.
  - tptacek 10y ago
    That simply isn't true, because the hardware token defends against phishing attacks --- in fact, that is the entire reason why U2F tokens exist in the first place. It's literally the motivating use case for the standard: experts with code generators were still getting phished. So, when you have the token handy, you use it, and you're not exposed to phishing. When you don't, you use the mobile app, and you're exposed to phishing (but not to weak passwords and breaches in sites). It's not complicated, unless you think the token does more than it really does for your overall security.
    - lrvick 10y ago
      I will grant you the phishing use case, and that one is relevant to average users. I admit I mostly work with infra folks that would not easily be phished, but might have one of their devices compromised unknowingly rendering phishing moot. TOTP is a mess in regard to phishing but if we have tools to avoid some of the problems while we are stuck with it, I feel they are worth mentioning. Particularly for people savvy enough to purchase hardware tokens for personal use.
      - tptacek 10y ago
        U2F happened because Google developers were being phished. We are all phishable, probably especially those among us who believe we're not.

by lrvick 10y ago

kasey_junk 10y ago

If only there were a similar guide to getting gpg agent working with the yubikey stored gpg keys and ssh. I've done it, but for the life of my I couldn't tell you how as it was mostly just trying magic incantations of things until it started working.

lrvick 10y ago
Here you go: Simple GPG setup: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/GPG/Simple_Setup.md https://github.com/lrvick/security-token-docs/blob/master/Us... Advanced GPG setup with backups: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/GPG/Advanced_Setup.md https://github.com/lrvick/security-token-docs/blob/master/Us... SSH Setup: https://github.com/lrvick/security-token-docs/blob/master/Use_Cases/SSH.md https://github.com/lrvick/security-token-docs/blob/master/Us... I also will be adding an alternate "quick ssh setup" guide via PKCS#11 flows to just store an existing ssh private key. Still I think GPG is the way to go in general given all the other use cases it opens up. Please file issues with anything you want to see! I have a lot of unpublished content I can get polished/up if people care.
- tptacek 10y ago
  "You should disable any other keys that aren't backed by a security token" ... why? You don't need a security token to physically secure a backup key; just put it on a USB drive and stick it in a safe (or a sock drawer). Security tokens are a nice little bonus for security, and they're a major corrective for the kinds of real-world attacks that screw real people over, like phishing (and dumb passwords). But they're pretty marginal against the kinds of attackers who will target SSH keys. Don't get fetishistic about them; at bottom, for serious systems security, they're mostly cosmetic. It feels good to say that all your SSH keys are held in secure devices, but it doesn't mean much.
  - lrvick 10y ago
    It means a lot because I have to physically touch the device every single time I ssh. I can even do agent fowarding taboos and know an attacker can't go creating new connections on that agent without a physical action from me each and every time. Compare this to how ssh keys are normally used. You use it once, type in a keyloggable passphrase, and the key is unpacked plaintext into system memory for, in most cases, the rest of the time the system is booted. You could invalidate the passphrase after every connection but this puts an unreasonable amount of work on the developer. Simply tapping once for each connection and having no way for an attacker to avoid that is a great middle ground, imo. Particularly for high level production keys.
    - tptacek 10y ago
      You're making a comparison to an example I didn't cite. I'm not saying that you should have software-only SSH keys on your computer alongside your Y4 SSH pubkey.
      - lrvick 10y ago
        I was mostly responding to: "But they're pretty marginal against the kinds of attackers who will target SSH keys." I am arguing it is not all that marginal. If the only non 0-day way into production is via ssh to a bastion host with a touch-based hardware token then their lives are more than marginally harder than an on-disk key.

brightball 10y ago

Are there any safe software alternatives to Google Authenticator? Duo? LastPass?

lrvick 10y ago
Yubico Authenticator and cryptostick.oauth are the only open solutions I am aware of that one can easily verify don't ever expose your secret key. Both of course assume you have the secret key on a Yubikey, Nitrokey or similar. Any app-only TOTP solution has to expose your private key somewhere by design and thus are best avoided in favor of hardware-backed solutions when possible.
ptha 10y ago
I use Authy: https://www.authy.com/ https://www.authy.com/ Now I'm wondering are there similar security concerns here as with Google Authenticator?
- tptacek 10y ago
  Yes. But those concerns don't really matter. Just use whatever TOTP application you're most comfortable with, and, because even experts can be phished, try to use the security key as much as you can.
  - lrvick 10y ago
    You can only use U2F for what, github and google? I am a big fan, but the 30 other services I need to access to do my job use TOTP. We need all the help we can get on that until TOTP is finally phased out.
- lrvick 10y ago
  Authy has the same core issues because the problem is they have to store the secret key in plain text somewhere for TOTP to work. Worse: it is closed source and does not allow itself to be easily audited so we don't even get to know for sure where the key is stored and how beyond what the docs promise. Security is hard enough when everything is open source. Closing foundational security tools so only a select few biased individuals can deem them secure on a deadline is never a good plan.

rubatuga 10y ago

Do you have a citation for the fact that google authenticator stores the keys in plain text? Furthermore, for the case of google authenticator on an iPhone, any files on the user partition are encrypted anyway, and I know from experience that the google authenticator app does not back up keys to either iCloud or iTunes backup. This should mean you are safe on iOS

j_s 10y ago
tokenizerrr | https://news.ycombinator.com/item?id=14105616 https://news.ycombinator.com/item?id=14105616 Even without root. Just run a backup and extract it from that. You can do it with just adb or helium. -- I can't quickly find any examples online that don't specifically mention requiring rooting the phone. Just this anecdote: https://community.spiceworks.com/topic/465582-google-authenticator-move-to-another-device?page=1#entry-3147863 https://community.spiceworks.com/topic/465582-google-authent... If you do a backup (even if not rooted you can use ADB to backup your apps and data,) then you can simply restore the app and data to your new phone and the codes for the device come with it. This article appears to contain the most detailed instructions, stating that both Titanium backaup and manual extraction require root: https://www.howtogeek.com/130755/how-to-move-your-google-authenticator-credentials-to-a-new-android-phone-or-tablet/ https://www.howtogeek.com/130755/how-to-move-your-google-aut... If your Android is rooted, you can use Titanium Backup, which we’ve written about before, to take a backup of your Google Authenticator app data. [...] If you have root access to your device, you can actually extract the credentials manually It was at one point possible to extract from iPhone backups: https://dpron.com/recovering-google-authenticator-keys-from-ios-backups/ https://dpron.com/recovering-google-authenticator-keys-from-...
- discreditable 10y ago
  ADB backups won't export the secrets from Google Authenticator. The app is configured to disallow that. Source: I've tried.
- lrvick 10y ago
  Well the scenario we are wanting to defend against is an attacker that can remotely (or even locally) exploit/root the phone (see long list of vulns for ios and android that have allowed exactly this). How many of these still exist not yet patched? Depending on who you work for, someone might just burn a 0-day on you. It all depends on your threat profile. Putting the secret in a hardware token gives you easy to reason about assurances a mobile phone OS vendor can't ever offer. Also this means when you get a new phone, you just install app and tap key. No setup required. Easier for you, and far more secure. Win/win.

tptacek 10y ago

The attacker who gets access to the filesystem of your phone can almost certainly defeat any "encryption" a TOTP authenticator would use to protect secrets, so the premise of phone-based authenticators is that your phone isn't going to get compromised. This is reasonable when you consider that if your computer --- the least secure device you own --- is compromised, your attacker is virtually certain to get your email account with it, because you'll have (at some near point) a logged-in session. Meanwhile: the #1 concern that laypeople have about security tokens is that they'll be locked out of their account when they lose the token. Authenticator (or Duo) is a perfectly sane answer to that concern. Finally, it's worth adding that at least the last time I helped someone set this up, you can't remove your phone number as a factor from your Google account until you have TOTP set up. Your phone number is an extremely insecure login factor. We use, and recommend, Google Authenticator as a backup login factor. We do not recommend Yubikey 4 keys for normal users. Nerds on HN might get a kick out of them; I say, go ahead and enjoy yourself. We're trying to solve problems for people who aren't computer experts.

lrvick 10y ago
Yubico Authenticator is a fork of Google Authenticator and is a drop-in replacement. I have never had any problem helping someone that has used google authenticator set this up. Scan barcode and tap. Also users have a much easier time when they get a new phone. Just tap to new phone and get codes. There is no data to transfer. As for people getting locked out, that is what the printable backup codes are for, or a secondary key, depending on your threat profile. In a corporate setting this is a non-issue as an admin can bail you out.
- tptacek 10y ago
  That's a desktop TOTP application. Now not only do they have to have their computer with them to log into their Google account from their phone, but they have to have 2 security keys on the account to remove their phone number from it, and all their backups are physically separated from them, so unless they bring their backup codes with them when they travel, if they lose their key, they're boned. And all this for what real additional security? If you want to nerd out and get your security key to do pet tricks like handling your TOTP secrets, I do not have a problem with that. But please don't tell ordinary users they're wrong when they don't do that.

sametmax 10y ago

It's not as good as having a hardware key, but they still need your username and password and pwn your phone. That's a lot of trouble. So for most people, TOTP software is good enough security.

lrvick 10y ago
I agree mobile app 2FA it is probably good enough for most people. This article however is about using a hardware token for login. If you have a need for hardware tokens, use them end to end. Using a hardware token and having a less secure backup method means you are only as secure as that less secure backup method.
- tptacek 10y ago
  That simply isn't true, because the hardware token defends against phishing attacks --- in fact, that is the entire reason why U2F tokens exist in the first place. It's literally the motivating use case for the standard: experts with code generators were still getting phished. So, when you have the token handy, you use it, and you're not exposed to phishing. When you don't, you use the mobile app, and you're exposed to phishing (but not to weak passwords and breaches in sites). It's not complicated, unless you think the token does more than it really does for your overall security.
  - lrvick 10y ago
    I will grant you the phishing use case, and that one is relevant to average users. I admit I mostly work with infra folks that would not easily be phished, but might have one of their devices compromised unknowingly rendering phishing moot. TOTP is a mess in regard to phishing but if we have tools to avoid some of the problems while we are stuck with it, I feel they are worth mentioning. Particularly for people savvy enough to purchase hardware tokens for personal use.
    - tptacek 10y ago
      U2F happened because Google developers were being phished. We are all phishable, probably especially those among us who believe we're not.