phc-discussions - Re: [PHC] Do we need a common password hashing API?

lists.openwall.net		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 linux-cve-announce 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, 13 Apr 2014 01:32:02 -0400
From: Justin Cappos <jcappos@....edu>
To: discussions <discussions@...sword-hashing.net>
Cc: santiago torres <sat417@...dents.poly.edu>, Justin Quick <justquick@...il.com>
Subject: Re: [PHC] Do we need a common password hashing API?

Some of the arguments of PolyPassHash are not overly sensible outside the
context of this algorithm.   For example, the number of shares, whether an
account is thresholdless or a threshold account, etc.

I think for many of the other algorithms what you say makes sense though.

Justin


On Sat, Apr 12, 2014 at 7:53 PM, Bill Cox <waywardgeek@...il.com> wrote:

> Now that I've got all the entries linking with the PHS API, I wonder if it
> would be useful to provide the world with a real one, something they could
> actually use in their applications.  If I were developing an application
> right now that needed to hash passwords, I'd like to future-proof my code
> by linking against an "official" API, which would allow me to select an
> established hashing algorithm now (like Bcrypt, Script, PBKDF2, or HKDF),
> and easily switch in the future, after PHC winners are announced.
>
> Such an API would need some more parameters than the PHS API, such as the
> hashing algorithm (like PBKDF2), a PRF (like SHA256), and a boolean flag
> saying whether it's OK for the algorithm to clear the password.  We might
> also want an additional data field, or maybe even a generic interface that
> would allow users to hash as much data as they like, similar to the
> init/update/final APIs.  Maybe it would be good to have something for
> dealing with salt and settings string generation, similar to what
> Pufferfish has.  The easier we can make life for users, the better.
>
> This would of course be in addition to the native APIs from the winning
> entries, but as a user, I would personally stick to the generic API if it
> met my needs.  If such an API were to be offered, the sooner the better,
> because we still have people totally winging it out there, who would much
> rather simplify and future-proof their code than hack it like they do now.
>
> What do you think?
>
> Bill
>

Content of type "text/html" skipped