-1

I am a university student and I have only now reached the part of my degree where we focus on security. The task was very broad in how we were to protect our database and user details. All it said was "you need to store the user's passwords in hashed form.".

I am now wondering if I should perform the hash client side (JS) then send the hashed data to the server to be stored in the database or if I send the password in plain text to the server and hash the data server side (PHP) before storing. I am using the HTTP POST request for both scenarios. (I am under the impression that if you use a POST request, users/attackers cannot access parameters being sent to the server. Is this right?)

On another note, what would be a good hashing algorithm to use in my situation?

Chris
  • 105
  • 7

2 Answers2

0

First of all, hashing on client side is generally considered useless for web applications. Any attacker that would be able to get through the HTTPS and do a MITM attack would also be able to change the JavaScript, so it would send the password in plain-text. Therefore, there is very little to no advantage from hashing on client side. The one possible advantage is, that you would prevent a failure similar to what Twitter is currently going through where the passwords accidentally ended up in logs.

It is a different story for native applications. However, simple hashing does not increase security considerably. There are far better approaches, such as the SCRAM authentication method. SCRAM allows the password being hashed on the client side, however, the client side HASH is not stored in the database, therefore an attacker gaining access to server database would not be able to log-in using just the hash stored there.

Community
  • 1
Peter Harmann
  • 7,728
  • 5
  • 20
  • 28
0

Understanding the purpose of password hashing in this context will help explain why it should be performed on the server and not the client.

The password is not hashed as to obfuscate it from an adversary who is listening to the request; this particular threat should instead be mitigated by using HTTPS. Instead, the purpose is to prevent the password from being trivially recoverable if the database is breached. If an attacker dumps a database of plaintext passwords, they can immediately read and use those passwords (which users may be using on other websites too). When they are hashed (and salted) the attacker has to do more work in order to brute-force the input that generated the hash.

If you hash client side, the hash becomes the password, so there is not a need to crack it in order to access the system. An attacker who captures the hash could just send it as the password and gain access. Unrelated, this type of attack is possible on Windows systems in a pass-the-hash attack, where the compromise of a hash on one system allows it to be used to authenticate against other systems.

Also, the statement:

(I am under the impression that if you use a POST request, users/attackers cannot access parameters being sent to the server. Is this right

is false. A POST request does not prevent access to parameters; sure, they are not in the URL like GET parameters would be, but they are still part of the request body. Without using HTTPS, an attacker could view or modify parameters in either case.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42