How to transfer data/backup when switching handsets? #246
Comments
|
Comment #1 originally posted by klyubin@google.com on 2013-02-04T04:46:31.000Z: Google Authenticator does not export/back up key material by design. To add keys/account to another instance of Google Authenticator, you'll need to follow account-specific instructions. For example, for Google Accounts, go to https://accounts.google.com/security, then click on 2-step verification settings, then click on "Move to a different phone". |
|
Comment #2 originally posted by prof7bit on 2013-07-02T13:52:21.000Z: backup functionality should be implemented, otherwise its impossible to backup the keys without rooting the device. An easy to use backup function for important data should be considered essential functionality for every app and even more so for an app that manages private keys that cannot be restored otherwise and whose loss could even result in financial damage! Users should be enabled to have full control over their data! |
|
Comment #3 originally posted by harningt on 2013-08-21T16:24:23.000Z: Google allows for this migration path, however there are many cases where 3rd parties use Google Authenticator but do not have the recovery methods that Google has (ex: one-time use print-out passwords). Ideally 3rd parties should offer "recovery/migration" methods, but many will not invest the effort to do this, and some even charge for the service. It would be preferable to have this be an option, perhaps at installation time for keys/accounts. If export is allowed, then the given account information can be exported. |
|
Comment #4 originally posted by leon@lukiyanets.com on 2013-11-10T06:48:36.000Z: I have 10 accounts in Google Authenticator for 6 unique applications. Only one of those is Google. How do I move all of this to a new device? If I go to each application and reset 2-factor authentication - that's 1-2 hours of work. |
|
Comment #5 originally posted by g1adrift on 2013-11-11T22:41:31.000Z: Would it be at all possible to use Google as an intermediary for transferring all TOTP secret keys stored in g-a to a new device? The app does have Internet permissions, so it wouldn't need to add a new permission. I envision it would work exactly like the phone transfer mechanism works (which I haven not yet tried), but also acquires an encrypted copy of the secret keys from the mobile app over the Internet. The encryption key could be exchanged by the two devices visually, via QR code. Google would provide the transfer authorization (by authenticating the user through the web). The only attack vector (aside from physically having the devices in hand) I can see here is a MITM attack where someone fakes the Google server. In this case, the attacker would still not be able to extract the TOTP keys as the encryption key protecting the data transfer is exchanged offline. I suppose you do add a possibility of someone having access to both your device and Google account (say, by a unlocked laptop), cloning your secret keys without your knowledge. To mitigate that, you could add a self-destruct mechanism to it in order to ensure that there are only one copy of the secret keys. As a user of the authenticator for 7 different services (one is Google), I do find it frustrating that I need to go through a lot of effort to migrate to a new phone. |
|
Comment #6 originally posted by jaimeyap on 2013-11-30T20:54:27.000Z: Surely Authenticator could support a mechanism that allowed you to export an encrypted blob, with a strong key inputted at export time. Either gathered from the user, or generated using entropy on the device from random swiping or something. It would be on the onus of the user to safeguard access to this key and to the encrypted blob. And it would be of little risk provided authenticator enforced a certain bar for key strength. I too have 2-factor auth enabled for 10+ services. Many of them financial, with no way to work around the 2-factor authentication should my phone get lost, stolen, or bricked. I am absolutely terrified to lose access to my phone. 2-factor codes are VERY important pieces of data. Too important to not backup. |
|
Comment #7 originally posted by robsonbhx on 2013-12-02T15:16:45.000Z: This is driving me crazy. I started using 2FA some time ago on many different sites and migrating to a new phone was a HUGE issue. This is something that can actually drive me AWAY from using 2FA, I can't image using it on 2-3 times more sites and having to go through that dreadful process again. |
|
Comment #8 originally posted by sotiris1 on 2013-12-06T17:38:31.000Z: Google Authenticator is great but when it comes to moving all those codes to a new phone is totally sucks!!! Really Google guys why can't you spend a couple of hours to create a backup/restore solution. My gut feeling is that just like most new things young tech folks workout they are always left half done because its always cool to move to something else. |
|
Comment #9 originally posted by jaimeyap on 2013-12-06T18:13:59.000Z: I notice there is already a data export and data import package in the Authenticator source. @alex Klyubin I realize this is intended for migrating between App versions. But surely we could extend this, without weakening the security model, to support exporting encrypted blobs, and importing encrypted blobs. The important piece being that the secret used to encrypt the blob must NOT be one guarded by a 2factor account. We could either use a password generation scheme using swipe+accelerometer entropy gathered at export time, or simply make it clear to the user that they need to pick a unique master password. I know that export/import is not implemented by design. But it is a bit short sighted to not change your stance on that. People end up either not using 2factor at all, or doing bad things like saving copies of the barcodes or serialized seed strings. Or even worse, rooting their devices and installing third party backup apps that have root access to their authenticator data. This is clearly not better. Really hoping to win you over :). Heck, I am tempted to redo all my 2factor codes and print out paper copies of my barcodes. But that really seems silly (and painful) when there is a perfectly reasonable technical solution. |
|
Comment #10 originally posted by ozonotech on 2013-12-15T16:36:52.000Z: ...and seems that Google don't give a fuck about this nightmare. I have 45 DIFFERENT ACCOUNTS inside my Authenticator and now I have to change my cellphone. Damn the day I choose to use this crap... |
|
Comment #11 originally posted by dimonb on 2013-12-23T19:54:30.000Z: it's really really important thing to backup-restore such kind of data |
|
Comment #12 originally posted by adil.hindistan on 2013-12-24T00:46:53.000Z: Seriously guys, moving "1" google account is not much of an issue, but what about people who are using several Google accounts + Facebook, Dropbox etc. etc. Backup/Restore should bring all that stuff back. What is the reason that this is not happening? |
|
Comment #13 originally posted by rayjonesy on 2014-01-12T21:16:30.000Z: I agree, so use this app in the meantime, or use Authy, since Google Authenticator doesn't allow you to backup/move your 2fas. |
|
Comment #14 originally posted by shah@google.com on 2014-01-14T06:07:30.000Z: <empty> |
|
Comment #15 originally posted by nospam256 on 2014-01-28T18:00:00.000Z: What if you lost your phone then what ! |
|
Comment #16 originally posted by nospam256 on 2014-01-28T18:04:36.000Z: I think if you can't backup those keys, we probably shouldn't use it, .. i have one for battle net and some times i had to reset the phone totally forgot about the battlenet authenticator on it, and now i got to go and reset it, .. proof of id the whole crap really annoying. Worse what they consider proof of identity can be faked ! There's no such thing as proof of identity all those things copies of something can be acquired from someones mailbox or obtained by hacking into someones computer, .. and faked or altered through some photoshop, .. |
|
Comment #17 originally posted by augusto@favetti.net on 2014-02-14T23:29:55.000Z: We really need this option of moving all acounts from one device to another... recreate them all is a way of saying: stop using this app! |
|
Comment #18 originally posted by ftmvideos on 2014-02-15T21:43:52.000Z: I have five 3rd party apps on the authenticator..how can I easily move them to a new phone without having to have to spend an hour setting everything up all over again? |
|
Comment #19 originally posted by philcalfee on 2014-02-28T04:59:36.000Z: I'm really worried I will lose my phone or something like it, then how will i access Accounts that I have set up on it? What the hell!? There is really no way to back up or migrate the data? |
|
Comment #20 originally posted by stephen.leavitt on 2014-04-12T19:19:49.000Z: Please implement a secure import/export option in this app. Thank you. |
|
Comment #21 originally posted by devendra.nantama on 2014-04-22T10:59:38.000Z: Glad I found this issue before changing my device, so I can do some preparations then. But in case we lost our device, what we can do? Not all sites and applications I used are supported print out code. Google, please dont make this guardian angel become demon lord that prevent us from heaven gate. Thanks |
|
Comment #22 originally posted by richardagreen on 2014-05-07T15:50:36.000Z: How about a compromise? If Google Authenticator does not allow the exporting of keys, then it should not allow the importing of keys ! It should, instead, refer users of services that are non-google to alternative 2FA management services (ie Authy etc). |
|
Comment #23 originally posted by mikerawsonnz on 2014-05-15T08:04:00.000Z: come on google - you know this is BS - you need to enable a way to recover from a lost phone |
|
Comment #24 originally posted by kyounger on 2014-05-15T16:39:08.000Z: The only way to do this currently is to root your phone so that you can do a true full backup. This would void warranties, though, so not a good option. Echoing others' sentiments, this is possible to do securely, it just takes some interest and motivation from the maintainers. It's sad, because you hear frequently that there is a balance of security and convenience that works well. This is one of those situations that people are crying out for that balance, but currently the security side is winning. Human behavior dictates that people will probably start deciding that the risk of losing their phone is higher than the risk of non-2FA credentials being stolen — which is then a sad day for security. |
|
Comment #25 originally posted by syberghost on 2014-05-15T16:54:03.000Z: Actually this isn't even security winning; as a result of this, most This ultimately hurts security more than it helps. |
|
Comment #26 originally posted by david.hardy on 2014-06-01T20:51:04.000Z: Google.. this really is a critical issue. Now I have to keep my old phone, just to access some secure websites. Not good enough. |
|
@ImaCrea How is that different from Google Authenticator? Also, when I went to Authy I also used another app (LastPass) at the same time, put the codes into both. |
|
@ImaCrea |
|
Ok, Google :) Why not provide export / import feature via password protected archive? |
|
@rudyryk that question is to me pretty clearly answered above, and/or in the previously mentioned google/google-authenticator-android#23. But also because if it's backed up and protected by a password then it's no longer two-factor. If a password can give access to the OTP, then what you have is two passwords, meaning one factor. |
|
@ThomasHabets This should be one-time download, not stored forever, chances that it will be intercepted and decrypted exist but are in general miserable. |
|
@ThomasHabets Probably backed up archive could be also transferred without network at all, it's tricky on iOS devices but maybe there is way to do so. |
|
You can just save the QR code itself then (at least for TOTP). |
I'm not sure about what are you suggesting. I have many (more than 10) services with 2FA setup and all I can see in Google Authenticator app is a list of 6-digit codes (constantly recalculated). QR code is provided by services on install, but it's weird to re-install and save all 10-20 services. I'd prefer to have offline backup (on flash drive, for example) from which I could restore at any time - if device is lost / broken for example. |
|
@rudyryk A one-time download, that you do after you've added all (?) of your accounts. After you've added another one you can download that one... once? If you can download it, if you can restore it, then you can clone it. And then it's not a second factor. Yes, once you've programmed in the QR code into GA then by design you cannot extract the secret again. Once you close the webpage or whatever that gave you the QR code then you can by design not see it again. Instead of making backups, I'd say you should enroll a second phone with a new secret, for the same account. It's inconvenient, yes. But OTPs are not super convenient if implemented securely. Where it's possible I'd recommend U2F. |
This could be problematic with trade-in upgrade for example :)
Hmm, I'm not a security expert, I thought that codes generated with authenticator app are just "seeded" with some secret and seed is stored - to generate every next value by seed + time. So we just need to clone all underlying data (values for "seed"?) from authenticator to another instance of authenticator and get same codes on another device. |
And that's why we don't implement that cloning/exporting. Because then it's no longer second factor. Just like any hardware token will resist extracting the secret. TPM chips, Yubikeys, U2F, RSA SecureID, etc... they're all, in the end, a "secret" but unlike a password can't be (easily) cloned. And making it easier defeats their purpose. |
Ok, I see, that makes sense, thank you for clarification here! On the other side when we are unable to simply backup 2FA codes we need a fallback to SMS codes to recover access if 2FA device is lost / stolen / reseted to factory defaults and so on. Is it ok? |
|
@rudyryk SMS codes are known to be probably the least secure "second factor" (google "SMS second factor"), and this is for employees I'd recommend having "go to security desk and show your badge to a human" as a fallback. Even "printed note of backup codes in my desk" (Google accounts and the PAM module supports this. I think Github has backup codes too) is still a good second factor as a fallback since unlike SMS it still prevents all attackers who can't physically get to you. Still: If possible, use U2F. If everything else is infeasible, use SMS. |
|
I don't think the argument blocking this feature holds any water whatsoever. There's two arguments that I'm aware of:
If there are additional arguments I'm missing, please let me know and I'll do my best to address those concerns. What if someone nefarious grabs your device and extracts yours keys?I'm surprised to see this argument used in 2017. It's pretty standard that once someone nefarious has physical access to a device it's security game over. The same applies if you're using a physical 2FA device, if someone else gains access to it, they can potentially login, make changes to the authenticated service, potentially add another 2FA device; then you've already lost. Pretending that you're somehow secure because the app doesn't let you extract the seeds is at best in denial and at worst malicious towards users as it downplays the risk of exposing your device to third-parties. Browsers intentionally don't encrypt user's cookies (which contain auth credentials) because they don't want to give users a false sense of security. But what if they copy the seeds and you don't know? Again, as above, they've potentially already gained access to whatever it is you're trying to protect with 2FA, so I don't see this as particularly compelling. However, if this is legitimately a concern, then why not implement transfer instead copy? Just wipe the keys on the source device once they're copied. Won't I then be locked out if someone nefarious steals my keys? Potentially, but they can almost certainly lock you out (or worse) once they've 2FA'd into whichever service you're trying to protect. It's not real 2FAThis seems like purist ideology, and unless there's some compelling reason to be "real" 2FA I don't see this as relevant. Google Authenticator is already a software solution when "real" 2FA consists of embedded hardware seeds. There are many genuine security/privacy advantages to allowing users to copy their seeds from one device to another. In particular, you're not encouraging users to save the seed data/QR elsewhere. No, users shouldn't be doing this, they should add a new 2FA device at each service. However, the point at which you're adding additional 2FA devices is the point at which the user's security is most vulnerable. If their computer is compromised, or in the case of QR, if someone has a camera nearby, then you're unnecessarily exposing the service. An additional point, it's already possible to copy the seeds on rooted/jailbroken devices. It's true that it's potentially somewhat complicated (less-so on Android), but downplaying the possibility doesn't help users. Particularly in the case of Android, it encourages users to root their device, and using unofficial means - as first-party bootloader unlocking required for root typically wipes the device. |
|
@Benjamin-Dobell Great posting, thank you!
BTW it's also possible to store and display history of exports making it hard to export seeds silently. |
Doesn't mean we have to make it simple, fast, and scalable as an attack. We have layers of security protecting copying passports and money too. Both are copyable. What's really different here is our unstated threat model; who the attacker is and how motivated and prepared they are. I think our differing opinions originate there.
Perhaps. I'd like to see a full design document for how this should work, but I already see that this design will likely have the problem of "how do I know that I'm not transferring to something that allows copying?". IOW: you could transfer, copy, then transfer back. There are similar problems with the awful "migratable keys" in TPM. (luckily you can set a bit to not allow migration, along with other off-topic measures).
A bit ad hominem there. Not really a technical argument.
But they DO bind them, so if you're implying that browsers just accept that cookies are copyable then that's not accurate.
Persisted shadow-access lurking for years is not the same threat as a one-time compromise.
I think it does. I like to phrase these things as "it can happen. But it won't happen [to you]". It's why the vast vast majority of users should not worry about Apple's fingerprint and face ID being spoofed. Yes, of course they're spoofable. But that's not how they're hacked. A wise man once told me "You're right, but that's not how users actually are compromised". Will backup/xfer of GA tokens cause people to get compromised? Tautologically: "not if it's designed and implemented correctly". But it is installing a door. While trying to protect the door, sure, but a door nonetheless.
Like I said: Many aspects of this needs more design and thinking. E.g. this would also need to show "there have been no exports since a given date" since data can be purged. And questions on whether users will notice this date changing. There are ways to fix this, but there's no point in micro-designing this part unless someone is willing to write up (and then implement) the whole thing. I'm only saying that I'm not volunteering, and would not accept a pull request for an implementation of a design I disagree with.[1] [1] I'm the de facto maintainer of GA opensource, which I why I say "I". Someone else at Google is free to take over maintainership and make other decisions. I have no edge on knowing the (app) code. Or someone can fork the code. It's Apache licensed. That said, this is all about this repo, and the opensource GA. I can't speak for the closed source version, but could forward design proposals etc if fully written. Pasting standard response here, for reminder: -- FYI: The version in Google Play Store / Apple App store is not the same as this opensource version. They've diverged. This opensource version is also unlikely to end up in the app stores. This open source version doesn't get much love, but I'll accept well-written pull requests. But don't expect this feature to be implemented by Google. -- |
|
@ThomasHabets Thanks for the detailed response.
Interesting. I've not heard of this before, I'll need to do some reading regarding this, its scope and how frequently it's used in practise. Just yesterday I imported all my cookies from Chrome into Firefox and was able to use these existing cookies to authenticate with several services without being prompted for my password. I don't believe this worked for Google services however - again I'll do some research, thanks for the info.
I just don't at all see this as a door. To me it's simply being practical with respect to both security and how modern consumers use and purchase mobile phones. The whole concept behind Google Authenticator is that we're trusting users to keep their mobile phone secure. It's an assumption, but it's a core assumption of Google Authenticator. Unauthorised access to a phone running Google Authenticator is enough to invalidate the entire concept. I certainly agree that this does make it easier for someone nefarious to steal the seeds. However, if a malicious person has valid authentication tokens, then having the seeds to generate them is somewhat irrelevant - security has already been compromised. Conversely, I would have thought that under normal use (i.e. no-one malicious having access to your mobile phone; that's the exceptional circumstance) then users are at their most vulnerable when using a computer to setup a new 2FA device for a service. This is a moment of weakness that presently exists, more frequently than necessary, due to Google Authenticator's inability to transfer from one device to another. As such I see this as something meaningful Google Authenticator can do to improve a user's security. Even if it means that once you're compromised, you're really compromised, the goal is to avoid being compromised at all. It's not really Google Authenticator's responsibility to try assess and mitigate how compromised you are, this is going to vary hugely from service to service.
It was my hope that by discussing this here, rather than simply submitting a pull request, that those involved internally (with the Google Play build) would be open to discussion. If that's not the case then it's probably somewhat futile of myself and others to spend too much effort on this here. After all there's nothing stopping us forking and adding the feature ourselves if all we're after is the functionality for our own personal use. |
Sorry, I missed this statement. This is definitely a reasonable point. However, it is making assumptions regarding what it means to be compromised; which is going to vary drastically depending on the service. Many services make it quite easy to add additional 2FA devices once the user has 2FA'd with an existing device. It depends on the service in question as to whether or not this could lead to what would be considered persistent shadow-access. However, adding additional 2FA devices aside, single-time auth may be all that's necessary e.g. authorisation to bulk download private corporate docs etc. To weigh this risk up properly is difficult, if not impossible, as Google Authenticator can be used with any number of services. For this reason I think this line of thinking ought to be out of scope for the Google Authenticator project. Although, I acknowledge that's subjective and I'm by no means in a position to define the scope of the project. |
|
I'll send an email to the team that owns the Play Store GA pointing them to this issue, but can't speak for them nor promise any reply. Steve Gibson on the Security Now podcast sometimes mentions GA having the good feature of not allowing backups. Not that he's always right (and in fact I often find him to be wrong), but there could be a silent majority that has the same opinion so there could be PR issues with implementing backups. But that's above my pay grade. |
|
When Google Authenticator was originally released, barely anybody was using two-factor authentication. Googe was merely trying to provide an easy mechanism for use with its own services. I don't think they expected Google Authenticator users to enter more than 2-3 different accounts. And they must have figured that other service provides would do what they did, i.e., provide backup codes, and allow alternative means of password reset. But Google Authenticator ended up becoming tremendously popular. And if you lose your device and have to reset 25-30 accounts, it becomes a nightmare. To prevent this nightmare, people cut corners. For example, they take a photo of a QR code before scanning it to initialize a new two-factor account. Or copy-and-paste the secret into an online notepad (like Google Keep), or just save a screenshot. So the choice is not between a secure Google Authenticator that never exports secrets on the one hand and an insecure Google Authenticator that does. The choice, out there in the real world, is between a Google Authenticator that never exports secrets but users save secrets as unencrypted notes and unencrypted photos and screenshots on the one hand, and a Google Authenticator that securely exports and imports strongly encrypted secrets. |
|
For the services that accept U2F (Github, Google, Facebook, Bitbucket, Gitlab, Salesforce, Sentry, FastMail, Dropbox, and on and on) I highly recommend using that instead of OTPs. It's phishing-proof, less copyable, easier to use, and better in almost every way. If you after that have 25-30 accounts then you are by far the outlier (though I don't actually have data to back this up). You have a point, but it's not that many users have 25-30 accounts. |
|
It's easy to accumulate 2FA accounts even for average people. 1-2 bank accounts U2F is a nice solution for those who have purchased such a device, but one must always augment it with Google Authenticator for when a suitable USB port is not available, which happens very often. So having U2F in no way decreases the number of Google Authenticator entries that one needs. As for the common use of screenshots and photos ... I speak from experience observing others. I am scandalized by how often I see people using this type of storage mechanism for passwords, 2FA QR codes, even cryptocurrency keys. The key idea here is friction, or lack thereof. Smartphone cameras are so handy, it's very tempting to use them as a convenient storage mechanism. Add to that the fear of losing one's 2FA secrets and having no good way to back them up, and taking a quick snapshot is almost a non-brainer for the average person not fully aware of good security practices. So if I want to persuade somebody to not save a 2FA secret using such mechanisms, what's my persuasive reasoning? I have none, because anybody who has ever lost a device that contained Google Authenticator has been though a very painful experience of restoring account access, and no amount of reasoning from me will make them forget that pain. The ability to export encrypted secrets might be able to compensate for that. |
|
@ThomasHabets Hmm... I suppose the real scenario why we are discussing this issue is the case of losing access to physical device for some reason. Device can be stolen or sold for upgrade etc. How using U2F can solve this issue? U2F can be stolen or lost as well. |
|
I congratulate you for having 1-2 banks that support TOTP/HOTP. That's pretty cool. I'd prefer if they had U2F, but I've found that most banks and other two-factor websites have their own made-up solution (or SMS). If it were "every single site uses RFC-compliant TOTP/HOTP" then it'd be a different story. U2F isn't just over USB. There are bluetooth dongles too. I have SSH keys on yubikeys as well (the same ones that hold my U2F), and the alternative to that would have been GA. I think people should enroll multiple GA devices (with different secrets) to protect against device loss/theft, but sadly that's rarely possible server-side (and client side you'd need a spare phone, which is not good). It's more possible with U2F. In the end though: If you want this functionality then for now you'll have to switch to another app, whose developers are more in line with the other side of this trade-off. Even if you were to convince me and you implement it and send a pull request, this won't make it show up in the Play Store/App store version and therefore very few people will get access to this new feature. |
If I may clarify, my purpose here is not to convince you, @ThomasHabets, but rather, just to make sure the issues are recorded here in a form that they can be read and understood. It's very kind of you to read and respond to the comments here, but I think most us understand that that doesn't mean that you are the person who will be making the implementation decisions for the app store version. There's always hope that someday the developers of the app store version will reconsider the security issues. This could happen, for example, if some high-traffic click-bait blogger's 2FA screenshots get misused by a hacker, and the event makes news headlines. If and when the time comes, the developers of the app store version can be pointed to this github issue, and all the information they need will be here ready for use. |
I actually have one that does NFC. It turns out that NFC for proper functioning requires an induction coil that must span a certain surface area for proper pairing. The tiny U2F device has a very small surface area, so the NFC connection is very sporadic. I have to run it over the back of my smartphone several time until I hit the sweet spot just right. So it has been a disappointment. I'll have to look for a Bluetooth version next time. |
I have 28 - I just counted. I use it for everything I can, even domain registrars, WordPress logins etc. There are a lot of use-cases. I use Authy & Lastpass on iOS - both of them sync to the cloud.
and that is the real issue. We already have our phones, we don't want to be carrying around yet another device. Consider how Apple / Android Pay did away with the need to carry credit cards. |
Good for you. Contradicts exactly nothing I said. I have many accounts too. GA has tens of millions of installs on Android from the Play store alone (Apple App Store doesn't seem to give a number).
Like I said: The crux of the matter is "securely". You can demand, attack, and insult all you like, but without a design that does it securely this is a waste of time. It's like the demands from governments to install good-government-only backdoors, and demanding that laws of math bow to the law of the land, and saying "you're clever people, you can make it happen". If you personally are willing to make the trade-off then there are alternative HOTP/TOTP implementations that do what you want. If this continues to do nowhere I'll just lock this issue. |
Original issue 247 created by luke@goh.me on 2013-02-03T20:24:55.000Z:
I have the authenticator app loaded on both iOS and Blackberry. When I change handsets, how do I make a backup of the data and port it over to the new handset?
The text was updated successfully, but these errors were encountered: