Backups should be easy

[fortran77]

(Apologies for the duplication -- I posted this in the Litecoin issue tracker recently.)

Having tried many different virtual currency wallets, i'm finding that backups are messy and poorly designed. And I didn't see this issue discussed in the existing issues here, so below are a few ideas for consideration.

Backups should be easy and fail-safe.

At backup time, the user should need to neither type nor read and record any encryption key. People make typographical mistakes all the time, especially on a small smartphone screen. Instead, a predetermined public key should be used to encrypt the backup, similar to the way GPG encrypts messages. Later on, at restore time, the private key will be used to do the restore. This private key need not be known to the program creating the backup.

The backup file should include essential information in it name. E.g.: name of program, backup format, datestamp. So simply looking at the filename will tell us at restore time how to use the file. The person doing the restore might be a knowledgable friend, not the naive user doing the backup, so let's save them some trouble trying to guess where the backup came from.

In addition to saving to mass storage, also, wherever possible, send the backup by email in the background so the user doesn't have to think about it. This might be possible on most desktop machines. On an Android device, invoke the mail program with the destination address already filled in, so the user needs to only press Send.

If possible, Android apps should also save the backup in a place where it will automatically get backed up by Google's "Android Backup Service", ready for restore should the Android device go through a factory reset and/or be replaced by another.

[langerhans]

At backup time, the user should need to neither type nor read and record any encryption key. People make typographical mistakes all the time, especially on a small smartphone screen. Instead, a predetermined public key should be used to encrypt the backup, similar to the way GPG encrypts messages. Later on, at restore time, the private key will be used to do the restore. This private key need not be known to the program creating the backup.

And where do we get that private key from? If your phone gets erased completely, how do we restore that backup file afterwards? In contrary to ther Android wallets I implemented a second password field so that users have to enter their password twice, greatly reducing the risk of typos.

The backup file should include essential information in it name. E.g.: name of program, backup format, datestamp. So simply looking at the filename will tell us at restore time how to use the file. The person doing the restore might be a knowledgable friend, not the naive user doing the backup, so let's save them some trouble trying to guess where the backup came from.

Backup files are named "dogecoin-wallet-keys-YEAR-MONTH-DAY. Not enough?

In addition to saving to mass storage, also, wherever possible, send the backup by email in the background so the user doesn't have to think about it. This might be possible on most desktop machines. On an Android device, invoke the mail program with the destination address already filled in, so the user needs to only press Send.

The App asks the user to archive it afterwards. He clicks yes, selects mail, enters his address (how should I know it beforehand?) and hits "Send". Automatic send of private keys? Vie mail? Without the user knowing? Security nightmare ;)

If possible, Android apps should also save the backup in a place where it will automatically get backed up by Google's "Android Backup Service", ready for restore should the Android device go through a factory reset and/or be replaced by another.

I didn't test this yet, but I'd have security concerns with that too. I'll think about it.
Thanks for the suggestions, but did you even check this wallet for the changes you propose? ;D

[fortran77]

Thanks very much for the comments.

Re the question "And where do we get that private key from?", the user generates a private/public keypair just once, at the time he installs the Dogecoin client. He saves the private key somewhere outside the client in multiple places (maybe on a sheet of paper, maybe in an encrypted file on his desktop machine, etc.). The Dogecoin client only saves the public key.

When a backup is done, the Dogecoin client uses the saved public key to encrypt the backup. So backups can be effortless -- there is no need to type an encryption key each time a backup is done.

If/when the backup needs to be restored, the user retrieves the private key (from the sheet of paper, etc.) and supplies the Dogecoin client with both the private key and the backup file, and the client then decrypts the backup and restores it.

There are libraries available for the above (e.g.: Libgcrypt), though I don't know how hard they are to use and how compatible they are with the Android environment.

Re the backup filename, I currently have two Dogecoin clients: one on my Android mobile, and another one Dogecoin-qt on my desktop. It's not currently possible to tell from the filename "dogecoin-wallet-keys-YEAR-MONTH-DAY" which of those created a backup, as the filename is very generic . The backup files look different, so I'm assuming they are not compatible. Next year there might be 10 different clients, all of them correctly described as "Dogecoin wallets", and it will be even harder to tell where a backup came from, unless software authors either all agree on a common backup format, or agree on some filename conventions.

Re sending backups by email, it's not a security nightmare because they would be sent only if the user had already into the app settings and enabled "automatically send encrypted backups by email" and entered an email address.

And presumably the user would see a message such as "sending email...done" each time this happened, so he would not forget.

Since all backups ought to be encrypted, neither sending by email nor having Google do the auto-backup should cause any security issues.

One huge advantage of the above backup-by-email scheme is that a knowledgeable person could help a naive user set up the software, by generating the public/private keys, making sure the private key is safe, and setting up the email address. From then on the naive user has to make essentially no effort to make the backups occur. If we want virtual currencies to really succeed, even a relatively naive (or stupid, or lazy, etc.) person should be able to use a virtual currency wallet without risk of losing money if he loses his phone.

[langerhans]

Well, you intended to make backups more easy, but introduced another possible point of failure with giving the user a private key to store somewhere. People tend to remember their passwords, but they tend to loose sheets of paper and files on their desktop. How would we transfer the private key? A sufficiently secure private key is nothing the average user wants to write down. Sending it via mail or in the cloud is obviously not an option. From a usability standpoint this method is pretty bad. I bet that it makes more users say "Can't be arsed to do all that". You and me, we would probably do that, but I have 25k users out there, from which I guess a considerable amount is not that tech savyy to understand it. An alternative will be HD wallets. I hope that we can get support for them too.

Backup filename: I'll keep an eye on it. Probably very easy to change.

Automatic mails: Impossible. Why? Because I can't access the users mail app. Sending via an API in background is useless, as I'd need to provide a mail account to handle this. I don't want to have the user's privkeys. Encrypted or not.

[fortran77]

That's an excellent question: "How would we transfer the private key? A sufficiently secure private key is nothing the average user wants to write down."

First, let's remember that currently, after we do a backup with the Android client, if we want to protect ourselves against losing our smartphone, we must transfer the backup to some other location. Most people will either put it into a cloud-sync'd folder (e.g., Dropbox), or they will email it to themselves. They are effectively sending all their Dogecoin private keys (in encrypted form) into the cloud or by email. And they are doing it every time they make a backup, so they will get sloppy and use poorly-chosen passwords.

I am proposing, instead, that they transmit a single private key (used for encrypting subsequent backups) once, in encrypted form, at the time the Android app is installed. Since they will have to enter a password only once, we can convince them to do it more carefully.

Re emails, I think my original phrasing covers it: "In addition to saving to mass storage, also, wherever possible, send the backup by email in the background so the user doesn't have to think about it. This might be possible on most desktop machines. On an Android device, invoke the mail program with the destination address already filled in, so the user needs to only press Send."

[langerhans]

Basically you are proposing at least a part of the HD wallet specification ;) Which is great imho! Upstream bitcoinj is currently working on implementing them. So the user has his mnemonic private key, which we could also encrypt, yes, and the wallet is able to deterministically create the subsequent addresses and keys. I'll keep that here open and reconsider it, when there is upstream support incoming.

[fortran77]

I've been reading about deterministic wallets, and those will indeed simplify life for all, as one needs to make a backup just once.

However, I personally have found it convenient to have multiple wallets, and to import private keys among them.

So even if we begin with a deterministic wallet, it won't remain deterministic for very long. Then we will still also need a simplified backup mechanism such as the one I proposed.

Anyway, thanks very much for considering these ideas.