Reputation: 39
I consider Javascript a security risk, therefore I would like to allow users of my website to login without having to have Javascript enabled.
This brings me to another problem. Without client-side-scripting I have no idea how I can hash the users password at the client side so to avoid plaintext password transmission. How can "pure HTML+CSS" allow me to have a password hashed.
At present it seems to me the only safe option (without Javascript) would be to have a secure(encrypted) ssl/https connection and send password as plaintext?
Anyhow: Is there some way to hash the users password as to avoid to send it over the internet in plaintext.? Is this possible only using client-side-scripting?
[update] I am aware that SSL is maybe the most close to ideal way. (as mentioned in the comments) Anyhow. It would be already an security improvement when at no time a plaintext username and plaintext password would be send via an unsafe channel. The hashes can be sniffed as well and no safty (i.e encryption) can be there. BUT at no time a sniffer will be able to get the unhased version of the username and password. => advantage would be that users will not make public their username/password combination (potentially used elsewhere).
After all it seems like there is no "scripting disabled"-way of (spice)hashing some input-field values. So I assume my question is unsolveable.
Upvotes: 2
Views: 220
Reputation: 10989
First of all, if you are using SSL, then the password is not being sent in plain text. Everything beyond the initial handshake is encrypted, and quite securely at that. Consider that this is the security that banks, the military, government all over the world rely upon daily. I'm not saying that you should trust it just because everyone else does (argument from authority) - I'm just saying that if there were a problem with it, we'll hear about it right away.
Second of all, you don't ever really gain anything by client side hashing. The basic attack you're trying to prevent is a man-in-the-middle (MITM) attack. Whether its someone eavesdropping on the connection, sniffing the password for a replay attack, or actively hijacking the session (i.e. pretending to be the server and the client to opposite ends of the connection), you can't really prevent it through additional security.
If you assume that the attacker can break through your SSL encryption, then any other token that relies on something the client software is doing or something that the server is sending along can be compromised. If its some client-side hash function, then the attacker can either learn what the function is by inspecting the webpage the server sends down or just sniff the hashed value and use it to impersonate the client when the attacker communicates with the server. If there is some secure key or token the server sends down for the client to use and respond with, the attacker can just intercept that.
I think what you're looking for is two-factor authentication.
Upvotes: 2