File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Security and the fly likes Hashing Passwords: Client-Side or Server-Side? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Hashing Passwords: Client-Side or Server-Side?" Watch "Hashing Passwords: Client-Side or Server-Side?" New topic

Hashing Passwords: Client-Side or Server-Side?

Jason Ferguson
Ranch Hand

Joined: Sep 16, 2007
Posts: 47
Okay, this post is security related, but doesn't really deal with the security APIs.

My team is implementing SHA-256 hashing of passwords. We are debating which is more secure: hashing a password on the client side (via a javascript SHA-256 function) or hashing it on the server side.

My point of view is that by hashing on the client side, the unencrypted password is never passed across the network. This protects the password from network snooping (which probably protects other applications: people reuse passwords).

One of my more senior coders feels that we are making the application LESS secure by hashing the password on the client side. The hypothetical man-in-the-middle attacker would get the already-hashed password, which they could then feed directly to the server. If the unencrypted password is passed, he thinks, it's safer because the attacker is unlikely to know the salt that is used with SHA-256 to hash the password. Also, using HTTPS would encrypt the password anyways.

He makes a good argument, but now I have this question: is there any value to hashing the password on the client side?

Aryan Khan
Ranch Hand

Joined: Sep 12, 2004
Posts: 290


In your situation where the traffic is encrypted by the underlying SSL, hashing the
passwords on client does not add much value.
Assuming that you were not using SSL, then you required more than just hashing as replay attacks
or MITM attacks could be mounted and alot more.

But there are situations where the attack can mounted even before the SSL takes over; at the
application layer.e.g. Keyloggers or in some situation you have to record data for compliance reasons but have to mask some part of it(more applicable to client-server environment)
etc . In such situation at the very application
level you need to hash/encrypt the passwords and then pass it on.
you can see such an example at : (visit


greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
Also, you can always hash the password twice (or more), once on the client side and again on the server side, perhaps giving you all the benefits of each. Most password-based schemes incorporate an iteration count of how many time the password goes through the hash function. Along with a salt, this can add additional protection for passwords. See for example PKCS#5 or the the 802.11 WPA2 specs.

Nice to meet you.
Bear Bibeault
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63865

If the traffic is protected by SSL, there is no gain to be had in client-side hashing, so it's just a waste of resources. In an unencrypted stream, it will just tell middle-men what the hashed version is.

I can see no benefits to client-side hashing.

[Asking smart questions] [About Bear] [Books by Bear]
I agree. Here's the link:
subject: Hashing Passwords: Client-Side or Server-Side?
It's not a secret anymore!