0

So while I was working on my personal project something struk me.

When somebody creates an account on any web service/social media they provide their desired username and password,this is then processed by the server, the username is stored in a BD and the password is hashed and then stored, but that means that the password recieves the password in plain text and then applies a algorythm before storing.

Same thing happens when anybody logs-in right? Of course this can be sent over SSL/HTTPS but the server is still presented with the plaintext that represents the password, hashes it, and compares it to the stored hashed password.

Why isn't this process done client-side? It would be pretty simple for the client to hash his password within the browser using JS I'm sure there has to be some library dedicated to hashing with popular algorythms such as SHA-256.

Maybe I'm ignoring something really obvious or maybe I'm missunderstanding something, so I'm open to correction.

EChan42
  • 111
  • 2
  • Oh wow, I overlooked that question when looking for dupes. It certainly is similar in essence, but my question is different in one aspect as far as I'm concearned. Mine discusses the security of hashing serverside and what the server does with the plaintext password it recieves on signup/signin more than discuss pro/cons of client/server hasing. – EChan42 Apr 25 '16 at 08:26
  • The server hashes the plaintext password. There's nothing much too it. – Daisetsu Apr 25 '16 at 08:30
  • Thomas Pornin made a good answer to your question in that linked question (http://security.stackexchange.com/a/23285/1574) – M'vy Apr 25 '16 at 09:21
  • 1
    But that's not a problem to give the server your password in plain text since you use a unique password for every website ? :) – Thibault D. Apr 25 '16 at 10:24
  • @ThibaultD. I'm not worried about my credentials since I do use a different password for every site. But I'm worried about people using their generic credentials on my server. – EChan42 Apr 25 '16 at 10:27
  • @EChan42 your question, as it stands right now, is "Why isn't this process done client-side?" The answer is in the linked question. If you could differentiate your question by editing it to include these things in the comments, then this question might be able to stand on its own. – schroeder Apr 25 '16 at 14:39

1 Answers1

2

If you do the hashing on the server side, the server (and an attacker with access to it) could read your cleartext password, correct.

But hashing the password on the client does not really help if someone managed to get access to the server - because the attacker could easily alter the javascript source to get your password in cleartext or start bruteforcing the database.

If the server is trusted, then there is no problem if it processes passwords - and if the server is not trusted, then client side hashing won't add much to security.

Using different passwords for each service would be a better and more secure solution for this problem.

Lukas
  • 3,158
  • 1
  • 15
  • 20
  • Thank you for the explanation! Truly insightfull. But my main concern isn't for me but for my "users" I can't trust them to use a different password for everything. – EChan42 Apr 25 '16 at 09:02