Idea: using --pw-hash-file instead --password-file

So you do not only reuse passwords but also share your user account?

Your family members should log in with their own computer accounts.

Your secret files should not be readable by everyone but only you.

The folders those files are in should be readable and scannable only by you.

Instead of breaking restic, fix your own security!

My plan was the system backup, but it requires root permission, but my password file is in the root environment, but I am not alone as root user, one of my family members is also a root user. He will read the password file.

This is the problem you need to solve, and the solution is not the proposed --pw-hash-file. If you do not want your family and friends to be able to read the password, then simply have them use another user on the system. There’s no point in them using YOUR user if you don’t want them to be able to access YOUR data. And if/when they can access your data, it doesn’t matter if they can also access your repository password, because that is a password which is only used for that repository and nothing else. So, they already have the data, there’s no point in also caring about the password.

Even the hash would be irrelevant to them, since they can already read your data that you backed up.

If this is the case, this user will always be able to read whatever is on the system, and it doesn’t matter if your file contains a plain password or a hash. And, since this password should not be used anywhere else than in your restic repository, there is no use in hashing it. The only time there would be a point to doing so, to prevent people from reading the plain text password, is when you use the same password somewhere else. If that is what you are doing, you need to stop doing that ASAP (see restic help key for information on how to change the password in your repository).

Seriously, you are trying to solve a problem by not addressing the cause of the problem, and instead doing some kind of workaround that doesn’t add any more privacy or security.

1 Like

Yeah, this is such a corner-case use case that is doesn’t justify the suggested additional parameter. If this was to happen, simply change the password in the repository, it’s quick and simple to do so.

1 Like

Once more:

You have to give up one of the three points above, and I think you realized this. So you suggested to not use the user-known password to encrypt your backup. Fine.

If you want to use the SHA256 of the user-known password, do it! There is even the --password-command option, so if you bother about accessing your repo with a password dialog and only having the user-known password ad hand, write a command which asked for the “password”, computes the hash and feed restic with it.
There is no need to add such an option to restic, as it is fully covered by the existing functionality.

I would, however, suggest to simply use a different/new password for your restic repository. Makes it so much easier! (and is security best-practice).


Yes, that is easy.

I have another question, I am confused about the option --password-command .
I read man page:

$ man restic | grep password-command
       --password-command=""      shell command to obtain the repository password from (default: $RESTIC_PASSWORD_COMMAND)

I tried it, but it does not work:

restic -r [REPOSITORY] --password-command=[PASSWORD] [COMMAND]

Is the command line right? If it is wrong, can you explain how to type a command line with this option?


COMMAND is expected to give the password on stdout, which is caught by restic and used to authenticate to the repo.

Ah, thanks. That is a good idea.

restic -r [REPOSITORY] --password-command="echo PASSWORD" [COMMAND]

I would write this command line with your own random key + encrypted your password (as binary file unlike hash) in C/C++ or Rust instead Shell script, then I compile the source code to a new binary that is not readable for human.

IMHO, I think you’d probably be significantly safer just using some existing tooling rather than trying to reinvent the wheel. If I was tackling this problem, I’d probably use something like pass to handle the encryption, storage, and retrieval of the repository password:

I will note that you originally mentioned not wanting to use a password manager to begin with, but your latest post seems to suggest you’re talking about writing your own binary and then using a key (presumably stored in a file) to decrypt the binary and retrieve the password. This puts you back in the position of needing to keep both that that key and the binary safe to access the password, which seems to me effectively the same as using something like pass.

It is possible to set pass up so that it does not prompt for a password when accessed (iirc you just set a blank master password during the setup steps). So you’d just use the restic flag --password-command="pass restic-repo", where “restic-repo” is the name of the password entry you created for the restic repository, and pass should decrypt + supply the password to restic. Do note that I’ve not tested this specific setup, but I use pass in combination with sshpass in this fashion, so I assume restic will work with it just fine.

Obviously as others have pointed out repeatedly this offers minimal additional security if someone actually has access to your machine. In the above example, an attacker could just run “pass restic-repo” and pass would happily print the password in plaintext to STDOUT, because that’s what it’s designed to do - render the password readable when asked. Ultimately I think anything that allows for automatic password provision is never going to be safe from an attacker with local access, because by its nature, this allows password access without you being present/involved in the loop.

It seems to me like a lot of this discussion is really about “security through obscurity”. I think the stance of many people here is that security through obscurity is no better than no security at all, which is why there are so many responses in here basically saying “this is a bad idea, don’t do it”. But ultimately, we’re talking about your system and your backups. I personally wouldn’t do what you’re proposing, but my threat model isn’t necessarily going to look anything like yours.