2

I'm working on implementing a basic login system (I know, don't roll your own security, blah blah blah) using PHP and MySQL. However, I don't want the user to need to have JavaScript enabled, meaning almost all of the heavy lifting should be done server-side. So I want to hash the user's password before sending it to the server. Basically, I don't want to rely solely on https and ssl to prevent MTM attacks. But I also don't want to use JavaScript for client-side hashing.

I can I ensure that the data I send to the server is hashed or otherwise not plaintext without relying on JavaScript?

Improve this question
4
  • 2
    I can only recommend you don't do that. A home-rolled hashing scheme is unlikely to significantly improve on the security provided by a decent SSL connection. Also if you expect a MITM attacker why would they not just modify the code you're sending to the client to allow them to get access to the password?
    – Rory McCune
    Commented Dec 23, 2016 at 15:27
  • 1
    You can't. Need some kind of executable on the client side to do client side hashing, although you also need to be able to get that executable code to the client without it being tampered with. If you stick to modern versions of TLS, you don't need to client side hash, and with very few exceptions, it gives negligible security improvement, if any, but massively increases the chances of something going wrong, due to more code being involved...
    – Matthew
    Commented Dec 23, 2016 at 15:32
  • You both make good points, and I'm leaning towards not hashing anything on the user side. @Matthew, you mention that you don't have to use client side hashes, with very few exceptions. Do you know of any exceptions?
    – user132557
    Commented Dec 23, 2016 at 16:37
  • 1
    Basically, when you need deniability from the server knowing the actual data. End to end encryption, basically - something like a password manager could verify a master password for a server side store, without needing to try decrypting. In that case, you'd not be relying on the hashing code being transferred from the server over the same channel though, necessarily.
    – Matthew
    Commented Dec 23, 2016 at 16:51

2 Answers 2

Reset to default
3

You're not going to like any of the options. The reason people disable JavaScript is precisely because of its ability to execute all sorts of instructions; the other options for client-side execution (flash, java applets, silverlight) are certainly going to be disabled by someone who disables JavaScript, because they're even more powerful. Your two requirements are in conflict, so you need to decide which one is more important.

Improve this answer
1
  • Disabling Javascript? I feel like we're back in the 90's...
    – wogsland
    Commented Mar 2, 2017 at 16:21
1

I think you don't understand hashing a password before being sent just makes that the new password that is seen by the server trying to verify the login credentials. One thing could be the use of public/private keys to encrypt the password text being sent.

Improve this answer

You must log in to answer this question.