B2 application key is written to an unencrypted file

[fjarlq]

After running b2 authorize-account, my B2 application key is stored unencrypted in the sqlite3 database $HOME/.b2_account_info. This file is readable by the user ID that runs b2 authorize-account, so any other program I run as that user, or as root, can read this file.

Correct me if I'm wrong, but I believe this means that if this user ID accidentally runs ransomware, the ransomware could use the plaintext information in $HOME/.b2_account_info to delete all the files in my B2 buckets. And ransomware would want to do that, because B2 buckets are often where backups are stored.

Therefore I'd prefer to store my B2 application key more securely. For example, if I could write a wrapper script for b2 that reads my application key from an encrypted file and then exports its value to $B2_APPLICATION_KEY to perform the desired b2 command, I would do that. (I think such a feature would help address issue #597 more naturally.)

But it seems that I cannot do something like that, because b2 requires that I first run b2 authorize-account, which writes my application key to an insecure file to be used by subsequent b2 command invocations.

Or have I overlooked an alternative method of b2 authorization?

[ppolewicz]

Please observe that if the user is compromised, they can modify .bashrc to enable searching for binaries in ~/bin/ (if it is not enabled yet) and upload their own ~/bin/b2 which will steal whatever you pass into b2 authorize-account. It requires just a tiny little bit more patience.

The proper fix for this is to use an application key which only has permissions to write data and does not have permissions to actually delete anything. Ramsomware could try to pollute the bucket with dummy data, but it could be filtered via uploadTimestamp and as long as the retention policy is set correctly, a restore is possible.

[fjarlq]

That's reasonable, thanks. You're right, since I'm already imagining a particularly clever breed of ransomware, I may as well imagine an even more clever breed.

My backup utility, restic, needs delete capability to prune old snapshots. That must be a common need of backup utilities. But restic doesn't need delete capability to perform routine backups -- snapshot pruning is a separate operation. I could do the snapshot pruning from a different system with a different B2 application key that has delete capability. That would be a dangerous key to leave lying around, of course. Is there a better way to manage this risk?

[ppolewicz]

You can configure server-side retention policies which will take care of deletion for you, see here. Then you don't need any keys with deletion capability at all.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate or assist you further.