Why would a password be hashed before being used to encrypt something?

Question

When reading some documentation about the security of a product, I found that the vendor uses the SHA-2 of a password to encrypt data (AES-256), instead of using this password directly.

Are there any advantages of doing so?

An attacker is not going to crack the encrypted data using this SHA-2-as-a-password key but rather exhaust the password keyspace (if feasible) and try its hash. Therefore the only reason I can think of is that there is an extra computational step (the creation of the hash). I would have rather increased the password entropy if the point is to computationally complexify the attack.

Answer 1

It sounds like a primitive version of a key derivation function (KDF), in particular they probably could have avoided reinventing the wheel by using PBKDF2.

There are several reasons why you don't want to use the password directly as an AES key.

1. To distribute the bits. The main property here is that a hash function's output is, statistically speaking, uniformly distributed. People tend to pick passwords that aren't fully random, in particular, most passwords would only contain characters you can type in a keyboard. When used as an encryption key, a non-statistically random key may expose weaknesses in the encryption function.

2. To fit the keys to the encryption key length. Most passwords are going to be either longer or shorter than the key space of the encryption function. By hashing your password, the exact key length will be exactly the size of the input key of your encryption function. While the entropy of the derived key doesn't increase, this avoids the likelihood of exposing weakness in the encryption function if you just simply zero pad the password or worse truncate the password.

3. To slow down key derivation decryption. Per your description, the software is only using a single SHA256 round, which is not much. But with proper password based KDF, like PBKDF2, there are usually tens of thousands or hundreds of thousands of rounds of the underlying hash function. This slows down computing the keys, increasing the effective strength of passwords without increasing its length.

4. To keep the user's plain text password out of memory, thus preventing it from being accidentally dumped to disk during hibernation or crash dump. While this wouldn't protect the hash from being used to decrypt the data you're encrypting, it will prevent the password from being reused to decrypt other files (which presumably uses different salt) or being tried on your online accounts or other devices that you use.

Answer 2

SHA-256 will generate a 256-bit hash from arbitrary length passwords. This hash can technically (as in it's the right length) be used as a key for AES-256.

Without more context, I'm guessing that they went for the simplest way to generate a 256-bit key.

As you mentioned, the weak point here is the password, and a single SHA-256 of the password is too cheap to prevent brute-force attacks on the password.

Instead, one should use a password-based key derivation function (PBKDF). One also shouldn't be using the key directly, but instead use it to encrypt keys generated using a better CSPRNG.

You can find a very good discussion of this topic in https://crypto.stackexchange.com/questions/22678/how-secure-is-it-to-use-password-as-aes-key.

Answer 3

Without any context, it's hard to answer. This could simply be a naive password-expansion mechanism or it could be something else. For instance, it could be that another party will need to decrypt the data and therefore store the necessary key.

By using a hash, it would then provide some level of protection for the original user's password. Not much, mind you, but still far better than simply storing the password itself.

Answer 4

I think the main reason for SHA-256 a password is quite simple. You dont want to know the password. If you know the password you need to take some extra precautions in order to protect it propperly. Since a breach could expose the password it would lead to possible other attacks.

Also usually the software does not use the password itself to generate the hash, but some random junk is usually added to it to ensure that 2 users who picked "Pa55w0rd" dont show up with the same hash.

This added salt makes it very hard for the attacker to guess the password, even if he has access to the final hash. There are precomputed resuilts for simple SHA-256 operations out there, and they cover a great deal of the normal key space already (Called rainbow tables) These could be used to find a password related to an account. But these tables fail badly if you add a few bytes of random junk in fromt of the password, and they are even less usefull is each user has its own "random junk"

The only "drawback" is that you cant recover your password, and only reset it. (I hate online services that can send me my password since it shows they dont care)

As others mentioned this results in a convinient 256bit blob of data, which could be used as an 256 AES key. It also means that a password reset would invalidate all encrypted data (Which you might want depending on the data)