Restic: Allow empty passwords

Restic should allow empty passwords.

Can you elaborate what your use case is? Why should restic allow empty passwords?

it is a design decision.

Indeed, it is. But I'm curious what you're trying to achieve.

A related issue is maybe #1018

I just wanted to backup some directories temporarily on my local system as a quick safety net when changing files in a directory. I did not want to remember a passphrase or be bothered to enter a passphrase everytime I want to create a backup. Since I just used a as a password, there is no real security benefit in using this password compared to not using a password at all. Therefore any low overhead to remember or enter a useless password make the tool less perfect.

Thanks for the explanation. I'd like to keep this check in place, so I'm closing this issue for now. Please feel free to add further comments. Thanks!

When we talked about this a while ago you said there would be a discussion...
Can you maybe explain why you consider this check to be useful? The repository should still be encrypted so that a password could be added afterwards.

I consider this check useful because in my experience, most users will want to set a password. Accepting an empty password, or even having a code path that allows accepting empty passwords, may lead to users accidentally saving their backups to remote locations without proper encryption. One situation where this may happen is when the environment variable RESTIC_PASSWORD is not exported or set to the empty string accidentally.

So, in this case, it feels to me that protecting users from a mistake is better than removing the minor inconvenience of having to set a password :)

There are easy workarounds for this though: Use a password manager, use the string test, export RESTIC_PASSWORD statically via a file e.g. in /etc/profile.d, use the name of the directory you're saving (or the repository) as the password...

Please note that knowledge of your password is required to access the repository.
Losing your password means that your data is irrecoverably lost.

How could I prevent this happen if I don't want to losing my data forever?

@LexSong Use a password manager.

On Tue, Jul 03, 2018 at 09:56:56AM -0700, Chenfeng Bao wrote:

@LexSong Use a password manager.

How do you propose to backup the password manager database? Do you
propose here to use a password manager with a database without a
password? Which password manager does restic support to get the
password from?

Password management is a huge topic that I don't want to get into too much details in this thread. Just pointing out that if done properly, passwords shouldn't be a headache. There're numerous resources online.

The database of a password manager should already be properly encrypted, so you can put it anywhere you like without another layer of encryption. There're also many cloud based password manager services, so you don't have to worry about backups yourself.

As for restic's support, you can just put the password in a plaintext file locally and use the --password-file option. Then you don't need to enter the password manually. The password itself should also be put in the password manager for record.

At the end of the day, there's always one complex password/passphrase you have to memorize to keep things truly secure.

Actually, if you truly don't want a password on a restic repository, why not just use a one-character dummy password?

Using 'a' as a password was actually my workaround but it does not feel to be proper since I cannot be sure that I remember using this when I see this repo for some reason again in a few years in case I forget to delete it when I do not need it anymore. Therefore I might have to implement some kind of brute forcing to figure it out. This is all work that could be avoided.

In the past I already used simple temporary passwords in situations that left me in this state when temporarily protected an external HD with a password to make it easier to delete it afterwards. However I did not delete it so when I wanted to use it the next time I wanted to make sure that there is nothing important on the drive. Unfortunately the password from my password manager did not work anymore since I forgot to update/remove it from there. Therefore when I think of my future self, it seems to be a good idea to make it easier for him by not creating restic repsositories that I cannot decrypt.

I have another idea, how about restic would try to use "restic" as a default password when no password to access a repository and fall back to a error message if it does not work? Then users could use this password to indicate that they do not need encryption and restic would open it without extra magic.

I'd agree with previous comments to keep the check for protection from user mistakes.

Restic needs to support empty passwords for the reasons already stated. I
specifically do not want to encrypt my local backups because I do not want
to lose access to them. I do not want to risk forgetting the password and
not being able to restore data. This is a real risk because users typically
restore very rarely, and often run unattended backups for which they do not
need to enter the password, making it more likely to be forgotten.

Storing the password in a file or script is an error-prone workaround for a
problem that should not exist.

I agree that care should be taken to prevent accidentally uploading
unencrypted data to remote repos.

It seems like a simple solution would be to have a command line option,
--allow-empty-password. Users could set that switch in their scripts and
the default could remain to require a password.

This is a real risk because users typically restore very rarely, and often run unattended backups for which they do not need to enter the password, making it more likely to be forgotten.

Such backup passwords are not meant to be memorized. The only complex encryption password you need to remember is the one for your password manager, which you will use often. And you _really_ should use a password manager.

Storing the password in a file or script is an error-prone workaround for a problem that should not exist.

Sorry, I just don't see how it's an error-prone workaround. It seems like a completely valid way to automate encryption to me. The problem is solved by, again, using a password manager.

It seems like a simple solution would be to have a command line option, --allow-empty-password. Users could set that switch in their scripts and the default could remain to require a password.

This does seem like a reasonable way to avoid user errors. However, there are still concerns regarding increased attack surface, and need to be addressed with great care.

Such backup passwords are not meant to be memorized. The only complex encryption password you need to remember is the one for your password manager, which you will use often. And you really should use a password manager.

A password manager is absolutely not a valid solution to this problem. The whole point of making backups is to backup your files, which includes the password manager's database! How, then, would you recover the password to the backup set when the password is stored inside the encrypted backup set?

When designing a backup system, you must plan for the worst-case scenario, which includes restoring when you have nothing available except your backup. What you evidently do is backup your password manager database separately from your Restic backups. That is fine for you, but it's not for you to impose that system on other users. And it's absurd to say that a password manager is necessary to use Restic, especially when it is not even designed to integrate with one. If it is, please show me the documentation to that effect.

Restic, like much software, is intended to enable users to meet their needs. Your needs do not include a bare-metal, nothing-but-your-Restic-backup restore scenario. Others users' needs do. Please do not dictate other people's needs to them.

This does seem like a reasonable way to avoid user errors. However, there are still concerns regarding increased attack surface, and need to be addressed with great care.

What specific concerns do you see regarding an increased attack surface caused by the proposed --allow-empty-password option?

This does seem like a reasonable way to avoid user errors. However, there are still concerns regarding increased attack surface, and need to be addressed with great care.

My other idea was for restic to use a default password to access a repository when no password was specified, for example restic. Then the UI for creating a new repository does not change and only when a user uses the default password restic will automatically be able to access the repository and the user does not need to remember the password.

Sorry, I just don't see how it's an error-prone workaround. It seems like a completely valid way to automate encryption to me. The problem is solved by, again, using a password manager.

As long as there is no integration with the password manager, there is still the danger that the value in the password manager is wrong, outdated or accidentally deleted since there will be a copy of the password outside the password manager.

I would also like to see an option to allow an empty password (through the use of the --allow-empty-password flag, or perhaps something more verbose/unique to highlight the risk, like NRPE's --dont-blame-nrpe flag).

My use cases:

• Business: we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).
• Home: I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (_for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another_).

I understand the need for a passphrase to ensure data integrity as well as encryption. I see the file(s) in the keys directory appear to be a JSON object. Perhaps a psuedo-random key could be generated (rather than no key) and stored in there? This doesn't help the users who are trying to avoid the overhead of encryption for performance reasons though.

@fd0 What do you think of the proposed --allow-empty-password command line option? It would require passphrases by default, but allow users to override it when necessary.

And please consider reopening this issue. Many users' needs include backing up non-confidential files without risk of losing access due to forgotten or misplaced passphrases.

Brand new restic user here -- haven't even created my first repository yet -- but years of experience with other tools -- my favorite being good old "dump". With respect, this is a no-brainer -- of course empty passwords should be allowed. By all means add a flag to minimize the risk of inadvertent error, but please do not dictate use cases to experienced (potential) users who have clearly indicated other needs.
All I'm trying to do is make local backups for safety; security is not an issue, and I am far more likely to lose track of the password than I am to need the backup. And I hate password managers...

Having password requirement makes it hard to automate backups, and needing to provide the password in an env or a script file renders whole security thing useless in the first place.

needing to provide the password in an env or a script file renders whole security thing useless in the first place.

That's not necessarily true. There are good ways to do that.

That's not necessarily true. There are good ways to do that.

Please don't rehash this argument here. Many users need to make unencrypted or empty-password backups. If you're not one of them, good for you.

@mholt, any recommendations? I would be more than happy to backup my servers with zero interference with maximum security.

Many users need to make unencrypted or empty-password backups.

This is usually an XY problem.

@mholt, any recommendations? I would be more than happy to backup my servers with zero interference with maximum security.

It highly depends on your specific situation, threat model, environment, acceptable risks, and technical and usability objectives. So no, I don't have a blanket set of recommendations for anyone.

This is usually an XY problem.

So no, I don't have a blanket set of recommendations for anyone.

That condescending attitude is not helpful. Much worse that after telling us our needs are wrong, you then decline to offer any advice. This is a FOSS project, not Apple, Inc.

For example, I neither need nor want to encrypt my local backups of my already-unencrypted data. If my primary disk fails and I need to recover my backups, the passphrase is stored inside the backup repository with my backup scripts and config files. My primary concern is not to keep others from accessing this non-sensitive data--my primary concern is easy recovery and not being locked out of my data.

This is a common case for many users, and it's not for you to decide what users' needs are.

Software exists to serve users, not to force users to acquiesce to its demands.

Thanks for explaining your use case(s) and you concerns again. For the record, I think they are valid, especially the "lost password" one. I also think that a special flag for restic init like --allow-empty-password would work (I have some considerations for corner cases, but I'm confident that they can be solved). I'll therefore reopen this issue.

Please be aware that allowing empty passwords will address the safety concern for "lost password", but will still encrypt all data as usual.

On a different note, I don't like the tone in this thread at all. You are free to not use restic, that's perfectly fine. Most of us are working on restic in our spare time. Some comments in this thread come across as very entitled, paraphrased: "you must implement this feature, there are users who need it!". That's not the case. We can consider and implement it, but we can also decide not to do anything.

So, please, everyone, let's keep this discussion productive, even if you disagree. :)

@fd0 Forgive me for being unclear. I don't demand or expect anything of you or any Restic developers. It's your project and your time, and you can work on whatever you want.

What I ask is that you consider this feature and use-case. If you're not interested in implementing it yourself, that's fine, and I ask that you leave the issue open so others can discuss it, and that you consider any PRs that might implement it.

What I object to are comments (not yours) which suggest that users who want this feature don't understand their own needs, especially when followed by a refusal to suggest alternatives. That's rude and unhelpful noise.

For me, I'm using git-annex with a bup special remote. Annex already supports encrypting files(which I've turned off, to make use of bup's deduping feature). And then I back up the bup repo(which is just a fancy git repo) to a remote server. I can then delete the bup repo, as it is just a cache, and do a restore via restic, as needed.

So, basically, I'm stitching a bunch of single-use tools together, in the Unix Way(tm), as each does their own thing well. Restic(I'm currently switching from duplicity) does sliding-window-block deduplication, to a remote cloud, and that's all I need it to do. Encryption and local block deduplication happens at a different layer. So, I don't want to have a password specified, nor any encryption(which actually saves on CPU use).

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

This is only half what I want, as it is still encrypting, but with a blank password. I'd like to recover that cpu usage, if I could.

Please be aware that allowing empty passwords will address the safety concern for "lost password", but will still encrypt all data as usual.

Hm, what is the motivation behind still encrypting with an empty password?

I mean, when running restic on low-powered hardware the encryption adds some noticeable runtime overhead.

Edit: Ok, https://github.com/restic/restic/issues/1018#issuecomment-307549863 - especially the 2nd point answers my question.

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

The main problem with this suggestion is: It just does not work, restic is asking for a password interactively then:

~# restic -r '/tmp/restic/' -p '/dev/null' init
enter password for new repository:

Thank you, @fd0, for reopening the issue. I agree with @alphapapa , my intention is not to push any free-time developers to spend their time on anything they don't have fun with.

We just don't like being told by other we don't understand our own need.

To my view the most important feature of a backup tool is the ability to do a restore in any case. Although security has a very, very high importance, it depends on the specific situation whether data safety (ability to restore) or data security (protect from unauthorized access) has a higher priority.

Of course, you could freely decide to develop a tool only for situations where security is more important then safety.

As @mholt mentioned "XY-Problem": The request is to be able to do a disaster recovery without any knowledge beyond a public available generic restic documentation and of course access to the repository itself.
"Without any knowledge" excludes the need or use of password managers.

The reason I found this issue is: _I am helping some people with their PCs in private. Their handling of passwords is a mess, trying to teach them proper password handling while setting up a backup on USB-drives will only result in either not creating backups at all or not heaving password available when needed. They may get help by somebody else when needing a restore, so anything I come up with to mitigate the situation might be void._

Right now, I am saving the password in a text file on the same USB-drive as the restic backup repository, which spoils the security of having a password completely.
And I don't like this solution as using a password which does not give any additional layer of security gives a very wrong imagination of security.

Of course I am only talking about personal local backups here. For severs, I recommend strong passwords copied to some separate offline storage.

I think another problem here is; if some frameworks/APIs allow empty passwords and some do not. And one has to decrypt an input that was encrypted by another API with empty password. This is currently my problem with https://github.com/RNCryptor/JNCryptor

So, please, everyone, let's keep this discussion productive, even if you disagree. :)

After reading this thread, I find conversation productive, because the outcome was positive.

I'd like to remind everyone that this is Github - if you feel strongly about something and the project maintainer isn't receptive, feel free to make a fork - it literally takes seconds. If you lack the skill to make the change yourself, enjoin others to help you. You'll find that maintainers can be more open to accepting a patch that implements something they would not have been motivated to implement themselves.

Personally, in this case, I think that enforcing a preconception of what security "should" be onto everyone, is a mistake. The first rule of data security is that the data must be accessible to those who are entitled to have it. Any rule which compromises rule #1 should be considered with due care.

Security is a topic that is full of FUD and fear-driven policies, resulting in naive, hasty, and often hypocritical implementations, because few among us actually like to think about all the things that can go wrong. Even less want to face the criticism of others when we are seen to allow things to go wrong.

Some common mistakes we see every day:

1) Insisting that data written to a media that is encrypted at rest, must itself be encrypted, even in a trusted environment. Where does the fear of interception end? Where to we begin to trust that the user could potentially be competent, and that adding redundant layers merely increases the risk of data loss?

2) Insisting on password of a specific format, ie 8 characters with at least one uppercase letter, one number, and one non-alphanumeric - this was a common practice for 20 years and has now been debunked because the pain exceeds the gain. Instead we should insist on memorable, high-entropy passwords like xkcdpassword, or integrate with a password manager (which effectively makes all key consumers reliant on a shared security SPOF master password that can be spearphished - just ask COMMODO) or integrate 2FA (potentially better depending on the second factor's physical security, including N+1 key redundancy).

3) With a master password - failing to cache it in a session such that the user is forced to enter it so many times throughout the day that the very action of them entering it becomes a conspicuous attack vector.

4) With a master password - failing to check policies and blindly querying for the master password such that the user becomes accustomed to presenting it when it should not actually be required, resulting in them stopping critically analysing whether or not they should be providing it in this instance.

5) Enforcing a policy of least privilege to a point that users resent it and avoid opting in, or find ways to work around it, leaving the door open far longer than if there were a more permissive scheme.

6) Enforcing a policy of least privilege without N+1 redundancy, aka lack of 'business continuity / "key man policy" considerations. ie instead of locking a shared resource behind 2 private keys so that it can only be accessed when both agree (quorum of 2), lock it behind any 2 of 3 private keys. Nobody lives forever.

Any time we as programmers are implementing a single key encryption scheme, we need to consider the importance of accessibility, and hear the concerns of those who are painfully aware of the consequences of key loss for a single key encryption scheme.

Let's also try to kindly remember that taking things away from users purely out of fear of misuse, is fundamentally wrong - like almost all decisions made out of fear. Punishing everyone because someone might do the wrong thing, diminishes society as a whole.

If you feel in this moment that you disagree with that concept, then take a deep breath, count to ten, then consider this: What should we as a society do when someone commits suicide by putting their head into a trash bag with a can of spray whip cream and inhaling the entire can of Nitrous Oxide? Should we take spray whip cream away from everyone? Plastic bags? Breathing? All these things could be misused in a way that causes user death.

Instead of the knee-jerk impulse to take things away, as we would with a child playing with matches, we should instead err on the side of educating people to use these things correctly. Or raise the bar of entry such that only those who RTFM will find it.

That's what happened in the end here, and the decision to accept that outcome didn't come until all the issues and opinions were already expressed. I recommend watching Parliamentary Debate sessions on the public TV stations for examples of what unproductive debate sounds like, lol. The participants here were exceptionally respectful towards each other by comparison.

Remember old good archive utilities where encryption and password protection was available as explicit options only but not by default. And this is the right logic because security may have a lot of external solutions out of this utility scope and because this care is up to the user. What do you do is just provide those security tools of the users' choice. But the author prefers to take care of what the user doesn't ask to prevent misuse.

And again about the tone. This is usual for the open-source world. And it backed by some psychological mechanism. Criticism the authors doesn't agree is treated as a claim to spend their spare time. And every time we have to remind: we don't discuss here Your spare time, instead we explore Your genius creature, its functionality, and the logic behind it. We never forget that You have no obligations to meet our demand and you have full right to do nothing at all. But if You like what you do, it may be (maybe) because others like it. So there some hope may exist that You are interested to meet demand at least of the majority.

P.S. All these are just abstract ranting and no practice actions are meant.

There's one thing I've never understood with the discussion about allowing no password for a repository (assuming the context @fd0 wrote earlier, that the data will still be encrypted); Why don't those that "don't want" a password just use a dummy password like "1234" or whatever? What's the point of writing code in restic that removes the password, when if you don't care about having a password you can just use a dummy password? It's one environment variable or password file away, if you think it's cumbersome to type it on the command line when running restic.

@rawtaz This has been answered in previous comments on this thread.

Just let me say that restic init -r foo --no-password is probably a better flag name than restic init -r foo --allow-empty-password, simply because the former is more to the point and the latter is just too verbose.

I fail to see any good arguments why just using a dummy password isn't a perfectly viable way to do this instead of increasing the restic code base on this topic. I've seen someone say that they might forget the password "a". While that might be true, surely it's possible to invent a simple dummy password and remember that, or at least figure it out anew when need be. But whatever, a flag works fine too, I'm just amazed at how big of a problem this seems to be :D

Well, here's an example. Made a restic backup a year ago. Scripted a
dummy password, read from a file. Didn't write down the password
anywhere else. After a year of not using that machine, I completely
forgot both the process and the password -- and wasted an hour trying to
guess the password before eventually finding (and reverse engineering)
the script. My fault entirely, but still -- I don't need the security,
and don't want to be forced to remember a dummy password. And if I
hadn't had access to the original files, I would have been locked out.

TD

Isn't that a matter of having overcomplicated it? One of the most common passwords is 1234. Use that and you'll not have to try and find it somewhere (assuming you don't think that you used a more complex one) because when you need to enter a dummy password you know it's 1234. But sure, I see what you mean.

I would also like to see an option to allow an empty password (through the use of the --allow-empty-password flag, or perhaps something more verbose/unique to highlight the risk, like NRPE's --dont-blame-nrpe flag).

My use cases:

* **Business:** we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).

* **Home:** I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (_for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another_).

I understand the need for a passphrase to ensure data integrity as well as encryption. I see the file(s) in the keys directory appear to be a JSON object. Perhaps a psuedo-random key could be generated (rather than no key) and stored in there? This doesn't help the users who are trying to avoid the overhead of encryption for performance reasons though.

• Business: we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).

But those "anyone" already need special knowledge/instructions. They need to know either how to run restic to restore data, including which repository to use and other things, and it'd then be incredibly easy to include a dummy password in those instructions. Or they'd use a script or similar automation that does the restore for them (in which case they still need to know/get instructions for where to go to use that tool), in which case the dummy password would be handled by the script. No matter how you look at this, a dummy password is a non-issue. And seriously, if everyone would all of a sudden forget it, people will be able to simply guess 1234 or brute force it. It's not a problem :P

• Home: I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (_for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another_).

Wait, what? Why on earth would you want to have no password, and when that's not possible (currently at least) use a super simple dummy password (e.g. 1234), and then put that super simple dummy password in a safe? That'd be completely pointless. Put it somewhere else, and for what it's worth you probably already have a whole bunch of other information that your family need to know in the case of your demise, so just put your dummy password along with that.

Finally, a dummy password should be so simple and obvious that it won't go out of date, and there's no need for more than one dummy password. So it shouldn't be out of date or mixed with another one.

Yes, those suggestions have already been made, so we're going in circles now. Personally speaking, they are not suitable solutions that I'm comfortable with for my environment and use cases.

You don't have a need for this feature, that's fine. That doesn't mean everyone else's use cases are invalid. I don't have a use for the Amazon S3 backend, but I don't declare it un-needed, I just don't use it. If this feature is implemented, it costs you nothing to not use it.

Yes, those suggestions have already been made, so we're going in circles now.

Yeah, and honestly I still haven't seen an actual explanation to why a dummy password is so hard to handle, I feel I've mostly seen overcomplications of it.

Personally speaking, they are not suitable solutions that I'm comfortable with for my environment and use cases.

This is something I totally respect. Everyone's use case is individual and you have your workflow :)

I guess at some point we will get a --no-password or similar, hopefully that will solve this use case too. Thanks for your input!

rawtaz wrote

Just let me say that restic init -r foo --no-password is probably a better flag name than restic init -r foo --allow-empty-password, simply because the former is more to the point and the latter is just too verbose.

I fail to see any good arguments why just using a dummy password isn't a perfectly viable way to do this instead of increasing the restic code base on this topic. I've seen someone say that they might forget the password "a". While that might be true, surely it's possible to invent a simple dummy password and remember that, or at least figure it out anew when need be. But whatever, a flag works fine too, I'm just amazed at how big of a problem this seems to be :D

I'm not concerned about dummy password usage/handling - instead I'm sometimes concerned about CPU usage slowing the backup process down by the mandatory encryption when it's running on lower-end hardware.

Resolving #1018 (Unencrypted backups) would also resolve this issue - i.e. e.g. with a --unencrypted switch instead of --no-password switch.

I actually used restic on lower-end hardware where the CPU definitely didn't have AES-NI (or a similar extension) and where the backup then was CPU bound. In another case the CPU was a bit more powerful but the only available external hard drive was already LUKS encrypted and thus it was CPU bound because it wasn't powerful enough to handle two encrypting processes in parallel.

See also: https://github.com/restic/restic/issues/1018#issuecomment-307549863

If You forget how to use restic You can read the docs. If You forget a repository location You can find it. Or You can casual encounter orphan repository and wondering what there is backing up inside. But if You forgot password You lose your data forever. And in real life You can forget any simplest dummy password. You can forget everything You don't use often.

If You lose root password You can boot with init=/bin/bash option and get full access. While this hole could be closed it still exists in most systems. Why? Because loss from the unavailability would be more than from insecurity in those cases. Thus it is a trade-off between security and availability. For systems with higher requirement special solutions exists, like redundant keys, provided both security and availability.

resitc is not a security tool. It is a backup tool. And as such, it should provide backup functionality itself first of all, and only then security. So password protection and encryption could be provided as options only and should not be in place by default.

BTW: defaults are the mark of software quality.

@vstavrinov Please read the introduction to restic before saying it's not a security tool. It's a backup tool of which one of the primary features is that it tries to make your backups secure. So, you're pretty far off when you say that it's not concerned about security.

But if You forgot password You lose your data forever.

Yes, and that's why you (in this case have the simple option to) use a dummy password so that you will always be able to realize the password even if you were to forget it.

And in real life You can forget any simplest dummy password.

If you do, you picked a too complex dummy password, and it's not really a simple dummy password anymore.

This whole discussion is becoming hilariously silly, frankly. I can't believe people are saying that a password like 1234, which is one of the most common and obvious ones, is something that they might forget and then not be able to figure out real quick (e.g. by just trying a few obvious dummy passwords). I'd say you have to try real hard to not be able to "guess" 1234 when you're in that situation, and even then you will most likely fail to not guess it.

But if You forgot password You lose your data forever.

Wikipedia might help you out: Just try the most common passwords from https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

One situation where this may happen is when the environment variable RESTIC_PASSWORD is not exported or set to the empty string accidentally.

It is possible for the code to check if a password was set to an empty string explicitly or just not set (no command line option specified, environment variable not set -> different from an empty string).

I think the choice should be given to the user which password one wants to choose.

Resolving #1018 (Unencrypted backups) would also resolve this issue - i.e. e.g. with a --unencrypted switch instead of --no-password switch.

Encryption should still be mandatory to protect against binary search on a hosting provider independently from the format, transmission over an unencrypted channel with MITM and so on. While this does give you as much protection as an empty password does for targeted attacks (zero), it still avoids collateral damage on non-targeted attacks.

@rawtaz

It's a backup tool of which one of the primary features is that it tries to make your backups secure. So, you're pretty far off when you say that it's not concerned about security.

Not far off. Point me where I say "it's not concerned about security". I don't. You say the same: "It's a backup tool". Backup is not security, right?. So restic is not a security tool. And "... one of the primary features ...". You are right again: it is a feature. i.e. security is a feature, while a backup is a functional (target) designation.

@rawtaz

This whole discussion is becoming hilariously silly, frankly. I can't believe people are saying that a password like 1234 ...

I can do nothing, but You are right in this case too. What is silly is a discussion of a dummy password. But I think more important is to understand that password protection and encryption should be optional. As well as do not impose users extra unwanted features, leaving them a choice to use or not to use it. And this is the mark of software quality too.

But I think more important is to understand that password protection and encryption should be optional.

Why? Why "should" a backup tool not have default encryption? Just because it's a "backup" tool? You're just saying this but there's no reason to any of this.

No design decision can please everyone. Restic _chooses_ to put a heavy emphasis on security, and users like me _love_ that strong encryption is the default.

• If you don't care about security, you _cannot_ misuse a secure-by-default system. At worst, you see some errors and try again with an adjusted command.
• If you care about security, there are tons of ways to misuse an insecure-by-default system to catastrophic effect. One missing flag, and your sensitive data is leaked, maybe _irreversibly_.

It's one thing to ask for a flag that can omit the password, but arguing for no encryption by default is a dangerous "screw you" to all existing users who are relying on restic's encryption. The potential for catastrophic user errors is huge.

@cfbao

But I think more important is to understand that password protection and encryption should be optional.

Why? Why "should" a backup tool not have default encryption? Just because it's a "backup" tool? You're just saying this but there's no reason to any of this.

"optional" is not the same as "default". Defaults as such may be arguable. But to have options is more important. While we have no choice there is nothing to do with defaults. That's the point. First provide options then it makes sense to discuss defaults.

In this case (issue) it's pretty simple - there will likely be a --no-password or similar flag to restic init (with the default still being that restic requests a password upon init), but this is just my take on @fd0's last response. And there's no ETA at this point, no need to ask about that :)

Meanwhile, use a dummy password :) I would guess that a proper implementation includes the ability to remove/unset a password/key that was previously used to init the repo, so one shouldn't have to recreate the entire repository.

Encryption is another thing however, and tracked in that other issue.

I don't care too much about a no password option, but you were arguing for default no encryption:

So password protection and encryption could be provided as options only and should not be in place by default.

BTW: defaults are the mark of software quality.

which I find dangerous.

Though I generally agree with @rawtaz's points, if the discussion is strictly about a no password option (not changing default), I don't have too much of a stake in it.

@cfbao

I don't care too much about a no password option, but you were arguing for default no encryption:

So password protection and encryption could be provided as options only and should not be in place by default.

You can see even in this cite the "options" are first and "default" is next. And that's the point again.

In this case (issue) it's pretty simple - there will likely be a --no-password or similar flag to restic init (with the default still being that restic requests a password upon init), but this is just my take on @fd0's last response. And there's no ETA at this point, no need to ask about that :)

Meanwhile, use a dummy password :) I would guess that a proper implementation includes the ability to remove/unset a password/key that was previously used to init the repo, so one shouldn't have to recreate the entire repository.

A probably simpler solution would be for restic to support a dummy password that it will try to open an existing repository if no password is specified by the user.

Regarding handling dummy passwords: There is no clear best dummy password that works for everyone. 1234 is an annoying dummy password since it requires four fingers to move up and type. "asdf" is a lot faster to type for example. Also some services restrict password choices, so only numbers or only four digits might not be possible. Therefore a solution inside restic would be most user-friendly. Then users would only have to type the dummy password once.

From a security by design perspective, providing any sort of dummy password is a bad idea.

IFF someone really wants to circumvent the encryption or does not need it, simply supply a consistent password. You don't have to type it, you can write a script to wrap restic and hard code to your heart's content in there. Really, is that more work than supplying the repository address or other config options?

Having restic try a set of fake or dummy hardcoded passwords is just asking for trouble. What if some poor soul happens to pick one of your proposed "magic" passwords? Do we warn them off choosing our special dummy, fake encryption passwords? "No Ted, you can't choose SPACECHICKEN as your repository password, it's _special_." ;)

I'm fine with providing a option for users to shoot themselves in the foot with ("--no-repository-password") but I don't think restic should go any further than that to appease the very small segment of users that desire REDUCED security.

From a security by design perspective, providing any sort of dummy password is a bad idea.

Why is it worse than allowing no password?

IFF someone really wants to circumvent the encryption or does not need it, simply supply a consistent password. You don't have to type it, you can write a script to wrap restic and hard code to your heart's content in there. Really, is that more work than supplying the repository address or other config options?

Yes, it is more work. Restic would be the backup solution and its output is the repository. So, ideally, the repository would contain everything to restore the backup. But when using a wrapper script that hardcodes the dummy password means that this script needs to be backed up by something else, otherwise the repository would be useless.

Having restic try a set of fake or dummy hardcoded passwords is just asking for trouble. What if some poor soul happens to pick one of your proposed "magic" passwords? Do we warn them off choosing our special dummy, fake encryption passwords? "No Ted, you can't choose SPACECHICKEN as your repository password, it's _special_." ;)

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

I'm fine with providing a option for users to shoot themselves in the foot with ("--no-repository-password") but I don't think restic should go any further than that to appease the very small segment of users that desire REDUCED security.

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

Why is it worse than allowing no password?

I'm not sure how I would go about convincing someone that hardcoded, hidden, secretly tried against repositories passwords would be a bad idea. If you think they are, there is likely no security focused argument that would convince you.

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

I chose an entertaining example, perhaps I should not have. Let's assume that your dummy password that you want restic to secretly and automatically try if decryption fails is: "12345". A naive user could very well choose that as their password. Now they have a repository that they believe is encrypted (and sort of is) but _anyones_ restic can decrypt. This argument applies for any give set of passwords you choose in your hardcoded set. This is fundamentally bad security design.

There is a term for what you are proposing. It's called an encryption backdoor :) Hiding that backdoor in the documents assumes that all readers will fully read the manual before using restic. Would it not serve more people's needs to make them read the documents to determine how to lessen secure should they strangely desire that?

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

If you don't think that encryption at rest is a solid security policy and would opt for something else, you are certainly in the deep minority. These kind of insecure defaults serve no one and should be discouraged at every point. One needs only to look to ANY security reference for advice in this case. My point is not the contentious one - I'm arguing the industry standard practice.

Even your example of append only storage media would strongly benefit from at-rest-encryption. I'd hearily recommend reading a recent set of NIST, ISO 27002, NERC, IEC 62443 or really any globally accepted standard for guidance in best practices here. We're not in new territory.

I should also point out that we are effectively conflating two issues in this thread: key management and encryption.

Perhaps that's where the confusion arises.

Maybe this issue can be solved by documentation that says something like:

If you don't want to secure your repository with a password, just use the string: password

That way there's a well-known way to achieve backup/restore with restic without having to manage any keys.

Why is it worse than allowing no password?

I'm not sure how I would go about convincing someone that hardcoded, hidden, secretly tried against repositories passwords would be a bad idea. If you think they are, there is likely no security focused argument that would convince you.

I guess you are missing a "not" there...

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

I chose an entertaining example, perhaps I should not have. Let's assume that your dummy password that you want restic to secretly and automatically try if decryption fails is: "12345". A naive user could very well choose that as their password. Now they have a repository that they believe is encrypted (and sort of is) but _anyones_ restic can decrypt. This argument applies for any give set of passwords you choose in your hardcoded set. This is fundamentally bad security design.

I did not propose to try it when decryption fails but when no password is specified for decryption. If someone chooses an insecure password, it is insecure regardless of it being tried by restic directly or by someone brute-forcing passwords. "12345" is an insecure password nowadays, as well, and it would not change if it became the default password for restic.

There is a term for what you are proposing. It's called an encryption backdoor :) Hiding that backdoor in the documents assumes that all readers will fully read the manual before using restic. Would it not serve more people's needs to make them read the documents to determine how to lessen secure should they strangely desire that?

An encryption backdoor would be if restic used a default password additionally to the user-provided password when encrypting data. My proposal is about trying one password at decryption. The user would still actively choose this bad password.

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

If you don't think that encryption at rest is a solid security policy and would opt for something else, you are certainly in the deep minority. These kind of insecure defaults serve no one and should be discouraged at every point. One needs only to look to ANY security reference for advice in this case. My point is not the contentious one - I'm arguing the industry standard practice.

What's the insecure default in your opinion?

Even your example of append only storage media would strongly benefit from at-rest-encryption. I'd hearily recommend reading a recent set of NIST, ISO 27002, NERC, IEC 62443 or really any globally accepted standard for guidance in best practices here. We're not in new territory.

At-rest-encryption does not mean that restic needs to do it. The append-only storage can still be encrypted somehow else if necessary. Nevertheless, there will be some unencrypted storage, even if it is only for the password. Otherwise the backup concept would rely one someone always remembering the password.

unsubscribing from this thread...

Let's just leave it at this, it's clear that some people want a --no-password option to init, and that's all that this issue is about. Encryption or not is a separate issue.

Just a quick comment here:
I'm a user who doesn't care about encryption. There's nothing sensitive about my data. I do care about people being able to use in 20-40 years who aren't me. Just using rclone is another poorer alternative.

Restic looks like a good tool for this, except mandating encryption and a password means that I need to take that into account. Maybe a README in the backup repository. It is more work and any solution (from my side) defeats any encryption anyway.

Mark

Thanks for your contributions, I think we've collected enough information.