1
  1. Confidentiality is the property of a message whereby no one but the person who knows a secret (let's calle it K) can read the message.
  2. Hashes do not provide confidentiality (data is destroyed, you can't recover it)

Following these definitions, is it OK to hash sensitive data (eg: passwords) and store it in a database? I already know using SHA256 (or any other non-specialised hash) is dangerous, because brute forcing is relatively easy. Let's say we are using Argon2.

The question now becomes: is it OK to assume the hashed data remains private when using the correct hashing algorithm? If so, what's the name of the property that provides this safety? Is it non-reversibility? SHA256 also provides non-reversibility, but is easy to bruteforce. Is there a name for this property?

1
  • Hashing algorithms are by definion, non-reversible. That is why the bruteforce is the attack used against them. To avoid bruteforcing salt is added to make the result of the hashing mostly unique (so bruteforcing would not match the existing hash, the brute forcer does not know what was the salt added). F(secret+salt)=hashed but the attacker does not know salt. Think also a scenario where each row of the database with the hashed secret used a different salt, that bruteforcing would be really hard for the attacker.
    – bradbury9
    Mar 9, 2021 at 12:32

2 Answers 2

2

You're conflating two concepts

Confidentiality is the property of a message whereby no one but the person who knows a secret (let's calle it K) can read the message.

It doesn't even need to be a shared secret. Confidentiality means

Only those who are allowed to see the message can see the message.

How this is done in practice doesn't matter to the idea of confidentiality. An example of this is talking with someone in private. The contents of this discussion are confidential, as long as both parties do not share it with anyone else. There is, however, no secret "key".


Hashes do not provide confidentiality (data is destroyed, you can't recover it)

That's not what hashes are designed to do. A hash, in simple terms, allows you to check whether two inputs are identical. Let's define m to be a message and H() to be a hash function. We expect that H(m) = H(x) if m = x. Further, we expect that H(m) != H(x) if m != x. The second assumption is provably not true for any hash function due to the Pigeonhole Principle. However, we expect it to be very difficult for an attacker to find such a message that causes a collision.

Furthermore, it is important to know that hash functions are one-way functions. That means you can calculate the hash of a message, but you cannot recover the message from the hash. If that were possible, then I could create a 512 bit long hash of a 20 TB large file, send you the hash and have you "calculate" the original message back.

Is it okay to store password as hash?

Yes! Please do!

OWASP recommends using hash functions like Argon2 to store passwords. Why?

From a purely functional perspective, the easiest way would be to store a password in plain text. The user enters it once when registering, then it is stored and when the user tries to log in, all that has to happen is a string comparison.

The reason we use hashes is because when (not if) a database is compromised, we generally do not want attackers to get instant access to all of our users' credentials. For that reason, we store the hash of a password. Because really, the server owner doesn't care what the password is, as long as whatever the user entered during registration is the same as what the user enters during login.

What is the name of this property?

The property you are looking for is called "cracking resistance". In theory, yes, SHA-256 could be used and is being used in practice as well. the problem with SHA-256 is that it is relatively quick to calculate. I can calculate millions and millions of possible password candidates for a given SHA-256 hash.

Argon2 on the other hand is designed to be extremely slow. That means I could only generate, say, 100 hashes per second, which makes offline brute-forcing extremely expensive.

3
  • Excellent answer, thank you. "Cracking resistance" is exactly the term I was looking for and did not know I was missing! This all spun from a workplace discussion where I was challenged to show (somewhat formally, or at least referencing known properties) that hashes where the correct option when we knew they formally provided no confidentiality. Now I know I must answer "you don't care about confidentiality because you are not trying to convey that information to someone else, you care about cracking resistance because you're trying to make sure this can't be cracked") Mar 9, 2021 at 12:54
  • @joaquinlpereyra Exactly. The important thing is that the content of the message (the password) doesn't actually matter to you at all. All you care about is that it's identical to what the user entered previously.
    – user163495
    Mar 9, 2021 at 13:24
  • 1
    Not only is Argon2 slow, it's also memory hard. This means that an attacker is forced to dedicate more silicon to memory, which makes it more difficult for them to use GPUs or (cheap) ASICs.
    – forest
    Mar 10, 2021 at 7:49
1

is it OK to assume the hashed data remains private when using the correct hashing algorithm?

It depends. It is easy to derive the hash from the data. So if there is only a limited number of options in the data it is easy to try all to find out which data item a specific hash means.

Even if there is a huge number of possible options but most of these highly unlikely the privacy can be broken in many cases by simply trying the more probable options. That's also the idea behind effective password brute-forcing: try the most commonly used passwords and their variations first.

If so, what's the name of the property that provides this safety?

The relevant properties which makes brute forcing hard are the slow performance and the choice of salts. Proper use of salts makes it impossible to precompute the hash of many inputs. Slow performance then makes it impossible to simply try each input.

SHA256 also provides non-reversibility, but is easy to bruteforce. Is there a name for this property?

Performance. SHA-256 is simply very fast and that's why it is possible to try lots of inputs in a short time.

1
  • Beat me to it by a minute :D
    – user163495
    Mar 9, 2021 at 12:46

You must log in to answer this question.

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