On 09.05.14 15:07 , Stefan Fritsch wrote: > bcrypt has a smaller speed-up from normal CPUs to GPUs than > sha256crypt/sha512crypt. This means if you tune the rounds to make > bcrypt give you the same level of security as sha*crypt, bcrypt is > faster. For the normal login on a server, this is not really relevant > (100ms or 500ms, who cares). But in a web server, speed is very > relevant. You may need to do 10000s of password checks per second. You > cannot increase the number of rounds arbitrarily.
This is certainly true for Apache httpd, but Apache httpd is not the only project that uses APR. The sha*crypt functions are basically a standard, are they not? Thus it would make sense to include them in APR. Using them in htpasswd or httpd is another topic altogether, but I see your point regarding performance. I missed the fact that bcrypt has been available since APR-util 1.5.0, my bad. > Therefore bcrypt is more secure than sha*crypt for web servers. I > don't see any reason to add a less secure algorithm. And I didn't > choose scrypt because I felt it was still rather new when I included > bcrypt support in apr. Is scrypt planned for the future? I mean for APR? If yes, also for httpd? > However, there is a contest for password hashing alorithms [1]. If > there is some winner, and after the winner has seen some scrunity from > cryptoanalysts, it may make sense to include that into apr. > > [1] https://password-hashing.net/ Too bad I didn't know about this earlier. Maybe I could have used my knowledge from studying mathematics for once. I know that cryptology is more than just math, but I also had a few cryptography courses when I studied computer science. Cheers, Helmut P.S.: It seems that your mails are not queued by the mailing list server. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
