Discussion:
[PHC] Verbify "password hash"
Scott Arciszewski
2016-05-22 21:17:28 UTC
Permalink
Hi all,

I frequently find myself telling people, "Don't encrypt passwords, hash
them," but then I have to continue on explaining that you can't just use
ANY old cryptographic hash function, you need to use one of these special
password hashing functions instead.

A lot of clarity and simplicity can be gleaned from choosing a distinct
verb to go along with each major class of cryptographic algorithm, even if
it's an informal vernacular.

This is what I've come up with so far:

* Symmetric-key cryptography
* Symmetric-key encryption
* encrypt
* decrypt
* Symmetric-key authentication
* auth
* validate
* Asymmetric-key cryptography
* Asymmetric-key encryption (wherein you encrypt with
$publicKey but can only decrypt with $secretKey)
* seal
* open
* Asymmetric-key authentication
* sign
* verify
* Key agreement
* exchange / agree / negotiate
(not sure which is easiest yet)
* Other cryptography
* Cryptographic hash functions
* hash
* Password hash functions
* ?????

I'm not the first to propose the naming issue, but my argument is a bit
different: I'm fine with "password hash" as a compound noun. I'd just like
to get some feedback on a verb, for telling developers with little security
background:

Don't encrypt passwords. Don't hash passwords. Instead, ______
passwords.

Some ideas that have come up in discussing this on Twitter:

* PASH (previously suggested by dchest)
* phash (my original suggestion; pronounced "fash"; short for password
hash)
* pulverize
* blend
* puree
* blitz
* nuke and pave (not sure if this one was tongue-in-cheek)


Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
Krisztián Pintér
2016-05-22 21:27:26 UTC
Permalink
      * Password hash functions
        * ?????
    Don't encrypt passwords. Don't hash passwords. Instead, ______ passwords.
i think this came up earlier. my take: stretch. pbkdf is also good,
but long, and not accurate, as we don't always derive a key, we might
derive a verifier.
Scott Arciszewski
2016-05-22 21:48:29 UTC
Permalink
Post by Krisztián Pintér
Post by Scott Arciszewski
* Password hash functions
* ?????
Don't encrypt passwords. Don't hash passwords. Instead, ______ passwords.
i think this came up earlier. my take: stretch. pbkdf is also good,
but long, and not accurate, as we don't always derive a key, we might
derive a verifier.
I like "stretch" as well. Especially since the phrase "key stretching"
is already used in this context, i.e.
https://en.wikipedia.org/wiki/Key_stretching

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
Maarten Bodewes
2016-05-22 22:10:29 UTC
Permalink
Hi Scott,

"Perform password hashing" (yes, that's sidestepping the issue), or
otherwise "perform password based key derivation" (PBKDF2 is password based
key derivation function #2, and PBKDF can be thought of as a generic name
for a function performing password hashing).

I don't like key stretching.

- First of all, a Key Based KDF such as HKDF can also perform key
stretching.
- Second, key stretching is a function that's part of the password
hashing - it's not identical to it. HKDF for instance consists of two
parts: HKDF-Extract and HKDF-Expand. The key stretching would be (part of)
HKDF-Expand.
- And finally, most people would not put a connection between key
stretching and password hashing.

"Phash" is probably the best shorthand. But I'm not sure that there is a
need for one, nor that it will get any traction.

Regards,
Maarten
Post by Scott Arciszewski
Post by Krisztián Pintér
Post by Scott Arciszewski
* Password hash functions
* ?????
Don't encrypt passwords. Don't hash passwords. Instead, ______
passwords.
Post by Krisztián Pintér
i think this came up earlier. my take: stretch. pbkdf is also good,
but long, and not accurate, as we don't always derive a key, we might
derive a verifier.
I like "stretch" as well. Especially since the phrase "key stretching"
is already used in this context, i.e.
https://en.wikipedia.org/wiki/Key_stretching
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
Scott Arciszewski
2016-05-22 22:17:11 UTC
Permalink
On Sun, May 22, 2016 at 6:10 PM, Maarten Bodewes
Post by Maarten Bodewes
Hi Scott,
"Perform password hashing" (yes, that's sidestepping the issue), or
otherwise "perform password based key derivation" (PBKDF2 is password based
key derivation function #2, and PBKDF can be thought of as a generic name
for a function performing password hashing).
I don't like key stretching.
First of all, a Key Based KDF such as HKDF can also perform key stretching.
Second, key stretching is a function that's part of the password hashing -
HKDF-Extract and HKDF-Expand. The key stretching would be (part of)
HKDF-Expand.
And finally, most people would not put a connection between key stretching
and password hashing.
"Phash" is probably the best shorthand. But I'm not sure that there is a
need for one, nor that it will get any traction.
Regards,
Maarten
Post by Scott Arciszewski
Post by Krisztián Pintér
Post by Scott Arciszewski
* Password hash functions
* ?????
Don't encrypt passwords. Don't hash passwords. Instead, ______ passwords.
i think this came up earlier. my take: stretch. pbkdf is also good,
but long, and not accurate, as we don't always derive a key, we might
derive a verifier.
I like "stretch" as well. Especially since the phrase "key stretching"
is already used in this context, i.e.
https://en.wikipedia.org/wiki/Key_stretching
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
Hi Maarten,
Post by Maarten Bodewes
But I'm not sure that there is a need for one,
Compare the two statements:

Don't encrypt passwords, hash them. But not with a general-purpose
cryptographic hash function; you need to use a hash function
specifically designed to perform the slow, salted hashing of a
password. This means don't use something like AES or SHA256, but do
use Argon2i.

-----

Don't encrypt or hash passwords, phash them. For example: Argon2i.

I find myself repeating the same footnotes every time I try to correct
an article or press release about "we encrypt our users' passwords".
My meta-argument is that using the same verb to mean several different
actions is ambiguous and causes confusion for neophytes and opting for
a different verb for every context avoids that problem.

The need for it might not seem widespread, but I'm reasonably sure
that adopting this approach will lead to better user understanding
(i.e. not calling literally everything you can do in cryptography
"encryption").
Post by Maarten Bodewes
nor that it will get any traction.
We won't know unless we try. :)

Regards,

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https;//paragonie.com>
Alex Elsayed
2016-05-24 03:34:52 UTC
Permalink
Post by Scott Arciszewski
Don't encrypt passwords, hash them. But not with a general-purpose
cryptographic hash function; you need to use a hash function
specifically designed to perform the slow, salted hashing of a password.
This means don't use something like AES or SHA256, but do use Argon2i.
-----
Don't encrypt or hash passwords, phash them. For example: Argon2i.
I find myself repeating the same footnotes every time I try to correct
an article or press release about "we encrypt our users' passwords". My
meta-argument is that using the same verb to mean several different
actions is ambiguous and causes confusion for neophytes and opting for a
different verb for every context avoids that problem.
This is a false dichotomy:

Don't roll your own password storage; use a secure password hash,
such as Argon2i.
Post by Scott Arciszewski
The need for it might not seem widespread, but I'm reasonably sure that
adopting this approach will lead to better user understanding (i.e. not
calling literally everything you can do in cryptography "encryption").
Such a term is only needed because you're trying to fit this into a
pattern that puts you in a linguistic straitjacket. By reframing the
problem - and the problem is not encryption, or hashing, it's that people
aren't using Best Practices - the need falls away.

Loading...