Backup and Restore Codes

[npmccallum]

Reported by stephenjudge on 8 Mar 2014 17:44 UTC Many sites that offer two factor authentication offer a method to recover access to your account should you loose your authentication device, this is usually SMS authentication or a set of printable codes. However some sites and OTP implementations don't have such a feature and if you loose your authentication device, you loose access to your account.

An example of this is if you add the Google Authenticator plugin to a self-hosted Wordpress blog. The plugin does not provide a secondary method of authentication. In their FAQ there is this question:

"'''Can I create backupcodes'''?

''No, but if you're using an Android smartphone you can replace the Google Authenticator app with Authenticator Plus. It's a really nice app that can import your existing settings, sync between devices and backup/restore using your sd-card. It's not a free app, but it's well worth the money.''"

This proprietary app, Authenticator Plus, does look very nice and has some nice features, but the most beneficial I think is its ability to backup and restore codes.

This could be a huge addition to FreeOTP and I would like to request that someone considers this feature and looks at a way of implementing it. I am not able to code myself.

[npmccallum]

Modified by stephenjudge on 8 Mar 2014 17:46 UTC

[npmccallum]

Comment by davidstrauss on 14 Mar 2014 04:32 UTC What I would really like is for it to use a standard, FOSS service like Firefox Sync to shuffle data between devices in a secure way.

[npmccallum]

Comment by npmccallum on 28 Mar 2014 18:20 UTC Doing is a really great idea. But without encryption support, it is not possible in a secure way. We need to implement encryption first.

[npmccallum]

Comment by patcon on 5 Jan 2015 21:38 UTC +1 from me. This is the only feature I really miss. (Having just spent the last 2 hours trying to recover access to a service using 2FA :)

As a work-around in the meantime, there was a review in the android app store that offered a great solution:

https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&reviewId=Z3A6QU9xcFRPRWNKSE93UTRlVENSall1Wi1FNnY0TVd0SGtDNHhzUEdvVnBoaUZXbHloM2RoVF9NN3NTNFdoSGRoWXZLMWRIcF9hYS1TYlM3MFdteGE2ZHc&hl=en

After playing with it a bit the only downside is the backup. It needs a proper way to generate a local backup which I could copy to a computer with a truecrypt volume using sftp. To backup you need to use the adb command on your computer. Connect your phone and run: adb backup -f freeotp.bak org.fedorahosted.freeotp That will store the FreeOTP data to the file freeotp.bak. To restore this data, just run: adb restore freeotp.bak

I suppose you need to be decently tech savvy to use it, but it's better than nothing :)

[npmccallum]

Comment by jpl on 16 Jan 2015 02:09 UTC YES! I have some more thoughts about this in ticket #6.

Being able to view the saved tokens would allow manual export to pen/paper, but there's so much more that could be done with import/export/backup/sharing/migrating, all securely, and the crypto isn't that hard.

[npmccallum]

Comment by woi on 17 Jul 2016 18:51 UTC Replying to npmccallum:

Doing is a really great idea. But without encryption support, it is not possible in a secure way. We need to implement encryption first.

I think it would be sufficient to save the backup as an encrypted archive. At least as a first step. So the user would manually chose to create a backup, then be asked for a password, which then is used to create an AES encrypted zip file (or which ever achieve format is convenient). Threema for example backs up like this.

[npmccallum]

Comment by zeevro on 20 Jul 2016 16:12 UTC Android can now back up app data to google drive automatically. Adding support for that would be a good idea IMHO.

[grmpyninja]

Don't know if cloud-backup is the best option. Maybe I'm a paranoid, but I'd really like to do it myself, without cloud and google. Especially for such crucial stuff like OTP codes. Maybe as additional option if somebody doesn't mind to send it to google, but by default I guess it's better to do it manually on your own machine.

[DieterSchieber]

I agree that an encrypted export/import would be a great new feature. Support for easy migrating from one device to another is a MUST for all users of 2FA. But most authenticator apps either do not support this at all or only via clumsy circumventions (like the adb example mentioned above) or by suing cloud services for synchronization. However I really hate to have this data in the cloud! This is sensitive data to me and I just want to have it local under my own control. So having export with prompt for a passphrase and storing the data in an encrypted file using strong encryption + import would perfectly address these key reqirements. While google app data back up (as well as any cloud sync feature) is IMHO just the wrong way to approach this problem: It's not let alone about trusting the cloud provider, but it's also that if somebody get's access to one device which is synced, he can render the cloud data useless and this will be synced to other synced devices ... .

[variousred]

What's the status on this? Not having backup codes makes me very nervous.

[cron0mat]

I have a LineageOS android phone without GApps, so I would prefer a solution with local backup and without any enforced cloud sync.

[arbie65]

Like @cron0mat I would find local backup for android app to be very important. I have already had one issue with I have had phone break and no backup of FreeOTP made it a chore to reset up all my codes

[arbie65]

Could the cloud backup feature in FreeOTP+ be merged back into FreeOTP? That would just leave backup to disk to be added

[esjee]

Just wanted to point out that https://github.com/viljoviitanen/freeotp-export exists. This script allows you to translate an (unencrypted) backup file generated through adb into a series of QR codes, which you can then scan on your new device.

[variousred]

Really need this now, as I just got a new device.

[FSMaxB]

What I do is to store the TOTP URI's in my password manager, but that is quite tedious, because I have to scan the QR code on my computer first.

And I have to recover all the codes one by one, which is quite tedious as well.

[variousred]

The adb backup worked for me, just wish I didn't have to jump through all the hoops for what should have been in the app from the beginning.

[npmccallum]

We are not likely to implement this feature. Backups, encrypted or otherwise, break the promise between the app and the server that the code is tied to particular hardware. Indeed, we will move instead toward storing the credentials in the KeyStore making them unrecoverable.

[npmccallum]

To be clear, moving in this direction will break existing backup hacks (intentionally).

[variousred]

Ok. I stand corrected on what should have been implemented. In this case it seems the issue needs to be taken up with service providers who do not allow for an alternative means of access in the case of a hardware loss.

[dabura667]

@variousred Yes. Any site with 2FA should give users backup codes for disabling 2FA in an emergency.

[g1y]

:+1: for a file export so that I can sync to my new phone with syncthing.

[blaskovic]

@dabura667 Keep in mind, that 2FA is not used only for websites (where backup option to login is available) but for remote servers too, where if you don't have your code generator, you can't log in (thats the point of it).

[sigio]

What worked for me (to transfer the codes between 2 rooted phones... on one without a working camera) adb shell, su, cat /data/data/org.fedorahosted.freeotp/shared_prefs/tokens.xml (copy data) on the other (with the non-functional barcode-scanner/camera): Install freeotp, create a manual token and force-quit the application adb shell, su, vi /data/data/org.fedorahosted.freeotp/shared_prefs/tokens.xml (and paste)

[ehuggett]

We are not likely to implement this feature. Backups, encrypted or otherwise, break the promise between the app and the server that the code is tied to particular hardware. Indeed, we will move instead toward storing the credentials in the KeyStore making them unrecoverable. To be clear, moving in this direction will break existing backup hacks (intentionally).

I would have to disagree?

Not implementing such a feature (someone has to do the work) or not being able to implement it due to technical limitation (ie keyStore) would be ok but suggesting it should not be implemented because there is some sort of "promise" is something else. I would argue its not freeOTP's "place" to be dictating to me what i can and cannot do with my own data on my own device.

There is nothing to stop me from importing the key into a dozen different devices while the QR code is displayed on my monitor, any service provider which needs a "something you have" guarantee would have to issue their own tamper resistant tokens to users (like many banks will offer, often using your bank card itself to store the secret).

---

I don't like the idea of syncing secrets between devices over the network, as it introduces a lot of risks that are difficult to address properly, but I can see why people would want it. If the keystore allows keys to be marked as exportable then freeotp would be able to display it as a QR code while still benefiting from its use

• I think this would cover some of the use cases people for anyone asking for key export/sync, with the caveat that they have to remember to do it manually for each new service
• I don't think this introduces any significant new risks?
• avoids any issues relating the to the security of the export file (by not having one)
• On devices with a HSM the keys being practically unexportable to most people (tamper resistant) will make little difference to the attacker, if they can unlock they keystore then they can use the secrets and if they can't unlock the keystore they can't export them anyway!

(I ended up here because I wanted to export my secrets before wiping my device)

[FSMaxB]

Most services provide backup codes, but sadly some don't! This means that you always need a way to backup the TOTP token for them.

But arguably you shouldn't rely on your phone not dying to not lose access to such kind of service, so you should back the token up outside of TOTP anyways.

Just wanted to throw this in there. One example of such an application would be TTRSS.

[sigio]

I recently had to reinitialize all my tokens, and then decides to just make screenshots off all the QR-codes, and store them somewhere safe (and encrypted) ... re-adding the keys to my phone and tablet was then just seconds of work... shooting al the QR-codes back into the new phone. Though I used the tokens.xml trick on a phone with a broken camera, beats having to type-over all the secrets :)

[noraj]

The more convenient way (workaround) is to backup the FreeOTP app (adb backup -f ~/android-org.fedorahosted.freeotp.adb org.fedorahosted.freeotp) and use freeotp-export to get the QR-codes or adb restore /location/of/android-org.fedorahosted.freeotp.adb on the new phone.

[g1y]

@npmccallum I am interested on working on a simple file export implemetation,

[ehuggett]

@g1y if you literally want to export to a file this might not be that helpful... when I was messing around with this I found Token.toString() but I never went beyond displaying the OTP string in an existing field that wasn't meant to contain it.

https://github.com/freeotp/freeotp-android/blob/0c6af8d639e6a6bbe259748c639a6b056598034c/app/src/main/java/org/fedorahosted/freeotp/Token.java#L270-L296

[f0o]

The more convenient way (workaround) is to backup the FreeOTP app (adb backup -f ~/android-org.fedorahosted.freeotp.adb org.fedorahosted.freeotp) and use freeotp-export to get the QR-codes or adb restore /location/of/android-org.fedorahosted.freeotp.adb on the new phone.

I tried this and also adb backup -apk -obb -noshared -all -nosystem but no luck at all... none of my settings have been restored after applying the backup.

I assume it is because I'm skipping a version? From Android 6 to 7. Any pointers?

EDIT: Worth to mention that the source phone is running an encrypted SD (sadly internal storage, not a real removable SD)

EDIT2: After extracting the backup locally I see that tokens.xml exists and has all the data. Why hasn't it been applied?

[ehuggett]

@f0o I don't know, but a workaround may be to restore it manually with adb root then adb push tokens.xml /path/on/device/to/tokens.xml (on my device that file resides at /data/data/org.fedorahosted.freeotp/shared_prefs/tokens.xml).

[noraj]

No offense but just to remember. This issue is a request asking for a backup/export feature not a question on how to manually export tokens. We are not trying to find counter measure or workaround.

[f0o]

@noraj1337 although you're right about hijacking this thread, however there should be a way to get the tokens.xml out of freeotp. And it seems like adb backup is the only current way.

@ehuggett Android 7 doesnt like adb root anymore. However after digging around a while while logcat it turns out that I had a newer version of freeotp installed on the new phone (thanks google) which on restore gave me a manifest check issue. After manually extracting the original apk from my old phone to the new one, the restore worked fine. This also applies to numerous other apps :|

[ehuggett]

k-9 uses OpenKeychain for PGP encrypt/decrypt, something similar might be a good approach for encrypting an export / decrypting an import of tokens.xml

• Supports USB & NFC smartcards https://www.openkeychain.org/faq/#nfc-security-tokens
• Would allow encrypting to multiple recipients / public keys (Very handy / essential for an encrypted backup)
• It would not be convenient for users who do not already have a PGP key
• Restoring could be awkward for users who do not wish to make their private key available to their phone/etc, but they could re-encrypt it (i.e. using gpg and a computer they trust) to a temporary key created just for the restore

I think this would solve all of the concerns about the security of the export file, once encrypted could safely be

• Written to 'External Storage'
• Copied over USB
• Sent by email
• Transmitted in Morse code by fog horn etc

Edit (19 days later): This backup issue came up a few times in the comments of an HN submission for FreeOTP https://news.ycombinator.com/item?id=15690957 today, Turns out this is one of the options andOTP supports for backup.

[KeenRivals]

In 5ced27208fc65999ee5a0103a452877dfb256247 it looks like they disabled backup via adb. 🤔

[MagicFab]

Check andOTP which includes backup functionality and a script to move your existing OTP data to it.

[hydrian]

I think being able to export and import the the associated seeds is an important feature. You can't always rely on backup codes being provided by sites. Even if the sites do, you can't completely rely on end-users having those codes either. Even if you printed the codes out or even screen captured / photographed the original QR code, if your residence suffers major destruction, such as flood or fire, you may not be able to get to those code.

This is why we need to look for some type of off-line export and import function. Have the user be able to export the seeds once they have provided some level of authentication. More than just opening the app such as fingerprint or device's passphrase. Then the data can be exported to some type of protected container. PKCS12 or using an external GPG application to do the encryption work to get the data to a movable file form. The importing and exporting should be a manual process.

For me, an 'cloud' sync is a show-stopper for me. It means I still don't control the my seeds and there is more liability for problems. Problems being 3rd party compromise, server outages, sync issues causing seed deletion...

[noraj]

@MagicFab Thanks, I moved to andOTP.

[noraj]

@hydrian Yeah allowing export only after an auth. It can also be exported a non-protected file if the user want to handle that himself (eg: store codes in a keepass or a veracrypt container). Of course cloud sync for that kind of secrets is a bad idea.

[hydrian]

@noraj1337 I don't think an unencrypted version should be ever be allowed. It allows bad habits. I use keepass2 also. I would still store a pkcs12 file in the kdbx file with the passphrase as the password field. That way even if the attached file gets exported, you still have to have the passphrase on the file.

[morriswinkler-simple]

It is as trivial as a screenshot, giving anyone the impression that the device is tied to the code is misleading. If you really need a backup make a screenshot and attach it to your login manager. But as stated it is not intended to be used like that. Still, it is not different from writing down a password.

[hydrian]

@morriswinkler-simplesurance That's assuming the device you are importing it to has a camera...

[morriswinkler-simple]

@hydrian well most of the time it is a QR code in your browser, you take your phone and scan it.

There are situations when that is not the case, but let's not talk about that one time, pls.

[KeenRivals]

The QR codes are encoded text. If you have a QR code you can convert it to its text form and enter the secret manually on the device(s) without a camera. Check out xanxys.net/totp/ for an example.

[hydrian]

@KeenRivals That's assuming I have a camera. I have android support on my Chromebook... not the easiest thing to do. I also do not see a way to import the raw QR code material. I just looked through the app and the only way I see to import is via a camera.

[deutrino]

I don't care about "promises," I care about usability. And having to set up 2FA all over again for every single account I have if I lose or replace my device is not usable. I also want a file based export option. If I wanted a "cloud" based option I could pick any one of 50 other apps.

The is the showstopper missing feature in this and nearly all other TOTP apps. I just paid $3 for Authenticator+ (closed source) before finding out about andOTP in this thread. Maybe I can get a refund.

[HarmlessDave]

I need export, and not to some cloud service that will be hacked. I can manage the security of my local files well enough, and when appropriate back up encrypted archives to my own remote storage.

[joao-paulo-c]

You can backup QR Codes or secrets you received at the very moment you just received them. Actually you probably should do that, because one day you will move to another device.

But this is equivalent of having an export functionality on you OTP, since it's up to you to decide where to store backup codes. Presumably would be on an encrypted file/media.

In my opinion, since you have to have backup somewhere (for instance, to move to a new device), one export feature would ease backup process while would have the bonus of keeping backup codes for a minimum time.

Once again, in my opinion, the best option would be to have the discipline of storing a secret (or QR code) as soon as you receive it on an encrypted media, but sometimes it's possible that you really haven't it (your encrypted media) at hand, and this could force you to backup to another media (not the one chose by you for backups) or even to an unsafe media. Again an export feature would be safer.

[alkuzad]

So for everyone digging in here looking for backup solution, some summary:

Due to initial bad design, FreeOTP allowed application data backup (opposite to Google Authenticator which disallows it for security reasons). Users used this backups to extract tokens to be backed up.

At some time 5ced27208fc65999ee5a0103a452877dfb256247 was merged, which disables backup of app. This kills all methods and tricks revealed in this thread.

So, as this app has nothing to offer more than other gazillions apps have, rather go for:

1. https://github.com/andOTP/andOTP - which has offline backups, it's free and open source.
2. https://authy.com/ - which offers limited (100 auths/month) free account and has cloud sync and backup
3. Authenticator Plus - one time cost app, has cloud backup (using your Dropbox or Google Drive)