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

Problem:

If you need an automatic Restic backup that requires your password but it is simple learnable clear text in the password-file with read-only root permission (chmod 400), but I do not like it, because the same password is for other applications and other website logins.

My idea:

your password should be convert to any hash e.g. sha256 that will be loaded by the option --pw-hash-file that is unlike --password-file for your own clear password. Both should unlock the same.
However, I know that any hash is password itself, but hash is harder to learn than your password.
But hash is a bit safer than your password, because hash is like a pseudonym (transparent) of your password. Nobody knows what is your password except hash.

My question:

Is this feature possible implementation?

What prevents you from using a randomly generated password in your password-file?

4 Likes

It can also be possible. But it is not for everyone, because it is difficult to learn a randomly password.

  • You lose the password-file If your system crashes and will be deleted, but you do not know what is this password for restoring backup via restic.

  • Not everyone can remember many different passwords, for example there are dementia or Alzheimer’s disease to forget many passwords. But any password manager can help, but if you lose password manager, you can not access restic backup anymore.

So, do I understand correctly:

  • you want to use a user-known password to encrypt your restic backup
  • you want to have automatic backups, i.e. you want to store the password
  • you don’t want to store your user-kown password

This is obviously not possible.

The more detailed answer is:
restic uses symmetric encryption which means knowing the key to save data to a repository also means being able to read all data.

Saving data to the repository but not being able to read the data would require asymmetric encryption, i.e. a privat/public-key encyption. This would then work by using a private key that is accessible with the user-known password and a public key that is saved in the automatic backup process.
However, restic doesn’t implement asymmetric encryption and there is some trouble with implementing this: restic needs to read metadata to be able to provide deduplication and parent detection. So either the metadata will be still unprotected or you’ll basically loose all of restic’s benefits.

3 Likes

How would restic actually use this hash of yours? I mean, if it’s supposed to use it straight away as a password, it’s not much different from just having your password in the file. If it’s meant to “unhash” it, then any attacker reading that hash will also be able to unhash it just as easily. I don’t see how there’s any practical gain to doing this. Please elaborate how it would work in practice.

Probability of cracking hash is lower, not everyone can crack hash. Many people are not computer scientists, they don’t even know how to unhash hash to your password.
But everyone can read your only same password in the password file that is worse than the hash file, then everyone can use the same password for other applications and other website logins.

This doesn’t answer the question. Please explain how you expect restic to actually use the hash?

Regarding “not everyone can crack hash” - they don’t need to, they can just do it the same way restic uses the hash, if it’s supposed to be used without the user inputing their password to compare a one-way hash.

As far as I know there is no difference if restic uses hash or password.

My topic has the goal here : The password should be hidden or pseudonymised in the file.

I feel you’re not getting my point, nor are you answering the question. But in short, it’s not that simple. As @aawsome already said, it’s pretty much impossible to get the desired result with your suggestion.

I am not a native English speaker and do not know much about Restic source code .

The other question, how does restic decryption work?

Restic uses AES-256 symmetric encryption by default, am I correct?
AES-256 requires 256 bits as key that is like the length of SHA256 hash. AES 256 uses SHA256 as key in most use cases.

I am not sure, if Restic uses SHA256 as the key fĂĽr AES-256. Your password is hashed to SHA256 then AES-256 algorithm will process to decrypt data. This means that the password and the sha256 hash must match correctly.

But I don’t get why my suggestion’s impossible like you said, maybe restic’s implementation has a limit.

What would restic actually do with the hash in that file? How would it use it? It’s not about restic having a limitation, it’s about your suggestion not being applicable in practice.

The behavior is like loading the password file. Not so big change of code.
Restic would load the hash as a key for AES-256 without password because the key already exists, no need to re-hash the password into the hash.

You can generate the hash and store it in the hash file.

echo -n password | openssl sha256

An advantage: the password is pseudonymised.

Exactly. So, this effectively means that all we do with your suggestion is to remove one of the steps towards unlocking the repository. Instead of going through PASSWORD → HASH → UNLOCK we just go HASH → UNLOCK.

And since restic then has a way to read the hash instead of a password, it doesn’t matter if the attacker instead has the hash - they can use this just as easily as the plain password. So in the end, it still boils down to having that file properly protected. There’s simply no added security here.

In other words; it doesn’t matter if the input to restic is a plain text password or a hash - as long as the attacker has it, they’ll be able to use restic the very same way that you do, to access your repository.

If you were to be using the same password for your repository as you do use on other sites and services, then your suggestion would lower the risk of other site’s being compromised by the attacker having the hash, they’d have to reverse the hash using tables or brute force. But since you are supposed to not reuse passwords, this is not something that should be a relevant factor or use case.

Feel free to elaborate if I’m missing something in your thought process or suggestion :slight_smile:

1 Like

That’s exactly what I meant. Sorry I didn’t explain clearly before.

Feel free to compute the sha256 hash of the user-known password, write it to a file and use this as --pasword-file.

From a security point of view this equals using the user-known password. And you have the handling benefit that you can always re-generate the password file as long as you know the user-known password.

From the restic point of view, your repository password is the hash of the user-known password.

It is, however, not possible to store the hash of the user-known password and let restic use the user-known password as password. The reason is, if restic could compute the password from the hash, everyone could.

If I understand correctly, “PASSWORD → HASH in the file → HASH → UNLOCK”.

That is pretty hard to type a long password as hash key to unlock your restic repo in CLI without writing your own Shell script.

Do you mean that “Loading HASH in the file → UNLOCK” that is impossible in the restic’s implementation?


My expectation:

  • The option --password-file is for your password as plain text in the file.

    • Load PASSWORD from the file → HASH → UNLOCK. The behavior is like before.
  • A new option --pw-hash-file or --hash-file is for hash of your password in the file.

    • Load HASH from the file → UNLOCK. No need to use password, just like skip password.

Both options should be separated, they have the same behavior to unlock the same repo, no need to change the password. This is just an additional small code extension, don’t change the code that much. But I knew that Java can do.

This is not about restic implementation, this is about how what you are suggesting is not adding ANY amount of additional security.

Again, it does not matter if what you use to “authenticate” with restic is a plain text password or a hash - an attacker that gains the very same piece of credential as you have is able to use it the very same way you do - it does not matter if it’s a password or a hash. Is there anything unclear about this? If yes, please explain what part of it is unclear or doesn’t make sense.

Consider the following scenarios:

  • You keep your plain text password in a file and use --password-file to load it into restic to unlock the repository. An attacker getting read access to that file is, just like you, able to unlock the repository by e.g.:

    • Running restic --password-file to have restic use the password in the file directly.
    • Running restic and manually supplying the password when asked to.
  • You keep the hash of the password in the file and use your proposed --pw-hash-file to load the hash into restic to unlock the repository. An attacker is, just like you, able to unlock that repository by e.g.:

    • Running restic --pw-hash-file to have restic use the hash in the file directly.

In what way do you see an added increase in security when using the hash instead of plain text password, considering that an attacker getting access to the file in question has just as much ability to access your repository regardless of whether the file contains a plain text password or a hash of a password? In what way is there any relevant difference between the two?

As far as I understand, you are asking to weaken restics current security model, to compensate for you reusing passwords while knowing that this is bad practice?

Change your passwords!

related to what OP is asking for, restic could do what rclone does?
rclone encodes the sensitive information instead of storing them plain text, this is not to avoid people stealing your data because as everybody knows, if someone has your config (pass included) it has everything but, I’m guessing, is to avoid giving out any hint about your password to passing by eyes, so if you are working on your machine showing something to someone else and you happen to open your config file the other person or persons don’t see your password in plain text and wont be able to figure out what the complete password is, at least that’s the only utility I see it may have.

1 Like

That depends on your situation. Not everyone has the same situation.
I don’t mean about any attacker around the world. That is not about security of Restic repos, but It’s about protecting my password that won’t let my family or friends know.

In my situation, reading password file is worse than hash file at my home, because my family or friends can easily read and learn my password file at my home if they use my computer, although they are not computer scientists. They do not know what is hash and have no interest in it. But everyone or child knows what is password.