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: Mon, 28 Sep 2015 01:47:48 +0300
From: Solar Designer <>
Subject: Re: [PHC] Interest in specification of modular crypt format

On Sun, Sep 27, 2015 at 09:40:50AM -0400, Anthony Ferrara wrote:
> So my overall suggestion is make it easier on the developer using the
> API, rather than the one writing it. After all, there are going to be
> FAR more people writing a salt string then there will be writing the
> backend implementation. Optimize for the greater use-case...

Here's an idea in the above context:

We can have our crypt()-like API accept both compact and human-friendly
"setting strings", but output only compact encodings.  This takes care
of making it easy for application developers to generate new hashes via
languages' existing crypt() API without waiting for a new API to be
introduced.  It also prevents such application developers from
influencing the actual encoding (order of parameters seen in final
encodings, etc.)  For example:

crypt("password", "$7X$logN=14,r=8")

as well as e.g.:

crypt("password", "$7X$p=1,r=8,N=16384")

could return something looking like:


Of course, crypt() would also return the same string if called as:

crypt("password", "$7X$B5$Pwm/zQAIhEVTKlaoJSA7TQ")

With PHP's password_hash()/password_verify() API, the human-friendly
parsing would need to be enabled in password_hash(), but not
(necessarily) in password_verify().  Currently password_hash() accepts a
numeric $algo, but maybe we simply need to introduce PASSWORD_ANY (any
better name for it?) and have the actual choice made by a $setting
string that will follow.

Then we could also have an API for decoding compact to human-friendly
strings, but it would mostly be used for debugging and such, and it
wouldn't need to already be in place for apps to start using the new
hashes.  And yes, potentially needing something like this for debugging
is a drawback of not using a human-friendly encoding everywhere.


Powered by blists - more mailing lists