Serendipity Forums

To many tabs!

Is this something we should think about to be even more secure with Phpass or PBKDF2?
Do we use a large number of iterations to hash passwords?
(I found someone say iOS4 uses 10.000! )

http://www.heise.de/security/artikel/Pa ... view=print
http://www.openwall.com/phpass/
http ://www.openwall.com/articles/PHP-Users-Passwords
http://dev.myunv.com/articles/secure-pa ... th-phpass/
http://www.itnewb.com/v/Encrypting-Pass ... 2-Standard

At the moment, s9y is using phps sha1(), with the output of time() as salt.

Note that using something slower than that, like bcrypt, adds only security in the sense that if the database is stolen, the hash might be attacked and thus the password obtained.

Pro change:
* There are reports about fundamental issues in sha1.
* There are alternatives more expensive to crack.

Contra change:
* Which hash-algorithm should be the alternative? To guarantee the use of bcrypt, probably the best choice, php 5.3.2 is needed.
* We had quite some issues with upgrades when introducing sha1 instead of md5.

We probably should introduce iterations though, or try to use bcrypt when abailable..

onli wrote:We probably should introduce iterations though, or try to use bcrypt when abailable.

Yes, phpass has a fallback and PHP is heading to 5.4.
The article is about slowing down brute_force with a strong hash and many iterations to make it very expensive (by time and, last but not least, money), even in times having clouds, cuda, etc.
This is nothing to think about for 1.6, but in some of the next versions.

Yes, phpass has a fallback and PHP is heading to 5.4.

The last fallback of phpass seems to be md5, which is undesirable.

Hi!

One problem is also that if bcrypt is so expensive, currently s9y does a password check on every page request that is done. If it really takes 0.3 seconds or so to calcuate a single password, that would MASSIVELY impact the s9y pagespeed for someone being logged in....

Regards,
Garvin

Uff. Why do we do that? Makes sense if we can't trust the session, but isn't the password stored in the session for the check?