7

I have just realized, that my web application is sending unencrypted passwords from login form. It's just like that -- I've analysed, that string sent by user from login form is hashed with MD5 (which is wrong itself -- but that's a different story) on server-side and compared after that (passwords in DB are hashed).

I have raised the issue in my internal issue tracker, that this should be replaced with using Javascript lib to hash password directly in login form, so it would never be sent in plaintext . I have immediately received a comment from one of our developers, that this is wrong, because it requires user to have Javascript enabled. And, that problem should be solved by using HTTPS, not by hashing passwords at client-side.

I have my personal opinion about all this "it require Javascript to be enabled" crap, which is not important at this point. But, I'd like to get a clear answer, which one of us is wrong. Is it really forcing user to enable Javascript a bigger sin, than sending his/her password plain to the server? And what about situation, when my application will be run on HTTP, not HTTPS server (for many reasons)?

Improve this question
0

3 Answers 3

Reset to default
12

From the attacker's standpoint, whether you send a plain text password or a MD5 hash or it doesn't make much difference, as long as sending the same value over again unlocks the door. Remember, getting in is the primary objective, not obtaining the exact value of the password. So if the attacker intercepts the hashed password, sending it again from his box produces the same result -- login accepted. Using HTTPS would be the best solution, as it protects all the data.

EDIT: As for the situation when your application will be accessed over plain HTTP -- well, you are screwed then. Unless you roll your own protocol (NOT RECOMMENDED) to encrypt the password client-side and decrypt, hash, and validate it server-side, the password will be exposed.

Improve this answer
6
  • Actually, you're wrong: it's trivially easy to implement a challenge-response system for the hashed password that would make it quite quite a bit harder to reuse the same hash over and over again. (and with keyed HMAC, you can do even better). The main issue is that it's pretty much pointless anyway: either you're using HTTPS in which case you're not adding any security to the overall system or you're not in which case protecting the password has no meaning since everything else-including session keys - are in clear text making it trivial to hack the user session.
    – Stephane
    Commented Jul 2, 2014 at 12:06
  • Good point with session keys. And a good point in favor of using HTTPS. As for the challenge-response system, I agree it might not be hard to implement it, and I can see the client side of things. I've got a problem understanding the server side in this scheme. Can you please elaborate a bit?
    – Dmitry Janushkevich
    Commented Jul 2, 2014 at 12:47
  • Simply add a challenge in the javascript you send to the client and make sure you write that in your local state. Server generate session state (marked as "challenged"), saves the challenge and sends the modified javascript. Client performs HMAC and sends result along with username, server looksup user name, perform the same calculation and check the result. In order not to store the password server-side, you just store the first half of the HMAC. Of course, that's still a pretty weak password storage strategy.
    – Stephane
    Commented Jul 2, 2014 at 13:45
  • I might have read the "store the first half of the HMAC" part wrong, but doesn't this require HMAC to be constant? If so, what is the benefit? Otherwise, this scheme seems to require a shared secret (might be a password or its hash), which should be stored to reproduce the result of HMAC computation server side. This leaves a possibility of immediate damage in case the DB is leaked (the main reason to keep passwords hashed, right?)
    – Dmitry Janushkevich
    Commented Jul 2, 2014 at 14:13
  • 1
    Even if the same hashed content would always unlock the door, it would still be an improvement over sending a plaintext password if the hash could not be effectively reverse-engineered. If the same password is used on both an http: site and an https: one, a good hash algorithm could prevent passive listening attacks on the http: site from exposing the password to the https: one.
    – supercat
    Commented Sep 28, 2014 at 17:20
8

https must be enabled anyway and you must not use http in your login form. What your developer is saying that by limiting the application to be served as https only (should be configured in the web server) even if the password is sent in clear text in the form, the whole traffic is encrypted and hence the password is safe. That is correct. Even if you hash the password in your browser and then send it via http it can be sniffed and stolen. For an attacker - the stolen hash in this case is just as good as the actual password. Even if he cannot look it up on a rainbow table he can just submit the hash in the login request.

Improve this answer
0

In my opinion sending a cleartext password is a bigger sin and risk because the hacker will need less expertise (i.e sniffing the cleartext password from the server) as compared to using javascript (the hacker will need more expertise). and also, why not secure your cookies instead? like to not mark your cookies as httponly?

Improve this answer
4
  • 1
    How exactly securing cookies would protect from sniffing traffic? The HttpOnly flag only forbids accessing the cookie from JS code within the browser, the cookie is transmitted over the wire nevertheless -- otherwise there is no meaning in setting the cookie whatsoever.
    – Dmitry Janushkevich
    Commented Jul 2, 2014 at 11:38
  • that was a suggestion.
    – H3lp3ingth3p33ps
    Commented Jul 2, 2014 at 11:39
  • Doesn't seem to solve the problem at hand. :-)
    – Dmitry Janushkevich
    Commented Jul 2, 2014 at 11:40
  • Any password protocol that does not perform browser-side authentication of the JavaScript to be executed on the client will be susceptible to a man-in-the-middle attack. I agree with you though that sending a plain-text password over http: is a bigger sin, because that password will not only grant access to http: sites, but may grant access to https: ones as well.
    – supercat
    Commented Sep 28, 2014 at 17:10

Not the answer you're looking for? Browse other questions tagged .