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.
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.
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?
âpassword-command=COMMAND
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: https://www.passwordstore.org/
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.
You can use two passwords: One randomly generated password for the password-file and one simple clear text to keep in mind. Just add a second key, see Manage repository keys.
This is an old thread, but:
Put the password on a USB drive, then unplug it when youâre not using the computer. (After solving all the other issues about trust, etc. )
You cannot provide a hash and hope the password of it can be used for decryption. If you use the hash for decryption you can just hash the password yourself and use it that way.