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
| ||
|
Date: Fri, 14 Aug 2015 16:12:28 +0200 From: Thomas Pornin <pornin@...et.org> To: discussions@...sword-hashing.net Subject: Re: [PHC] Argon2 improvement thread On Fri, Aug 14, 2015 at 03:22:56PM +0200, Krisztián Pintér wrote: > i don't think that people without understanding what a salt is can > develop secure code Indeed they cannot. But they will try. This is a harsh but true fact: people who develop code for security purpose are a lot more numerous than the people who are actually competent at developing code for security purpose. Which is why it is the responsibility of people who know to design API so as to minimize risks of mishaps. It is all about _improving_ the situation (because fixing it altogether is unrealistic). > unless you want to include generating random salts too. Oh yes I do want that. It is part of the deal. A simple-to-use API that minimizes risks of misuse would offer two functions: one for generating the hash _and_ the salt (and encoding both in a string output amenable to inclusion into string-based systems like an /etc/shadow file) and another function for verifying a password (takes as inputs the password and the string, and outputs a boolean). Such an API can be implemented more or less generically around a core single-call API that expects the salt as parameter and outputs raw binary. However, I think it is important that such an API is provided along with the "reference" implementation, because being tagged "reference" will lower the probability that other people reinvent it poorly. --Thomas Pornin
Powered by blists - more mailing lists