Custom password before allowing "Export"

[corobin]

Android app.

Is your feature request related to a problem? Please describe.
The current workflow for exporting saved data is this:

1. go to settings
2. select "export codes"
3. choose encrypted or plaintext
4. (if select encrypted, set encryption password)
5. authenticate with device credentials - ! this is the step this feature request is about
6. success

while this is very good and far far superior than no authentication at all, i feel like this can be stronger

Describe the solution you'd like
an option to set a custom key/password before:

1. an export is allowed
2. related to the concern in question 2 in Questions - clarification about security (storage on device, sign in after use) #337 this can also be used as a gate before allowing log in to an account
3. revealing an entry's QR code

this is different from setting an encryption password (step 3 above) since that is a password to access the backup

what i am proposing is a custom password to allow anything being exported at all

this can be either in addition to device credentials (current step 4), or in place of it.

the reason this can be stronger than the current workflow is that a user can set a much stronger custom password than the device lock password/pin/pattern/biometrics since it is used very rarely

also, the device credentials needs to be used to open the app in the first place (to unlock phone, and also to unlock the app if the app lock option is enabled), providing opportunities for peeping close-in-time to triggering an export. a separate/additional password that is rarely used provides a much stronger protection against exfiltration of the secrets.

so, the proposed additional option in settings would be:

• set a custom password to protect data saved on the device

and if it has been set, the proposed workflow would be:

1. open app
2. (if app lock is enabled - authenticate with device credentials)
3. go to settings
4. select "export codes"
5. (authenticate with device credentials - tbh i think if a custom password is set, the value of also prompting for device credentials at this step is minimal - but device credentials should still continue to be used for the app lock option i.e. when opening the app)
6. authenticate with the custom password
7. choose encrypted or plaintext
8. (if encrypted - set backup file password)
9. success

and if this is also implemented as a gate to login, the workflow would be:

1. go to settings
2. select "sign in to backup your codes"
3. authenticate with the custom password
4. the rest of the sign in flow

for QR code:

1. swipe on an entry
2. click "QR" button
3. authenticate with custom password
4. success

Describe alternatives you've considered
In terms of exporting data, FreeOTP does it this way:

1. on first launch of app for the first time, prompts for a backup password that cannot be changed later
2. this password is used for any backups - there are no further password prompts

this achieves that: any backups will not be accessible unless you have the original password first set in the 1st place.

pro: slightly less friction for UX

con: no way to change it once set other than resetting the app entirely and starting over

there can be a way to do it this way while still allowing securely changing the password later: the old password must be required in order to change it. cannot simply set a new one without inputting the current one.

Additional context
I like that the app uses android's device credentials and there are security benefits to that, so i would like that to stay.

e.g. if every app uses android device credentials, only 1 pin needs to be changed to update all of them, whereas app-specific pins may never be changed at all.

however, in the context of exfiltration of TOTP data, a custom and rarely used password just for the exporting or syncing of data offers security advantages, because it only needs to be used rarely:

• few opportunities for leaking/peeking at the PIN since it is not frequently inputted like the device credential is
• also can be used only in private spaces - device credential may be used outside in non-ideal conditions far more frequently
• it can be set way stronger than an often used PIN

the app lock "Lockscreen" option that prompts for device credentials upon opening the app should still use the device credentials since it is used every time the app is opened

the custom password should be used any time anything other than the current one time code can be exfiltrated from the device.

[corobin]

just to add some additional context, I just saw this: https://www.twilio.com/blog/august-2022-social-engineering-attack

Authy's model leans heavily into syncing TOTP secrets across devices. They had user accounts compromised through an attack on the company which allowed registering additional unauthorized devices.

In addition, to date, our investigation has identified that the malicious actors gained access to the accounts of 93 individual Authy users - out of a total of approximately 75 million users - and registered additional devices to their accounts. We have since identified and removed unauthorized devices from these Authy accounts. Twilio purchased Authy in 2015 and various elements of Twilio’s platform support the functionality of Authy.

the fact that they try to minimize it by saying it "only" affected 93 users is a distraction. the fact that it happened at all is a demonstration of the security flaw.

this is a live demonstration of the use-case for having stronger controls before TOTP secrets can be exfiltrated off of a device by any means