Search code examples
javascriptsecuritysslclient-side-scripting

Merit of Client-Side Password Security Techniques


I understand the benefit of SSL/TLS and hashing and salting passwords on the server side and plan to employ this standard for password security, likely with bcrypt.

What I'm wondering however is whether there is any additional merit to encrypting or obfuscating passwords en route to the server using client side JavaScript in combination with the aforementioned best practice. The reasoning that I have used to justify thinking about this is that admin error (failing to enable mod-rewrite or faulty vhost config) could in the future allow non-HTTPS connections to my server. This would be an additional layer of security to protect users on public WiFi if they somehow manage to connect without SSL/TLS.

Again, just wondering whether there is merit to this approach and if not, why?

EDIT: Additionally, I've figured that at least disguising that a login form is even being received (encode form server side to be decoded by client-side javascript and then displayed via DOM) might be of value especially when up against someone just snooping around in public WiFi for plaintext transactions.


Solution

  • While a method like this might help to slip by the most casual of attackers, it is almost entirely not worth the effort, and can in fact be somewhat detrimental to overall security.

    If your server accepts this obfuscated/hashed/enciphered password as the user's password, then stealing it gives the attacker almost as much advantage as stealing the user's plaintext password; they will be able to authenticate as the user. They might even be able to retrieve the user's plaintext password from the obfuscated string, as they would be able to see exactly what operations were performed on the user's password to obfuscate it.

    In addition, obfuscating the login form is almost entirely useless; any attacker with an ounce of interest will be able to find the login sequence in the network traffic, and will be able to steal the user's information trivially. It might fool something like a wall of sheep sniffer, but only for exactly as long as it takes for someone, somewhere to write a rule for detecting your login sequence. If you have a large enough userbase, or your app deals with sensitive enough information, that will be a very short time.

    In short, don't waste your time trying to solve a problem thats already been solved; spend that time making sure that you have properly configured exclusive HTTPS.