Backup without password

[Opening-Button-8988]

I briefly read this issue: #1786

It seems there is some confusion about the need for backups without encryption. First of all, I use LUKS encryption on my drives as a first line of defense and it's implemented on all of my drives. For this reason alone, a password is less useful for a drive already encrypted using LUKS.

The particular drive I want to backup to is not only LUKS encrypted but also hardware encrypted. It's a drive that has a keypad. Call me paranoid, but I like to encrypt using both hardware and software solutions for my most sensitive data.

I also use CryFS and VeraCrypt (I'm moving away from VeraCrypt). I have some directories further encrypted using these tools and again, there is less of a need to use a password for backups of these directories since they are already encrypted.

I think it's bad practice to require a password because restic is first and foremost a backup tool, and users should be able to backup without a password if they want to. It's really that simple, freedom. Forcing users to create a password for a repository that doesn't actually need one causes users to create passwords that they may not remember, something like "password123" which, from my experience, I tend to forget placeholder passwords more often than I forget more secure ones. A password manager is not a solution here. I don't want to have to use a password manager to store a weak password for something that doesn't need to be encrypted in the first place. It's inconvenient.

As for the problem regarding users inadvertently not using a password for data that needs one - this all comes down to how you implement it. There's a very simple fix for that. Add a warning saying "No password set. Are you sure?", and tell users that not setting a password is an option.

Forcing users to set a password will inevitably lead users to create weak passwords where no password is needed, and they may forget it because they were sure they wouldn't. It's happened to me more times than I care to admit.

I forgot to mention the whole reason why I posted this issue. The drive I'm trying to backup...is the drive that holds my password manager. In order to save a backup of my password manager, I need to create a new password database, with its own password, on a complete different drive, to save the restic password which decrypts the backup, which itself is encrypted anyway. Not sure what I'm gonna do about that except use a different program.

I'll also quickly mention the fact that some users may not trust restic's cryptography, and should have the option to use an encryption tool separately without having to rely on restic's encryption (and of course, not have to double-up on encryption when they don't want to).

[MichaelEischer]

Duplicate of #1786 (comment) .

I forgot to mention the whole reason why I posted this issue. The drive I'm trying to backup...is the drive that holds my password manager. In order to save a backup of my password manager, I need to create a new password database, with its own password, on a complete different drive, to save the restic password which decrypts the backup, which itself is encrypted anyway. Not sure what I'm gonna do about that except use a different program.

You're overcomplicating the whole setup. Just add a text file to the repository which contains the plaintext password. After all an empty password and a password stored in a plain text file provide the same level of security.

I'll also quickly mention the fact that some users may not trust restic's cryptography, and should have the option to use an encryption tool separately without having to rely on restic's encryption (and of course, not have to double-up on encryption when they don't want to).

Feel free to add another layer of encryption. But that's not a reason to complicate the encryption in restic.

[Opening-Button-8988]

an empty password and a password stored in a plain text file provide the same level of security

At significantly less convenience.

[rrrlasse]

I have decided not to use restric because it requires a password.

I once made an encrypted archive and wrote down the password on the backside of a piece of furniture. Some 14 years later I wanted to extract it but couldn't even remember what furniture I used, or if I still owned it.

With the --password-file flag the same problem exists, just with a file, which isn't better.

For my particular use case, encryption has zero value.

[Opening-Button-8988]

@rrrlasse while your issue simply comes down to user error (also, 0.1.0 was released on 2015, which is 8 years ago...), I can understand your pain.

I have since discovered that rsync comes built-in with Fedora. Not only did I think you had to download it, but didn't realise it could be used to simply copy files to and from local disks, like a glorified cp command. So I use rsync instead of restic now, where encryption is not needed. Because I use LUKS, that additional layer of encryption is not necessary. Even if restic had support for no encryption, I have a feeling rsync would be faster / less overhead anyway. Pretty sure restic even uses rsync as its backend anyway. Despite this, forcing encryption is still a stubborn approach considering it's a backup tool, not an encryption tool.

In case it isn't yet clear to the devs: Restic is a backup tool. I already use encryption, either LUKS or cryfs or veracrypt. Being forced to encrypt my backups is simply inconvenient and provides no additional security, instead increasing the chance of losing data. Even so, I would rather trust other tools to encrypt my data. @MichaelEischer

[MichaelEischer]

Restic is a backup tool. I already use encryption, either LUKS or cryfs or veracrypt.

restic is designed to back up to cloud storage. For those it is not (really) optional to encrypt the backup data.

[yushiyangk]

You're overcomplicating the whole setup. Just add a text file to the repository which contains the plaintext password. After all an empty password and a password stored in a plain text file provide the same level of security.

At that point, why not just add an option to disable the password? Why jump through so many mental hoops to justify making password mandatory?

Make password required by the default, sure, but a simple flag to provide the option to disable it would solve so much problems for so many people.

restic is designed to back up to cloud storage. For those it is not (really) optional to encrypt the backup data.

Not all data is sensitive data. I'm backing up publicly available census data that has been slightly transformed, because it would be inconvenient to have to regenerate it.

[rrrlasse]

Regarding the idea to "just use a password file", here's the problem:

1. User creates some backups, perhaps automated
2. Two years later the user needs to restore it
3. User thinks "I am certain I did not use a password for this backup, because it's not secret data. But restic keeps asking for one when I try to restore it?!"
4. User googles how to disable encryption when restoring
5. User finds out he had had to use a password because it was mandatory
6. User thinks "Hmm, did I use '123', 'abc', '1234', 'empty', 'dummy', 'none', ' ', 'abc123' or what?

The user not only forgot that he had used a password. He also forgot that restic even supported the "--password-file" flag.

I'm also a software developer, and we need to try and see things as the users do, who don't have the product on their mind every day.

If you have decided not to change it due to policy, then that's fine - I didn't write this comment as an attemt to convince you. I just wanted to mention a common problem in software development.

[Opening-Button-8988]

All good points here. A password file may provide the same level of security at much less convenience. Users who backup to cloud storage may not necessarily want their backups to be encrypted. Those who are required to encrypt their non-sensitive data will be required to use a password, they will probably use an easy to remember password that isn't so easy to remember, and when restoring, they'll forget what it was, because writing down "password" or "abc123" would be a waste of time.

Rsync has been working well for me and its faster, big difference is that it doesn't write millions of files which is a plus. Honestly, I feel like using rsync to backup, then using something like cryfs to encrypt, would be a faster and more secure workflow. As long as restic mandates passwords, it's a tool that doesn't do backup or encryption as well as other tools that do those things separately.

[rrrlasse]

@Opening-Button-8988 yeah, I like the UNIX mentality with "one good tool for each job". I.e. one tool for encryption, one for backup, one for compression. You can then combine them as you wish, and developers don't need to reinvent the wheel.

[MichaelEischer]

Allowing backups with no password / a default password and removing encryption are very different beasts.

For the former a --unsafe-no-password or --use-empty-password option might be an acceptable approach. However, it will be necessary to always specify that option for a repository with no password; specifying that option will result in an error if a password is passed to restic. Otherwise it's just too easy to accidentally end up with an unencrypted repository. Automatically checking whether a repository uses an empty password before even asking for a password is also not possible as this will create security issues. That is, instead of specifying a password, one would always have to pass the no password option to restic.

An empty password does not remove the encryption of the files in the repository. Removing encryption would require changes to the repository code that risk degrading security for encrypted repositories and thus won't happen.

I like the UNIX mentality with "one good tool for each job". I.e. one tool for encryption, one for backup, one for compression.

That would result in several severe problems when applied to restic. Restic requires random access to pack files such that an external compression would either result in compressing far too much data or inefficient compression. And taking cryptfs as an example: from what I could find it only provides encryption but no integrity checks. Like with compression, integrating encryption into the repository format allows restic to decrypt and integrity check just the relevant parts.

[Opening-Button-8988]

@MichaelEischer

For the former a...

Maybe I'm misunderstanding you but I can only imagine the --use-empty-password option to be useful only when creating repositories. That's the only time it makes sense. If I want to remove the password to a repo, I'll just make a new repo without a password. All those other issues you mentioned aren't relevant. "Automatically checking whether a repository uses an empty password before even asking for a password" would only be relevant for repos that already exist.

An empty password does not remove the encryption of the files in the repository. Removing encryption would require changes to the repository code that risk degrading security for encrypted repositories and thus won't happen.

Two thoughts come to mind, keeping in mind that I'm not a programmer:

1. create new code so that code for encrypted repositories are not affected
2. convert an empty password to some arbitrary, static value that only restic needs to know and not the user.

And taking cryptfs as an example: from what I could find it only provides encryption but no integrity checks. Like with compression, integrating encryption into the repository format allows restic to decrypt and integrity check just the relevant parts.

Cryfs does check for integrity violations, though I don't know if it's of the same kind that restic checks for.

[rrrlasse]

For the former a --unsafe-no-password or --use-empty-password option might be an acceptable approach.

That would be perfect, at least for my use case. It's fine that you need to always specify it, and I don't mind whatever encryption it does "under the hood".

In principle (wouldn't recommend it, it's just for illutration), a solution could even be to just state "Please use '1234' if you just want to use a as a dummy password" in the usage legend. It's only the "need to have knowlege about something" which is problematic.

[Opening-Button-8988]

That'd work, really. Just add that to the documentation, and to the CLI docs. Would at least be a temporary solution.

[ProactiveServices]

As someone for whom the encryption and data integrity is of paramount importance, I would prefer that not a single line of code is added or removed which has the intention of removing or weakening either encryption or integrity.

People here are asking for a trade-off: weakened encryption and integrity for everyone for the benefit of their convenience. It would be my argument that anyone who does not want to remember the password simply keeps it password in a file alongside, or inside the repository. If a user cannot keep their repository directory, or its parent, safe, then they cannot keep their backup safe anyway.

[yushiyangk]

Making encryption optional but enabled by default absolutely does not "weaken encryption or integrity".

Really that should not be difficult to understand.

[MichaelEischer]

Maybe I'm misunderstanding you but I can only imagine the --use-empty-password option to be useful only when creating repositories. That's the only time it makes sense. If I want to remove the password to a repo, I'll just make a new repo without a password. All those other issues you mentioned aren't relevant. "Automatically checking whether a repository uses an empty password before even asking for a password" would only be relevant for repos that already exist.

Handling an empty password without requiring the --use-empty-password option for existing repositories is somewhat tricky. Restic would still have to prompt the user for the password or read it from the environment variable (I wonder whether everyone is aware about the difference between an environment variable with an empty value and an unset one). Opening a repository first, then checking whether it has an empty password and only afterwards falling back to prompting for a password would introduce a security vulnerability for repositories with real passwords. Thus, we can never have autodetection of empty passwords.

To prevent any chance of misuse I'd prefer to make the choice of an empty password explicit by always requiring the user to specify --use-empty-password.

Making encryption optional but enabled by default absolutely does not "weaken encryption or integrity".

We have no intention of providing an option to remove the encryption. What we're discussing here is allowing for an empty / a default password.

[Opening-Button-8988]

Making encryption optional but enabled by default absolutely does not "weaken encryption or integrity".
Really that should not be difficult to understand.

Exactly what I'm thinking (even though we're not discussing removing encryption, but rather, passwordless repos).

Handling an empty password without requiring the --use-empty-password option for existing repositories is somewhat tricky.

Again, maybe I'm misunderstanding you, but why would you need to handle an empty password when the --use-empty-password option is passed? You would reject it in the same way it does now. It's only when that option is passed, that you would then use an empty password. Otherwise you're suggesting accepting an empty password without passing that option, which could lead to misuse as you yourself have said.

I'm referring here upon creation of repositories. If you're suggesting that you cannot do this without introducing a vulnerability in the opening of pre-existing repositories, because (and I'm thinking out loud here) that you would need to check whether a repository has an empty password or not, I have nothing to add since I'm not a programmer, just that it would be unfortunate.

Another idea from a layman: when opening repos, it always asks for a password. But it will accept an empty password, as long as the empty password has a unique hash value that can be matched against the repository. This would probably mean that empty passwords have some known static value that can be hashed. I could be talking out of my ass here, just an idea.

@MichaelEischer I just like to say thank you, for pursuing this line of discussion and being open to the idea at least.

[doak]

I am wondering if the "no password" use case would be fulfilled if an empty password was allowed. Hence, restic still asks for a password every time (if not provided by RESTIC_PASSWORD_FILE=/dev/null). @Opening-Button-8988?
In this case only init and key would require --unsafe-no-password, wouldn't it @MichaelEischer?
[Edit: I see, every other commands also bails out with "Fatal: an empty password is not a password. Try again" …]

There is imho no way to get an unencrypted backup by accident this way. On the contrary, you are reminded every time. ;)
Btw, I love the design decisions of this project. They seem well thought through.

[MichaelEischer]

For init / key I'd like to see the following behavior:

password	--insecure-empty-password	result
empty	not set	error
password	not set	ok
empty	set	ok
password	set	error

--insecure-empty-password would just invert the "no empty password check" to instead check that the password is actually empty.

The last case prevents unconditionally passing --insecure-empty-password just because it is easier. An empty password should be a conscious decision that has to be made beforehand. (We should show helpful error messages though). It also prevents accidentally setting an empty password due to e.g. some broken environment variables.

For other commands, I wouldn't mind if they also use the same logic as the init command. Although, I have to admit that the risk for those commands is a lot lower. The only scenario that could break is if your automation breaks such that RESTIC_PASSWORD is suddenly empty, and someone replaces the repository with one with an empty password at the same time. That should be an obscure enough scenario that it is not relevant.

(An option like --use-empty-password that automatically sets an empty password (without asking for a passsword) might also be an option. Although, we'd have to add some further restrictions to make sure that contradicting uses like passing RESTIC_PASSWORD=password and --use-empty-password at the same would result in an error. As such that variant is probably to messy to allow safe usage)

[doak]

The last case prevents unconditionally passing --insecure-empty-password just because it is easier.

Good point.
How do you like the nagging warning if an empty password is entered interactively?
I guess you are fine that there is still a second prompt to repeat the empty password when setting it.

I'm looking forward to feedback from @Opening-Button-8988.

[MichaelEischer]

After a lengthy discussion with @rawtaz and @fd0 we've decided on the following variant:

The option is called --insecure-no-password. For a repository with an empty password, the option must always be specified both for creating the repository and using it later on. When setting the option, there will be no password prompt. Instead, the password is set to an empty string.

If any other --password option or the corresponding environment variables are set together with --insecure-no-password, then that is an error. Simultaneously specifying a password and no password is contradictory, so restic must treat that as invalid CLI flags.

If a user does not specify --insecure-no-password but enters an empty password, then the error message suggests to specify --insecure-no-password instead.

That variant has the benefit of cleanly distinguishing between the with password and without password cases. It also gets rid of the redundant password prompt in the no password case.

[MichaelEischer]

How do you like the nagging warning if an empty password is entered interactively?

With the semantics described in my last comment, such a nagging warning won't be necessary.

[Opening-Button-8988]

@MichaelEischer @doak

I have nothing to add except 👍

It's interesting to read a programmer lay out what needs to be done, because that table is what I had in my head but was not able to visualise it as such. I know what functionality I want to see, but I don't necessarily know how it should be implemented. Based on what I've read it looks pretty intuitive to me. I also haven't used restic enough to identify problem points.

[aktaboot]

I guess #1018 could be closed aswell