Should allow seed export/backup about google-authenticator-android HOT 22 OPEN

I don't think it undermines the 2FA concept at all - quite the opposite.

Consider the case without this feature. The user has not saved screenshots of QR codes anywhere (nobody told them they should). So when buying a new device they must re-enroll in 2FA for all their accounts. In practice this means, re-authenticating to the service via something they know. So it degrades to 1FA! And worse, because upgrading devices is such a common occurrence, providers that support 2FA will expect users to come to them and ask for it to be disabled because they got a new device, so an attacker who claims the same thing won't raise any suspicion.

Consider the case with this feature. The user takes the second factor (thing that they have) and transitions it smoothly to a new device via physical contact. At no point do they need to authenticate to the service provider using only weak knowledge based authentication. It stays 2FA the whole way through.

With NFC transmission there is no need to regen HOTP codes. The counter can be sent to the other device along with the seed.

The original app can show on screen that an NFC transition took place, for people worried about their phone being stolen, unlocked and then cloned whilst they aren't looking.

from google-authenticator-android.

Sure, I understand the evil maid attack. But that's why I suggested a warning that shows up in the app if there was a recent transfer. That seems to strike a reasonable balance, especially because 99.99% of the users of 2-step verification anywhere are protecting themselves against remote attackers like phishers, hackers with stolen password lists etc. People who are so high value targets that someone might actually physically steal their phone without them noticing and clone their secrets via NFC are presumably the target of some spy agency, and those guys have plenty of options.

My current account list contains:

• 3 Google accounts
• Gandi.net
• 1 Google account that uses some kind of third party auth service I know little about (Okta), it's not Google handling the logins
• A Bitcoin exchange. Their 2FA implementation lets you pick either the app or SMS codes and if you lose your second factor, you have to go through ID verification to get it back. There are no backup codes as far as I'm aware, unless they added them very recently.

So the case I'm making is that features and quality of 2FA implementations vary quite a bit across the web, so I feel tuning the app for people who have to worry about evil maid attacks is making the classical "yellow stick note" security/usability error. It might help the 0.1% at the expense of hurting the 99.9% who just need protection from ordinary hackers.

from google-authenticator-android.

We seem to have duplicate issues that are almost the same. See: Issue 246.

I'll add a few points that have not been mentioned above.

1. Authy is not a suitable replacement for Google Authenticator. Authy requires invasive permissions (access browser history and bookmarks, access contacts) and requires you to supply a mobile phone number. These are privacy violations not appropriate to an app that merely generates authentication codes.
2. The complete inability to export 2-step authentication secrets protects you in case somebody forces you (at gunpoint, by court order, etc.) to reveal the secrets.
3. I still think the user should be able to export secrets by default, but should be able to choose to irrevocably disable the ability to export secrets.

from google-authenticator-android.

I sympathise the problem. I have 9 configs in my GA, myself. I guess I only switch phones every 1-2 years, so it's not a problem that often.

But consider this too:

• I borrow your phone, and clone the credentials.
• I reset all data for GA on your phone, and then clone the settings back.
• Bingo, cloned without a trace.

Sure, you could try to cover all of these cases, but it doesn't make me feel all warm and fuzzy. I can even change the clock on the phone to work around a message saying "this phone was synced at X time", a message I wouldn't notice with daily use anyway.

In the end though, code talks. Feel free to implement or fully design this. When there's code, that code could be merged (or live on as a fork). You don't have to convince me for someone to implement this. But even with a full design I wouldn't expect anyone from Google to implement it (not for not liking it, but because this opensource project is not staffed).

It may be me you have to convince to get it merged here though, and I'll be picky about not introducing new attack vectors.

from google-authenticator-android.

I think, there could be a pseudo-secure version: if a user wants to use the export functionality, they need to configure a password/pin to protect the export functionality before adding the first account.

If no such password is set before the first account is added, export cannot be used without first removing all configured accounts, setting the password, re-adding accounts.

from google-authenticator-android.

Yeah I agree. I think this bypasses too much of the benefit of 2FA.

For TOTP you can save the secrets by whichever means you input them. GA is lacking a feature for changing the HOTP counter though, so you'd have to generate codes until you're back where you were. I don't think I'd want that feature either though, because that makes it impossible to know if someone stole a key from the future, and are just waiting to use it.

from google-authenticator-android.

The case that I feel it's more important to protect against is that someone borrows your phone for a couple of seconds, and extracts all your secrets. It's much easier if you can answer the question "can someone copy my two-factor credentials?" with "no".

Otherwise you etch closer to the land of "something you know" rather than "something you have".

Also, Google can send an SMS with a one-time code. I can't speak for Google account recovery processes (or that of other companies), but I'm also not sure who you're addressing this feature to.

The general public will never back up their secrets, even if this feature existed. So it won't affect account recovery anyway. You still need that, and it'll be used just as much as before.

Security minded people should have phone number registered, so that a text can get them in.

And before you say it, borrowing a phone for a few seconds to get an SMS means you have to use it right then, so the window of attack is much smaller than if you have a copy of all the secrets. For the latter you have compromised the second factor forever, and now only need to learn the password.

from google-authenticator-android.

Right, that's why I'm debating with you :-) I'd like to know if a patch would get merged before I write one.

The data reset attack is clever. It could be countered by showing the user when they added an account, e.g.

"Added 2 days ago"

and by using a timestamp from a secure timestamp server e.g. the Date header on a call to gstatic.com/gen_204, so nothing in the phone's settings can be used to override the time.

Yes, it requires the user to notice that when they open the app all the accounts are listing a few hours/days instead of a few months. But they will be looking at that part of the screen to read the code too. Again, this seems reasonable for the usability win.

All this is assuming that the attacker doesn't have other ways to do what they want. Full physical access to an unlocked device is pretty powerful. To access Google accounts you could just install an app with an innocuous sounding name and use the standard OAuth mechanism to sign the app in. As Google mobile signins never time out on phones, that'd give you more or less permanent access to the account for as long as the user doesn't notice. Likewise you could uninstall the users browser and reinstall a hacked one that uploads session cookies after a login. How far do you want to go to tackle the combination of evil maid+defeated screen unlock?

from google-authenticator-android.

So when buying a new device they must re-enroll in 2FA for all their accounts. In practice this means, re-authenticating to the service via something they know.

Well no. They still have their old phone, right? And if they don't then this migrate path won't work anyway.

I think, there could be a pseudo-secure version: if a user wants to use the export functionality, they need to configure a password/pin to protect the export functionality before adding the first account.

Nice. I have a hard time coming up with a plausible attack on that. Yes, I think I should be able to merge that, but I would be picky about getting it exactly right. For example one must assume that the NFC transfer is being sniffed or even MITMed, so it should establish a secure channel over that and on top of that encrypt the database using the password.

So a workflow could be:

• On receiving phone, press "receive database"
• On sending phone, press "send database"
• Phones tell you to hold them close. You do.
• Some code is shown on both phones, this code should be the same on both phones, thus proving that the secure channel has been established.
• You press "yes" on both phones to confirm that the code is right.
• You type password into sending phone
• Database is marked as having been exported. (before it's transferred)
• Database in transferred
• You type password into receiving phone.
• Profit!

Maybe this can be simplified. Maybe it needs another step. But this is what I came up with off the top of my head.

Yeah, this feature getting merged in this repository is unrelated to whether it'd get into the Play store version. And this opensource version is unlikely to get put on the Play store itself. As I understand it you're perfectly free to put it there, but it most likely won't come from Google.

Pure speculation, but the future (and actually present) for auth to Google services is using Security Keys, so putting too much effort into improving a workflow that will never be as good as the FIDO one may be deemed not worth the time.

The problem of authing phones is not yet solved entirely (SMSs work, but U2F for NFC is not yet specified by FIDO), but it's going to be better than having to type numbers, surely.

(disclaimer: "you're free to put it [on the play store]" is my understanding, and I would be very surprised if this isn't the case, but since I work for Google I should clarify that this message itself does not in itself grant permissions or licenses. It's Apache licensed, whatever that means. Sigh, some of the voices in my head apparently are apparently lawyers)

from google-authenticator-android.

I'm in the same boat as you. I've already implemented this in my fork of the project. You might want to check it out. https://github.com/banasiak/AuthenticatorPlus

I haven't requested to merge this back into the main project yet because it really does undermine the concept of 2FA. The original developers did a good job of securing the source keys (on un-rooted devices), and this fork essentially bypasses those protections.

That said, I switch devices so frequently, I felt the trade off was worth it. You may as well.

from google-authenticator-android.

That doesn't help existing users, but is better than nothing.

Is this not redundant with the screen lock though? We're only discussing the case where someone cares enough about security to use 2FA but not enough to set a PIN on their screen lock. I'm not sure such a person would set a PIN on GA specifically.

from google-authenticator-android.

For existing users there is in my opinion no way that is "secure" (with regards to the insecurity of the whole feature). Also, existing users are limited to the users of this Open Source version, as the Play Store version is not really related to this anymore and this version won't ever be released in Play Store.

Actually, I use a pretty weak PIN code as screen lock, but I'd use a strong export password (that could also be used to encrypt the content of the exported file, which needs to be secured as well). Also, if they want to export keys, they'd set it despite using no/weak screen lock, because it wouldn't work otherwise.

We'd just have to make it clear during the process of adding the first account, that they need to set an export password now or it'll be too late. There is no problem (IMO) to have the user change the password later on, though, but it's important that it is there from the beginning.

That's just my suggestion on how we could make this possible and I can also relate to anyone saying: once we can export, we don't have to care about it's security as we are screwed anyway in regards to "what we possess vs what we know" (but so is anyone with root access already, see Titanium Backup (which I use right now to transfer to new devices)).

As most of the time, it's a security vs convenience trade-off. My approach would give a choice: do I want the trade-off (I set an export password in the beginning) or I don't (I don't set a password). Would satisfy both sides.

It's just a question if @ThomasHabets or anybody else with access to this repository would merge something like that, because actually I don't feel like managing my own fork for now, like @banasiak does for exactly this feature.

from google-authenticator-android.

Oh, huh, the Play Store version doesn't match this version? How comes? That is too bad - I feel much less motivated to write a patch if it won't actually get shipped to the vast majority of users.

from google-authenticator-android.

@mikehearn Google went proprietary with it, as with many other Android things.

from google-authenticator-android.

I like the solution @capi proposed. If @mikehearn wants to implement it, I'd accept the patch into my fork and publish it to the Play store as a separate app. But, yeah, I doubt Google would ever merge it into the proprietary version. It's been proposed over two years ago in this group with no comment from Google. https://groups.google.com/d/msg/google-authenticator-issues/baROYFInQk4/7ATykByefnwJ

from google-authenticator-android.

So when buying a new device they must re-enroll in 2FA for all their accounts. In practice this means, re-authenticating to the service via something they know.

Well no. They still have their old phone, right? And if they don't then this migrate path won't work anyway

If you consider this for a transfer via NFC only, it might change if you also consider it a backup approach (to an encrypted file). Which is even more insecure, but might be exactly what people want.

from google-authenticator-android.

Oh yeah. And really backups are pretty much indistinguishable from a security perspective from transferring back and forth (except for the "this setup was populated at TIME", which must be visible if backups are enabled. Maybe with a red background if it's "recent".

Oh, and the feature "prevent all future exports" must exist for those who have set a password to start with.

from google-authenticator-android.

Would you be willing to merge a properly encrypted file backup functionality to this project? Because it seems more easily doable than the whole NFC transfer thing.

Preventing future exports under my proposal would be simply wiping the export password from storage.

from google-authenticator-android.

You can get around preventing future exports by simply re-importing after exporting though.

As long as exportability is:

1. Not default, nor prompted.
2. An advanced setting with warnings, that can only be turned on before adding any keys.
3. Even if you enabled before setting up keys, must be possible to disable (and then of course not be able to re-enable until complete app reset)
4. UI must show "Last export done at TIME", where TIME is taken from some secure non-phone place (therefore needs internet access), if exports are enabled.

This should be fine. What do you think of this? I'm also going to see if we have some previous thinking about this somewhere.

from google-authenticator-android.

Just throwing this out there, I'd prefer an encrypted file vs NFC or another phone-to-phone transfer mechanism. Although I switch phones often, as a developer I typically manually flash Nexus firmware even more often. Unlocking the bootloader wipes the phone data, thus my need to restore the keys to an existing device. I think the encrypted file would be a good first step, then implementing a transfer mechanism could be layered on top of that.

from google-authenticator-android.

@thalesfsp that appears to address exactly zero of the concerns expressed in this thread.

Unless I'm misunderstanding your terse description.

from google-authenticator-android.

FYI, Google recently announced support for this feature in the official Google Authenticator Android app: Introducing portability of Google Authenticator 2SV codes across Android devices

from google-authenticator-android.