As a general plea to everyone on-list, and not specifically to you, please don't invent your own crypto systems for use in production.
This advice applies to magical combinations of existing well known systems as well. Specifically, in this instance, the salt in a one-way hash should not be derived from the password. The purpose of the salt is two-fold: 1. To impede the use of pre-hashed dictionaries for attacks 2. To prevent visible password collisions - ie, where two users have the same hash and therefore can be assumed to have the same password Your approach only solves problem 1, while leaving problem 2 in place. This is why the unix password file has exposed, random salts, rather than hidden derived salts. A unix file password often looks like this (each component of the hash is separated by $) tango:$1$QNRcN5Qp$G9GHQQkjJCScefX72moVy.:14212:0:99999:7::: The 1 means the MD5 algorithm was used The next section, QNRcN5Qp is the randomly generated salt The final section, 9GHQQkjJCScefX72moVy is the hash of the password and the salt combined Unless you've done plenty of research into this stuff, and at a minimum read Applied Cryptography by Bruce Schneier from end to end, don't mess around with crypto - the number of subtle ways you can leave your clients and users exposed is simply too enormous for the risk. Use well-known, existing libraries where-ever possible. Never invent your own algorithms for production use. Never use cryptographic algorithms or functions for purposes they were not explicitly designed. There are too many examples of developers failing these tests: 1. Failure to correctly salt hashed passwords makes exposure of weak passwords on db compromise almost inevitable. 2. Use of raw SHA1 to sign data, instead of its HMAC form, leaves the signature exposed to extension attacks 3. Failure to use signatures on encrypted data leaves data contents exposed to blind changes Take the security of your users seriously. Do it properly. It doesn't take long to implement a proper password function in comparison to a cheap sha1(), and the security difference is significant. Regards, Richard. On 1 February 2010 08:03, yeosteve <[email protected]> wrote: > SHA1 is just as easy to crack now, apparently. Salted SHA256 is the > way to go, perhaps something like > > $pwd = $_POST['pwd']; > $salt = sha1(md5($pwd); > > $encrypted = hash('sha256', $pwd.$salt); > > Noone's going to be able to use a reverse lookup to get the original > password, if they do get into your database, and if anyone can see > your code to see how you mixed things up, you've lost anyway, but I'd > be interested to see how others do this. > > Steve > > On Jan 31, 5:15 am, "aaron v1.4.10" <[email protected]> wrote: >> That was really interesting. Did you have a link to a list for the top >> 1000 passwords? >> >> On the topic of passwords, now that md5 can be cracked in seconds, I >> guess using SHA1 is now considered best practice. Perhaps it's time to >> have a password weakness feature (code anyone?) > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
