lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 25 Aug 2013 15:13:40 -0700
From: Alex Elsayed <>
Subject: Re: Terminology goals

Patrick Mylund Nielsen wrote:

> On Tue, Aug 20, 2013 at 5:02 PM, Jean-Philippe Aumasson <
>> wrote:
>> Agree with the need for a name better than "password hashing scheme",
>> or "password hash".
>> IIRC in previous Twitter discussions an idea was to avoid the word
>> "hash" altogether and some people proposed things like "password
>> scramblers". Also, a good name should probably include a connotation
>> of work factor/slowness.
>> Perhaps we should organize a separate competition: The Password Hash
>> Naming Competition.
> Password Storage Scheme?
> Granted, you're not storing the password, but that's what people are
> looking for. I have several articles on password authentication, and by
> far the most popular queries that find them are "password storage", "how
> to store passwords", and "storing passwords securely". Remember, people
> aren't looking for slow hash functions--they often don't know it needs to
> be slow at all. People who *do* know this aren't going to care if it's
> called a hash, a scrambler or a "password twister."
> "Scramble" is correct, but nobody understands what this means, and to a
> lot of people it sounds less secure than "encryption" or "hashing".
> IMO, "pash" is never going to get picked up. At best it's a cute term
> we'll use, at worst it'll cause more ambiguity around "hash".
> In any case, I agree that "hash" is bad, if only because it makes a
> construction suitable for password authentication seem too similar to
> normal hash functions.

I'd go for "Verifier Derivation Scheme", because what it's really doing is 
deriving a verifier from some other data.

That dodges both "password" (when passphrases are often better) and "hash" 
(when it really isn't one). In addition, it fits with the terminology used 
for augmented zero-knowledge password proof systems such as SRP, where 
what's stored on the server is known as the 'verifier' (and in the case of 
SRP is essentially a salted, iterated hash due to the protocol construction)

Powered by blists - more mailing lists