4 ms·

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

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
    No, that's a scenario you want to defend against, and I'll remind you again that if you're dealing with attackers that can exploit your computing devices directly, the tokens are pretty much cosmetic. If you have an insecure phone and you actually use it like a smartphone, you're boned no matter how many security tokens you've got attached to your key ring. When we work with lawyers, reporters, and NGOs, what we find are people with much more urgent security problems. They're one carefully worded email away from giving their entire email account away to a 25 year old in Estonia. They aren't worried that their phone is about to get owned up --- mostly because that isn't going to happen, but for other reasons too. Real targets are going to be compromised for 3 reasons: 1. They're going to be phished out of losing their credentials. 2. They're going to share credentials between sites and lose them in a breach of one of those sites. 3. They're going to click on an attachment and lose their whole computer to an attacker. The U2F/TOTP stack this post recommends nicely addresses (1) and (2), and nothing anyone on this thread is talking about addresses (3). I'm not sure why we're spending so much time considering (13).
    - kasey_junk 10y ago
      I think the other part of this is that for these people (and probably most people) losing access to your gmail account is a catastrophic event. That access can be lost because of an attack or by losing the keys. The former is actually much less likely than the latter so mitigating in favor of it instead doesn't make sense in this threat model.
lrvick 10y ago
Any device that generates TOTP tokens needs the secret key available by design. Your could read the source code or spec sheets but an easy way to prove this by backing up Google Authenticator via Titanium Backup and restoring it to a new device. Now both devices generate the same codes. There have been plenty of iOS exploits as well as Android and everything else. Phones have a lot of attack surface and are not a reasonable place to store 2FA of any kind, IMO. The separate hardware TOTP device never exposes the private key to system memory or disk at all. Even if your phone was rooted by a remote attacker, they could not generate tokens. Likewise even if someone physically stole your unlocked phone and your pin-protected key... you are still in pretty good shape. With a hardware TOTP device is just a "viewer" for one code at a time, as generated by the token.
- tptacek 10y ago
  For virtually all users, their iPhone is in fact the most secure computing device they own. It's meaningfully more secure than a computer running a desktop operating system. If we're talking about protecting applications running on a desktop OS, the idea of keeping things off the phone because "phones have exploits" is pretty silly; in that threat model, the desktop is also owned up, and with it the email account --- it's now secured solely by a cookie in your Chrome cookie store on your compromised desktop! The threat modeling here just doesn't make sense.
  - lrvick 10y ago
    Yes the desktop is just as bad as the phone. This is why I don't alow any of those devices have secrets that could be used without me being physically present to access data of users I am responsible for, or my own. You are coming at this from a threat profile of joe individual user. Okay, point taken. I am talking about the perspective of trying to take every reasonable step to reamin secure while being targeted by skilled adversaries who have a lot to gain if they succeed. It is not that much extra work to reduce attack surface so much further than TOTP-generator-on-a-phone offers, so why not teach anyone best practices that will listen? Say I have 30+ TOTP secrets in my mobile phone app, and also my password manager. Everyting from Gmail to my AWS root account. If the TOTP secrets are on my phone and an attacker compromises my phone... they get -everything-. If I am using a hardware token for TOTP and I quickly expire the sessions of all really important things I don't log into often, like AWS... then an attacker only gets a slice of the farm instead of the whole thing. What this buys is us is damage control and a much clearer picture of what an attacker could of accessed, and what they probably could not of because no cookies or secrets were available to memory or disk at that time. I can assert -maybe- this one token was phished, but that none of the others were at risk. If the attacker is on a phone with Google Authenticator, they an just generate all the codes they want for every service. We lose the whole farm.
discreditable 10y ago
If you are rooted, you can easily copy the sqlite database that secrets are stored in. I've done this a few times to migrate secrets to a new phone.

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
  No, that's a scenario you want to defend against, and I'll remind you again that if you're dealing with attackers that can exploit your computing devices directly, the tokens are pretty much cosmetic. If you have an insecure phone and you actually use it like a smartphone, you're boned no matter how many security tokens you've got attached to your key ring. When we work with lawyers, reporters, and NGOs, what we find are people with much more urgent security problems. They're one carefully worded email away from giving their entire email account away to a 25 year old in Estonia. They aren't worried that their phone is about to get owned up --- mostly because that isn't going to happen, but for other reasons too. Real targets are going to be compromised for 3 reasons: 1. They're going to be phished out of losing their credentials. 2. They're going to share credentials between sites and lose them in a breach of one of those sites. 3. They're going to click on an attachment and lose their whole computer to an attacker. The U2F/TOTP stack this post recommends nicely addresses (1) and (2), and nothing anyone on this thread is talking about addresses (3). I'm not sure why we're spending so much time considering (13).
  - kasey_junk 10y ago
    I think the other part of this is that for these people (and probably most people) losing access to your gmail account is a catastrophic event. That access can be lost because of an attack or by losing the keys. The former is actually much less likely than the latter so mitigating in favor of it instead doesn't make sense in this threat model.

lrvick 10y ago

Any device that generates TOTP tokens needs the secret key available by design. Your could read the source code or spec sheets but an easy way to prove this by backing up Google Authenticator via Titanium Backup and restoring it to a new device. Now both devices generate the same codes. There have been plenty of iOS exploits as well as Android and everything else. Phones have a lot of attack surface and are not a reasonable place to store 2FA of any kind, IMO. The separate hardware TOTP device never exposes the private key to system memory or disk at all. Even if your phone was rooted by a remote attacker, they could not generate tokens. Likewise even if someone physically stole your unlocked phone and your pin-protected key... you are still in pretty good shape. With a hardware TOTP device is just a "viewer" for one code at a time, as generated by the token.

tptacek 10y ago
For virtually all users, their iPhone is in fact the most secure computing device they own. It's meaningfully more secure than a computer running a desktop operating system. If we're talking about protecting applications running on a desktop OS, the idea of keeping things off the phone because "phones have exploits" is pretty silly; in that threat model, the desktop is also owned up, and with it the email account --- it's now secured solely by a cookie in your Chrome cookie store on your compromised desktop! The threat modeling here just doesn't make sense.
- lrvick 10y ago
  Yes the desktop is just as bad as the phone. This is why I don't alow any of those devices have secrets that could be used without me being physically present to access data of users I am responsible for, or my own. You are coming at this from a threat profile of joe individual user. Okay, point taken. I am talking about the perspective of trying to take every reasonable step to reamin secure while being targeted by skilled adversaries who have a lot to gain if they succeed. It is not that much extra work to reduce attack surface so much further than TOTP-generator-on-a-phone offers, so why not teach anyone best practices that will listen? Say I have 30+ TOTP secrets in my mobile phone app, and also my password manager. Everyting from Gmail to my AWS root account. If the TOTP secrets are on my phone and an attacker compromises my phone... they get -everything-. If I am using a hardware token for TOTP and I quickly expire the sessions of all really important things I don't log into often, like AWS... then an attacker only gets a slice of the farm instead of the whole thing. What this buys is us is damage control and a much clearer picture of what an attacker could of accessed, and what they probably could not of because no cookies or secrets were available to memory or disk at that time. I can assert -maybe- this one token was phished, but that none of the others were at risk. If the attacker is on a phone with Google Authenticator, they an just generate all the codes they want for every service. We lose the whole farm.

discreditable 10y ago

If you are rooted, you can easily copy the sqlite database that secrets are stored in. I've done this a few times to migrate secrets to a new phone.