phc-discussions - 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-next>] [day] [month] [year] [list]

Message-ID: <CAOLP8p4YDrTuiqzej_Dm5kXqTvzDq04d9MJy9UgDiJjm8nzNnA@mail.gmail.com>
Date: Sat, 12 Apr 2014 19:53:04 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Do we need a common password hashing API?

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