Mnemonic Phrase for Backups

[indolering]

TL;DR: The best trade-off between security and usability for off-device backups is a setup workflow/wizard that instructs the user to write down or print off the encryption key. This is what many online services do when activating 2FA and how most cryptocurrency wallets operate.

---

TOTP apps, password managers, and crypto-currency wallets are all domain-specific secrets managers. The security model is fundamentally identical, their value comes in isolating failure: Aegis on your phone hedges against a XSS attack against your password manager's browser extension.

TOTP managers tie a device to an account, protected by the pin/pattern/biometrics of the phone. The average pin/pattern has ~14 bits of entropy and can only be meaningfully protected by hardware which limits brute force attempts. A strong KDF will deter casual attackers and are necessary because hardware security modules are usually buggy propriety blobs which are regularly tricked into going over their limit.

For most users, off-device transfer of TOTP secrets (via device syncing, cloud backups, and vault exports) represent a violation of the isolation between secret managers. A separate password for backups would only bump the entropy level to ~30 bits; any "good passwords" higher than that are prone to being forgotten or fat fingered.

A better solution is to just store an offline copy of the full secret, possibly with mnemonic and QR encodings.

[alexbakker]

In summary, you'd like the encryption key for backups to be separate (see: #121) and have Aegis offer the user to generate a mnemonic phrase for them. Is that correct?

[indolering]

In summary, you'd like the encryption key for backups to be separate (see: #121)

Sorta. My advice as a UX engineer would be remove the ability to set a password on backups that aren't backed by a HSM that can limit brute force attempts, as it's error prone and grossly insecure. If you must encrypt the private key with a password, bury that shit in some advanced settings. I have forgotten/fat fingered encryption passwords and personally know multiple people who lost large sums of money.

and have Aegis offer the user to generate a mnemonic phrase for them. Is that correct?

Mnemonic encodings are fine, but the most popular implementation (BIP39) is problematic. A QR code is less error prone, but make sure the paper backup includes the raw digits as well.

Have you investigated reusing code from an existing cryptocurrency wallet?

[alexbakker]

I'm fine with offering users the option to generate a secure backup passphrase for them, but removing the ability to set a custom password is not an option. I'm afraid users would just do away with encryption altogether and manually create plain text backups instead as a result of that.

Have you investigated reusing code from an existing cryptocurrency wallet?

What, specifically, would you suggest we reuse from the code of a cryptocurrency wallet? The BIP39 implementation?

[indolering]

I'm afraid users would just do away with encryption altogether and manually create plain text backups instead as a result of that.

And whyyyyyy would you let them do that?

99% of users will just rely on Google's backup service, which actually can resist brute force attacks. People rolling their own DiY backup system can't be trusted not to screw it up; forcing them to pass the encryption key through meat space is a good thing. If they are syncing between devices, they can just scan a QR code.

I wanted to get a PhD on this topic at one point, so just trust me when I say that relying on password based encryption is a bad idea. NN-based password cracking is very good at draining entropy from passwords, especially when combined with the huuuuuge password data leaks out there.

The problem with "good" passwords is that people forget them or screw them up during input. People at early crypto-currency meetings (myself included) did this all the time. I've tried to devise algorithms so that my paper password backups aren't trivially easy to decode, and I inexplicably will make the same systematic mistakes during conversion. After setting up a new offline machine, I literally walk away for a week before I do any serious work on it.

What, specifically, would you suggest we reuse from the code of a cryptocurrency wallet? The BIP39 implementation?

Yeah, but now that I think about it BitWarden's code base would be a better starting point for a 2FA app. It has ports to everything and has received a code audit....

[indolering]

Lost my XRP phrase

I have also lost backup keys, mainly because I setup an overly complicated systems to protect them. This proposal still allows for backups to Google's HSM protected backup service, which uses the phone's pin (and maybe the user's Google password?) to protect the data.

[NumbGnat]

Reading this discussion, has me intrigued. Although I comprehend most of what is discussed here, it seems @indolering has far more security related experience than I do.

I find myself wondering about my own choice for backup security. I use a randomly generated string (32-64 characters) from an offline password manager, for my backup password. I don't have many concerns about forgetting the password that way. Is this complex enough?

I do understand both sides of the password issue though. @alexbakker is correct, that if it's too difficult, users will just choose another backup method. I think @indolering concerns are worth discussing, in order to help guide Aegis users to use the best practices, if at all possible.

Perhaps the app should automatically provide a mnemonic phrase, but allow the user to edit the value, if they so choose. Many users are likely to use the default provided, so you'd be helping them be more secure, with the power of suggestion and also giving them an idea of what their passcode should be like, if they choose to edit it manually.

[indolering]

Perhaps the app should automatically provide a mnemonic phrase, but allow the user to edit the value, if they so choose. Many users are likely to use the default provided, so you'd be helping them be more secure, with the power of suggestion and also giving them an idea of what their passcode should be like, if they choose to edit it manually.

Mnemonic phrase backups have redundancy, so that you can screw up a bit when transcribing the code but still recover the password. Specific words are chosen so that (among other things) spelling correction can be applied. They also generally employ an error recovery scheme, so that even if you totally screw up 3 of the words you can still recover the encryption key.

Allowing a user to edit them would break the algorithm that transforms the input from those words into the encryption key.

[unknow883]

Just to pile on here as a lay user..... I think somehow the backup should be encrypted more robustly & with more effort to un-encrypt than to view codes in daily usage.... so perhaps once a longer-stronger password is input into the phone it can save a session for some length of time or until some event (device off) and in the meantime be unlocked with a shorter pin code. Alternately maybe with biometrics plus a short pin code. I am sensitive to someone trying to get my fingerprints when I am not conscious of it but maybe thats paranoia. Authy seems to achieve this by having a long backup/restore password but a simple pin to protect viewing the codes. I think Signal works much the same way.

[kusyka911]

any "good passwords" higher than that are prone to being forgotten or fat fingered.

I disagree. If you're using an app like Aegis, which is open source and stores TOTP vaults without cloud syncing, you’re likely an advanced user who already knows how to create and manage strong passwords. Thus, I don't think this feature will see high demand. However, I do agree that for those with limited digital skills, it's better to have them write down a seed on paper rather than allowing them to set a weak password. But, in general, many of these users probably aren't using TOTP-based two-factor authentication at all.