Excellent advice Richard, thanks for posting it :) Jevon
On Mon, Feb 1, 2010 at 8:28 AM, Richard Clark <[email protected]>wrote: > 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]<nzphpug%[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]<nzphpug%[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]
