1

I was looking at Stanford's JavaScript crypto library and realized I could do hashing on the client.

Previously, I've been using PHP crypt() which is concise because with one command - crypt() I generate both a crypt type, random salt, the hash and put these three items into a string( md5, I know it's a bit fast but OK for now, read here ).

Looks like this:

crypt() MD5 hash example:          $1$rasmusle$rISCgZzpwk3UhDidwXvin0

However if one encrypts on the client using: Stanford's Crypto Library, and utilizing their implementation of SHA-256, one would have the added benefit of hiding the password while it is in transit to the server.

However while hiding the password, it exposes the hash in transit which is actually used to do the sql lookup.

I could hash on both ends - client and server to solve this problem. Would this be over-kill?

What is the standard, secure way to hash passwords?

Community
  • 1
  • 1
  • 1
    Short answer: use SSL; don't bother with hashing on the client. Use a configurably slow hashing function like bcrypt. Don't use SHA-* to hash passwords. – NullUserException Nov 30 '12 at 20:44
  • In effect, the hash made on the client side becomes the password. You'd still need to do work on the server side. The client side work becomes pointless, especially when it is sent over HTTPS. – gpojd Nov 30 '12 at 20:45
  • 1
    @gpojd One (small) advantage of hashing on the client is that the server never gets the real password. – NullUserException Nov 30 '12 at 20:46
  • 1
    @pure_code I suppose there's a *minimal* advantage, but you have to consider the problems it brings, mainly that it will alienate all users who have disabled JavaScript, and there's also the added maintenance. If you are using SSL and a proper hashing function (like bcrypt) on the server, you shouldn't bother. – NullUserException Nov 30 '12 at 20:56
  • In other words, there are more real security issues to address. Hashing on the client when you're already using SSL and a proper hashing function on the server is like looking at a steel door on a wood cabin, and claiming that it should have an extra, heavy padlock in addition. – NullUserException Nov 30 '12 at 20:58
  • My application requires javaScript already. I see it as a control issue, I have more control when using a library rather than abiding by an already defined protocol. + I'm wondering how SSL knows what I need secure and what I don't. If it just encrypts everything this would also be in-efficient....I don't have any security issues at the moment...I'm just designing right now. –  Nov 30 '12 at 21:01
  • @pure_code SSL encrypts *all* communications between the server and the client. I wouldn't exactly call it inefficient, but yes, there's some overhead. As you'll learn, security always comes at a price. – NullUserException Nov 30 '12 at 21:06
  • I'm working on a simple bookmarking site. I would imagine that hashing and encryption are the most costly things done as far as processor utilization goes - from a relative standpoint. From an absolute standpoint it would not be too noticeable. –  Nov 30 '12 at 21:11

2 Answers2

2

Honestly? It would be best to hash your passwords on the server side. Then, make sure that your app is using HTTPS (SSL/TLS) so that attackers can't sniff the network and retrieve plaintext passwords that are in transit. For the login page, you can force visitors to use HTTPS by using the following:

<Location /login.php>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</Location>

Obviously, you'll need to configure your web server for SSL before this will provide any security.

Wayne Whitty
  • 19,513
  • 7
  • 44
  • 66
1

The only thing hashing first protects from, is snoopers getting a cleartext of the user's password. Which can be considered a good thing if that user uses that password elsewhere. The snooper can still replicate the POST by passing along the sniffed password hash.

To solve the lookup issue, don't use a password hash to do the lookup. Rather, use the username to do the lookup, and when you get the data back, compare the password hashes. If they match, then you have a valid login; if not, you don't.

You can also hash the hash again on the server side to be sure no one knows your stored hash. There's no overkill when it comes to security.

But all of this still does not protect against a snooper that already has the values that should be POSTed.

As for a standard solution... I'm sure there are as many standards as there are solutions.

Benjam
  • 5,285
  • 3
  • 26
  • 36