At 2:02 PM +0000 2/9/09, Stuart wrote:
2009/2/9 Michael Kubler <mdkknd@xxxxxxxxx>:
These days SHA should really be used instead of MD5, and you should be
SALTing the password as well.
Here's a great guide : http://phpsec.org/articles/2005/password-hashing.html
Good advice. I would also advise against stripping and trimming
anything from passwords. By removing characters you're significantly
reducing the number of possible passwords.
I read the article and didn't find any objection to it, but before we
all jump on the SHA bus, why can't we do this:
1. Allow the user to pick whatever password they want.
2. After entry, add a token string to it, such as 'a14fmw9'.
3. Do a M5() hash and store the hash the dB.
When the user wants to log back in:
1. They enter their password.
2. We add the token string ('a14fmw9') to it.
3. Then we M5() the string and compare that hash with what's stored.
That will work.
Furthermore, if the token string is stored in the script, or in a
configuration file, and not in the database (as suggested by the
author), then if someone obtains access to the database, all the
dictionary and other such brute force attacks will be more difficult
because the hashes are more complex than one would normally expect,
right?
If not so, then where am I wrong?
Another scheme would be simply to use the user's password and
generate a hash. Then reverse the users password and generate another
hash. Then shuffle the two hashes, or take pairs, or quads, or any
number of other techniques to obscure the hash. As long at the
process can be reversed, it will work.
From my limited view, a minor amount of work can throw a major monkey
wrench in any method of trying to crack a hash -- am I wrong?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
