Hi,
I have the password hashed in the database using MD5.
Is it normal to hash the password using javascript before the password to sign in is sent using the POST request in the form?
Is this normal, or will server side hashing do just fine?
Hi,
I have the password hashed in the database using MD5.
Is it normal to hash the password using javascript before the password to sign in is sent using the POST request in the form?
Is this normal, or will server side hashing do just fine?
Most people will just hash it server-side and see to it that it gets transmitted via https. Anyway: The most successfull method of breaking MD5 nowadays is to google the hash. You might want to look for another hashing scheme.
Switch to something else.
I am using bCrypt and it is super easy to use. Rationale:
http://codahale.com/how-to-safely-store-a-password/
Implementation:
http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php
PhPass is another one.
http://www.yiiframework.com/wiki/240/authenticating-against-phpass-hashes-with-yii/
Hey James,
You do not want go give away whatever hashing algorithm you’re using, which you would do if you’re doing it client-side. MD5 with a random salt is adequit in most cases and in my personal experience you don’t gain anything from complicated hashing algorithms when it comes to normal web application user authentication.
As long as your code on the server is safe and you keep your hashing algorithm secret you are safe. And remember, your application security is always as weak as your weakest point of entry, which could be access to the server, access to the database, etc. Many people do put a lot of effort on password hashing but forget about server security completely.
Are you really advising security by obscurity? 
A consumer nVidia graphics card can check 350 million md5 keys per second these days. So salting is not enough.
You need
[list=1]
[*]a truly random salt, i.e. not [font="Courier New"]mt_rand()[/font] or [font="Courier New"]uniqid()[/font]
[*]a slow hash function
[*]strong password policies
[/list]
PHP 5.3 makes 2. so easy there’s no reason not to. Use [font=“Courier New”]crypt()[/font] with blowfish or either of the SHAs, it doesn’t matter, just make the cost parameter or number of rounds large enough, which directly affects how fast a brute-force attack goes.
For 1. you can try the randomness extension. Unfortunately PHP does not provide a platform independent API to the system entropy source that doesn’t depend on certain optional extensions and/or safe mode being off. You can see if the randomness extension works for you. It will throw a warning if it can’t get a quality random number. And it formats a random number as a blowfish salts for use directly in PHP’s crypt().
Number 3. is probably the hardest. And what’s appropriate depends on your application and its users.
It doesn’t matter if the attacker knows what hash algorithm you are using if you use it properly.
On the php website there is an article about safe hashing password: http://www.php.net/manual/en/faq.passwords.php
For me crypt() with blowfish is the best solution.
That’s an excellent hash function. But like the article, you missed the part about the salts being practically unguessable, i.e. properly random.
@Da:Sourcerer: No, I’m simply stating the obvious.
@fsb: It’s a bit tricky to prevent brute force since any string that produces the hash saved in the database will allow access. It doesn’t make any difference if you use a salt or not. Brute forcing could be prevented e.g. by blocking the log in for a period of time after a number of failed attempts.
So for you the best practice is to generate a totally random salt, but you’ll have to store it because we’ll need it each time we want to check the password, isn’t it?
So if someone has access to the DB, he’ll also have all the salt we are using, no?
This is for this reason I like to use a salt like the concatenation between the 3 last characters of the username and the create time for example. It won’t be stored in the DB so even if the DB is hacked, the salt would be safe!
You seem a lot more experienced than me so i’m really open to hear your feedback about it!
If that is really your point, you should stop using MD5 asap. Use a hashing algorithm that is proven to be collision-poor(er). Such as Ripe-MD 160.
Umm… The information you are using to construct the salt is in the DB. This is classic security by obscurity.
Nonsense. A proper implementation should be capable of being known to the attacker and still prevent the attack.
No, its not. You use a slow hashing algorithm. See PhPass or my recent wiki post for examples. The problem with any general-purpose hashing algorithm (md5, sha1, ripe-160, etc) is that they are optimized for speed. You want a SLOOOOOOOW hashing mechanism so that passwords cannot be brute forced within a reasonable span of time (years, decades, etc).
Obviously you shouldn’t rely on that, but why give the attacker hints? This has nothing to do with security by obscurity.
I am using Whirlpool + dynamic salt. But however, usually it’s like in this scenario anyway: http://xkcd.com/538/