Custom encrypted backups via the Files API

[xijio]

Maybe I'm missing something, but aren't I completely hosed if I lose my phone? I feel like there should be some sort of secure recovery process. If there already is one, I'd love to hear about it but I couldn't find it in the documentation (aka the FAQ and readme.md, couldn't find more documentation).

[xijio]

I made another comment here, not sure if you want to track this in that issue or as a new issue. https://github.com/calleerlandsson/Tofu/issues/16#issuecomment-555726548

The big things I'd want in this feature:

1. Encrypted backup and restore. The app would ask for a password when backing up data that would need to be entered upon restore
2. Store backups using iOS files API. This way you could sync to icloud, dropbox, nextcloud etc, or just save it to your device. Nextcloud supports these APIs which is how I'd want to securely store my backup https://nextcloud.com/blog/nextcloud-releases-deep-ios-integration/
3. Automatic backups. Anytime the settings change, automatically backup. I'd be fine with just appending datetimes. Eg "xijio-backup-Nov-19-21:49:24-UTC-2019.tofu". This would ensure even if I botch my config by deleting things I didn't mean to I can quickly recover from an older backup before I broke things.

[calleluks]

Let's track this issue here and keep #16 about the iCloud backups issue.

[eutampieri]

I was trying to implement this in my newborn fork but I have two questions:

1. The Apple CryptoKit API is available for iOS >= 13, so could we use this library?

2. I can't find a valid place in the UI to place the export button

[calleluks]

Wow, thanks for trying to implement this @eutampieri!

It would be great if we could make this compatible with iOS versions < 13 as well. Do you think we could use the CommonCrypto library for this? If so, I think I'd prefer that over adding a dependency. If not, we could also make this specific feature iOS >= 13 only.

Regarding where to put the export button: Maybe we could replace the + button when the accounts view controller is in edit mode?

[eutampieri]

Haha implementing because my mum needs it! I'll look up CommonCrypto. For the UI, I think I'll write the necessary code first.

[frozenshadow]

Maybe you could look at the share/export implementation in the default notes app. I think it will be unclear if the button is only shown in edit mode (you perform edit related stuff). The notes app has a "more" icon for this task.

[eutampieri]

[{"password":{"timeBased":true,"counter":0,"digits":6,"algorithm":"sha1","period":30,"secret":"EVSUnOcwQhA="},"persistentRef":"Z2VucAAAAAAAAAnI","name":"fns"}]

Here is an example JSON output

[eutampieri]

I'm trying to encrypt but my test is failing...

[eutampieri]

As per #38, we could put a menu in the UI to export the keychain

[eutampieri]

https://github.com/eutampieri/Tofu/commit/4278ee3b34b9bc4f7eb7abc757a250b4bd4b2a2e#diff-b1acf593e236b5dfd4921d5fa0b8405b I have pushed into my repo, but I can't figure out what's wrong with my encryption.

[ThinkChaos]

I have a fix locally, I'll make a PR on your repo @eutampieri 😃

[eutampieri]

I have a proof of concept (only export via file, import not implemented yet) @calleerlandsson could you please check if the UI is ok? I think it wastes a lot of space but I don't know what could be done to it. Also,

• [ ] Share icon appears only on iOS >=13
• [ ] Cannot dismiss export pane on iOS < 13

[eutampieri]

@xijio at the moment automatic backups is not gonna happen though

[calleluks]

Hey @eutampieri, feel free to open a PR and I'll take a look at it when I have some time over!

Responding to #38, I realized that the same potential security risk also applies to this feature: that someone with brief access to the device could export and upload the secrets to somewhere they can access later.

I think I might want to do some more research into how other 2FA apps handle this before considering to merge this feature. I'm sorry I hadn't made that connection earlier.

It's important to remember that 2FA smartphone apps are convenient replacements for physical MFA devices for which there are no backup or export options. The hard question is how to balance convenience and security.

[eutampieri]

@calleerlandsson the feature is not ready, I would have to handle the import of backup files. I think it's useful to have an export feature, for example if you want to switch to another app. This would mean of course to create a backup file viewer or another piece of softwar that creates multiple otp qr codes. Of course, this is a security risk and the user should be warned of it. Moreover, you could enable export only if the user has enabled biometric authentication, to make harder for other people to steal the backup.

Question: the persistent identifier can be regenerated during import? Because I think it has to be done.

[eutampieri]

Also, I've implemented qr code export, which is the data I would put into a file base64 encoded and pretended with a tofu:// prefix, so a handler could be added to enable quick sync between devices. We shall consider the security risks this feature poses. I remember there was an issue some time ago regarding TouchID/FaceID implementation that was deemed unnecessary for some reason I can't remember.

[ThinkChaos]

I think one way we can make this safe enough is to have the user set a password once, and use that to derive a key for encryption. To make this secure the password should NOT be recoverable from Tofu's UI though. @calleerlandsson do you think this would be an acceptable trade-off?

[calleluks]

@eutampieri, I definitely do see the utility of this feature. What I'm worried about are the security implications.

Regarding the persistent identifiers: these are provided by Keychain Services to uniquely identify an account stored in the keychain and are used to store the order of the accounts list in the user defaults. I don't think these should be part of backups. Instead we could order the accounts in the backup according to the order stored in user defaults.

@ThinkChaos, that is definitely an option. I'm not sure what it provides in terms of security over using the built in pass code or Touch/Face ID, though? This password would practically have to be stored in a password manager that would potentially be protected with Touch or Face ID.

I'm grateful for the time you've spent exploring this feature but please don't spend more time on it before I've had some time to think this over unless you really want to.

[eutampieri]

Ok, I'll keep up with this issue then! Have a good week!

[ThinkChaos]

I was going off of not having Touch/Face ID at all. If the app is protected that way it would be acceptable to have one authentication at app launch, and another at export. Though it is important to note biometrics are not a proper replacement for passwords because they can always be faked/taken from you whereas a password cannot. But that's a trade-off I am personally comfortable with for my 2FA as my primary passwords are protected by a password manager locked with a password.

I think it would be useful to write down a threat model for Tofu so that each feature can be analyzed with it in mind. Maybe that could be discussed in another issue.

[lukefor]

I'm not sure integrated backups are the correct approach - Apple has solved backing up keychain data nicely, and it is my understanding that Tofu is already backed up by an encrypted iTunes backup (please correct me if I'm wrong!)

What I would like to see is a means of avoiding lock-in, perhaps by displaying QR codes for all pairs. I've been burnt before by TOTP apps that are overly-sandboxed and therefore difficult to switch away from when they become abandonware. On the other hand I was able to move effortlessly from andOTP to Tofu by exporting QR code images and scanning them.

[eutampieri]

Your comment catches the spirit of the issue and I think it's a quite nice solution too. However my work can be safely discarded then

[9R2by]

@lukefor please refer to issue #16

[166MMX]

I can think of one scenario that could work out.

To resolve the trust issue when either displaying OTP QR codes or creating a custom encrypted backup via Files API, Tofu needs to be able to authenticate the user whether the user is the one initially installing Tofu or some random dude that I have lend my unlocked phone.

Tofu should be able to know if it has been started for the first time. It should then educate the user about the trust issue we solve and why he needs to setup a "master/admin" password for Tofu. This step can be optional but the user should be warned that he can not set a "master/admin" password after the initial setup has finished due to trust issue we have. The password should be able to be changed though as long one has been provided initially.

When the user chooses to not set a password he will not be able to gain access to the backup/export functionality and can only set a password by fully uninstalling Tofu and starting from scratch on that device. So that the initial setup screen shows up again.

The setup screen should not be shown when restoring from a backup though.

[166MMX]

On a second thought you could force the user to secure a secret key that is generated by Tofu during initial setup. After the user has secured the secret key he will be asked in a new view to verify the secret key. Once the user has been able to provide the correct secret key he may continue to use the app.

The secret key then would be used for export and backup features.

You could also mix and mash my suggestions together and let the user choose a password of his own, have a password(secret key) been generated for him or opt out of it with an additional warning.

Asking the user on a second screen to verify the provided password/generated secret key is annoying but proofs that it has been secured and noted correctly before its activated.

[eutampieri]

Now that the app is iOS 13 and above we could use Apple's crypto library, even though iirc @calleluks thinks it’s got big security implications. Maybe we could just ask the user for his/her passcode/TouchID/FaceID and then export the codes

[justablob]

I agree with @eutampieri. I'm just looking for a quick and easy way to export my 2FA codes to back them up somewhere and to me, it sounds like FaceID would be enough to make sure it's not some malicious actor exporting the codes. It's the easiest solution and doesn't reinvent the wheel.

[Shadowspear123]

Has any progress been made on this issue? Encrypted local backups would be a great convenience feature. An open-source 2FA app that implements this nicely is Raivo (https://github.com/raivo-otp/ios-application).