Use "verifier" instead of "hash"

[defuse]

Using the word "hash" to refer to CreateHash's return value is a misnomer. It's not a hash. It's a bunch of different things, including the output of PBKDF2 which isn't a hash. We should standardize the codebase and documentation to use the term "verifier" for this string.

[defuse]

I'll do this today.

[defuse]

This is actually going to be a huge change, since it will require changing the public method names.

[defuse]

What about the terminology "Validate" as in "Validate Password". Should it be "Validator"? or "Verify Password?"

[defuse]

Validate: To establish the soundness of; corroborate.

Verify: To determine or test the truth or accuracy of, as by comparison, investigation, or reference:

[defuse]

The "as by comparison" is key. It sounds to me like validate is more internal and a process done on one thing without reference to anything external, i.e. "input validation", whereas passwords are verified against the verifier, so the verb "verify" is more suitable.

[redragonx]

The word verify sounds better

[defuse]

This also requires changing the file names.

[defuse]

I think the file names should be changed to PasswordStorage.*.

[defuse]

Grep turns up 364 hits for "hash". Fuck me.

[defuse]

The worst part is, we can't just replace "hash" with "verifier". It depends on the context. "Password Hashing" should become "Password Storage", and "The Hash" should become "The Verifier". Ugh.

[defuse]

I think this can be done in the shortest amount of time as follows:

• Change all "validate" to "verify" manually.
• Take a break
• Change all "Password Hash" to "Password Storage" manually.
• Take a break
• Review the list of remaining "hash", to ensure they can all be replaced with "verifier".
• Change any that actually should be "hash" to "ducks"
• Manually replace all "hashes" with "verifiers" (only 21 of them)
• Take a break
• Write a script that replaces all "hash" with "verifier", preserving case, and run it.
• Change all "ducks" back to "hash"

[defuse]

Actually, it's probably a lot easier to tackle this one file at a time.

[defuse]

Got PasswordHash.php and PasswordHash.rb done.

[sarciszewski]

Hmm, this is tricky. Most people think "we need a strong hashing strategy", and the phrase "secure cryptographic storage" is almost never uttered outside of infosec certification exams.

We would need to check with @ircmaxell but I believe this is the reason PHP opted for password_hash() and password_verify() for the bcrypt wrapper nomenclature.

[ircmaxell]

Well, here's my view:

It is definitely a cryptographic hash. It fits every property of a a cryptographic hash function:

• Indistinguishable from an ideal random function
• Deterministic PRF based on inputs
• Resistant to collisions
• resistant to preimage attacks (1st and 2nd order).

The difference comes in usage. Normal cryptographic hash functions are designed for speed when used in MAC operations. KDFs on the other hand are designed to be slow and used in dedication based usages.

Therefore all KDF functions are cryptographic hash functions. All hash functions are not KDFs, due to speed.

Now, the normal user (someone who hasn't studied crypto) won't know the difference. All they typically understand is "hashes are one way". And that's why I kept the hash name.

Could there be a more accurate name? Perhaps. Is it worth potentially confusing or mislrading the user base that would benefit most from this? That's the question...

My $0.02 at least...

Anthony

[defuse]

I disagree that what we're returning is a cryptographic hash, since it's actually the output of PBKDF2 encoded alongside the salt, iteration count, etc. At a lower level, PBKDF2 isn't a hash either because it's keyed, so it's really a PRF (or PRF family depending on your crypto terminology, both are valid) where the salt is what's used to select the random function.

That said, I do think keeping the terminology consistent with other libraries is important. So I think we should revert to using "hash" even though it isn't technically correct, in favor of ease-of-use. The only non-nit-picking argument for using "verifier" over "hash" is that the user might think what they're getting out is really a hash, with all of the properties of a cryptographic hash, and then use it in some stupid way like as a checksum for a cookie... but I don't think that's likely to happen.

So I'll revert to "hash."

[defuse]

Done in 133147f4dd

[defuse]

Oops, I forgot to stage everything before I commited, most of it is in here: 93e9016d819bde1