Encryption tech is obviously intended to secure things that we want to be private over an insecure medium. When I log into a site for example, my password is transmitted over HTTPS, hashed by the reciever (hopefully), and then compared to the stored hash.

For securing secrets in git repos I have often used GPG in the past to encrypt them before commit, with the expectation that my secrets will not be derived by bad actors.

The intent of the hash (with salt) is to accomplish a similar goal to encrypting the value, save for it being non-reversible. The main difference being that the salted hash is usually intended to stay secret (stored in a secure DB somewhere) rather than being transferred over, or stored on, untrusted media.

Recently I've been playing with automating my workstation setup and I have a need to configure my user account from a public git repo, but I don't have secret encryption configured yet and I'd like to store my hash there.

What I'm unsure about is if this is a bad idea. In my mind, a secure and salted PBKDF with sufficient rounds should be as secure against brute force as a value encrypted with something like AES.

I've done quite a bit of searching and have not found anyone making a comparison between hashing and encryption for storage like this. Every result invariably tells the asker that you should never expose your password hash, often referencing the split of passwd and shadow as proof.

Is my intuition wrong? If so, what aspects of a hash make it weaker against brute force than an encrypted value?

  • "the salted hash is usually intended to stay secret" - No, this is not true. Hash is stored instead of password namely because we assume that the attacker can get access to database and will know hashes. Despite we don't make hashes public intentionally, there is no risk at all if somebody gets access to hashes and makes them public. Assuming of course that a resource intensive hashing is used, i.e. proper algorithm with proper parameters.
    – mentallurg
    Commented Jun 8, 2023 at 8:17
  • If hash is known, the only way to find the password is brute-forcing. But if encrypted password was random and the encryption password was not quite random and you used your own scheme to generate it, and if the attacker knows it, then brute-forcing can be essentially optimized and the attacker may have better chances to find the encrypting password and thus to restore the encrypted password.
    – mentallurg
    Commented Jun 8, 2023 at 8:37

1 Answer 1


It doesn't make sense to compare hashing and encryption in terms of brute-force resistance, because the possible attacks are entirely different.

When the attacker knows the hash of a password, they can systematically try out different passwords, calculate their hashes and check if there's a match. How likely they'll succeed depends on the brute-force resistance of the password hashing algorithm and the strength of the password itself. PBKDF2 is quite weak, so you'll need a strong password (purely random and sufficiently long) to still be reasonable safe from brute-force attacks. If possible, use a more modern algorithm like Argon2.

When the attacker only knows the ciphertext of a password, they cannot simply try out different passwords, because they don't have the key required for encryption and decryption. What they'll do instead is

  • try to steal the key
  • look for weaknesses in the exact encryption method or implementation
  • if there's any way to interactively test passwords, try attacks like a padding oracle attack (against AES in CBC mode)

With encryption, the main “weakness” is that the key must be secret. Once it is known, there is no protection at all. Hashing doesn't involve any secrets (except for the password itself, of course). However, it is possible to perform a brute-force attack by trying out different passwords.

As practical advice, I would use a modern password hashing algorithm and a strong password. This makes brute-force attacks largely infeasible. Additionally, you could use a secret to turn the plain hashes into keyed hashes. Argon2 has a secret parameter for this exact purpose, but it's also possible to use constructions like HMAC on top of PBKDF2.

  • I'm actually using sha-512 w/3M rounds right now, was definitely thinking fo switching to something like argon or yescrypt... The reason I said that it seems similar is because when brute forcing a hash, you try possible values of the content of the hash, with encryption you try possible values of the encryption key. It seems to me, that if the content of the hash and the value of the encryption key are the same that it would take a similar order of time to derive (if each try has similarly difficult between the two, I don't know if this is the case).
    – joshperry
    Commented Jun 8, 2023 at 2:31
  • Trying to brute-force an AES key (regardless of whether it's 128-bit, 192-bit or 256-bit) is absolutely hopeless, unless the key was produced by a completely broken random number generator. A brute-force attack against password hashes can be realistic, if the algorithm and the passwords aren't sufficiently strong. For example, a consumer GPU like an RTX 4090 can calculate billions(!) of SHA-512 hashes per second, so it possible to try a large number of different passwords in a reasonable time frame. On the other hand, keeping a key secret is difficult -- with hashes, there is no key.
    – Ja1024
    Commented Jun 8, 2023 at 2:41
  • Of course one could also combine these two methods: first hash the passwords and then encrypt the hashes. Commented Jun 24, 2023 at 9:15
  • Doesn't a keyed hash already combine the best of both? I can't think of a case where it would make sense to decrypt a hash, so adding encryption seems unnecessarily complex when the only goal is to introduce a key. Especially when the hash algorithm already has support for keying built in (like Argon2).
    – Ja1024
    Commented Jun 24, 2023 at 13:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .