Password hashing (non-SSL)

javascript security authentication encryption

10,074

Solution 1

Truthfully, you can hash it on the front end, but it isn't going to solve your underlying problem. Since you are going to store the hash for later verification, all a hacker needs to know is what the hashed value is. Then the hacker can send the hashed value to you, and you're system will authenticate it as the correct value. You are essentially sending the password unencrypted to the system.

To be effective at all, the transfer needs to be encrypted through SSL.

Actually, the easy way to get around the hashing issue is to just play the man in the middle attack. Since it's not using SSL, the person using the browser has no way of knowing the HTML content is not from your server. An attacker can simply position his code in between the client and the server and place additional code in the HTML to key log the password. The posted information then goes to the attacker; he or she takes what is wanted (in this case the password), and then forwards the information along to your server. Neither you nor the attacker will know you are not communicating to each other.

This the reason why you have to buy a certificate from a verifiable source. They are verifying that the server you are communicating with is who they say they are.

Related: Poisoning the DNS

Solution 2

Your method seems very insecure. But to approach your questions...

The same way it would be sent over SSL, just unencrypted.
No, MD5 is not good enough, even over SSL. If you are truly worried about security, then why would you choose a cracked algorithm that can be deciphered using a multitude of web services online (this has been the focus of a few sprited debates here on SO).
Even if you hash the passwords before sending them, you are doing this CLIENT SIDE. This means that your hash and your algorithm are exposed and shown to every end user. As a result, a well to do hacker now knows exactly how you are sending the passwords.

In closing, just get at least a $20 SSL cert from GoDaddy if you want to secure your site/text during transfer from client to server. Encrypt your passwords on the server side before storing to your DB.

Solution 3

Maybe you can try to implement the APOP command http://www.ietf.org/rfc/rfc1939.txt

Solution 4

Depending on what you are doing, you might be able to offload your authentication to openid.

View more solutions

10,074

Author by

sweet suman

Updated on June 04, 2022

Comments

sweet suman almost 2 years

How is the password sent from browser to server in case of non-ssl transfer?

I want to use bcrypt to hash password+salt before sending.... but it seems there is no javascript implementation for the bcrypt algorithm...

is md5, SHA-1 good enough?

PS: My site does not store any user personal information.. I just want that user intended password is not hacked as user might be using the same password at other sites that contains his/her personal information
Byron Whitlock over 13 years

+1 Real SSL encryption + clear text transmitted passwords. Hash on the backend.
Ishtar over 13 years

The hashed value is always different, that's why you add a bit of salt. SSL is not the only way to go.
hobbs over 13 years

@Ishtar that doesn't help. If you're actually going to use the hash that's in the user table for auth, you need to get it to the browser somehow before it does the hashing... which means now you're just implementing challenge/response auth really poorly (and still vulnerable to replay attacks). This really isn't a place to mess around if you don't know what you're doing. :)
kemiller2002 over 13 years

@Ishtar, that is not true. The hashed value has to be reproducible to compare it to what is stored. The problem comes from the fact the hashed value is not sent encrypted. I don't need the password to authentication, I need the hashed value in this instance which I can get because it is sent unencrypted.
Incognito over 13 years

@Ishtar what?? No. That's not how hashes work. Adding salt is a method to prevent rainbow-table based attacks on cracking a hash.
hobbs over 13 years

Meant to write "the salt that's in the user table" above. Too late to edit my comment. :)
kemiller2002 over 13 years

@joshua then can provide an explanation as to why?
kemiller2002 over 13 years

@joshua, your method id flawed.
President James K. Polk over 13 years

What prevents an eavesdropper from capturing the session key that you send in the clear in step 3?
vpalmu over 13 years

Nothing. Once the user logs in it's worthless. A man-in-the-middle, however, can breach this.
rook over 13 years

@GregS MITM isn't necessary, the attacker will just hijack the session id and use the authenticated session without needing to know the password. -1 clearly vulnerable, sorry but I give everyone a -1 who proposes a vuln on SO.
Nicholas Knight over 13 years

@The Rook: You need a separate secure (or secure enough) channel of some form, which the Wikipedia article I linked to explains. As I said, this requires a careful implementation, and is not my recommended course of action. That does not make my answer wrong.
Justin Johnson over 13 years

I think what the OP is asking is if hashing the password on the client side to save the user's password from being exposed is worth it. Regardless of what is being sent, if it's not sent of SSL, it will all be vulnerable to a man in the middle attack.
Ishtar over 13 years

Oops. I mean, a good hash function and a bit of salt(different for each user), will keep the password safe. Authentication is flawed, but irrelevant
rook over 13 years

@Nicholas Knight a DH Key exchange would work. However it doesn't matter how the password is transmitted if you are just spilling the authenticated session id. My -1 stays for this answer.
vpalmu over 13 years

The started with a constraint of non-SSL. You will never get better than this with non-SSL.
Nicholas Knight over 13 years

@The Rook: Again, you are acting as if my answer was a comprehensive description of how to properly implement HMAC authentication. It was not. It was merely a pointer in the right direction. A proper HMAC implementation does not have the problem you seem to think it does. In particular, proper HMAC usage has no "session ID" in any normal sense.
Nicholas Knight over 13 years

@Joshua: Proper HMAC usage is superior. It kind of looks like what you describe, but not quite. You need to abandon sessions (or at least not make them the key part of validating a message), hash each message in its entirety with the password and a unique value (basically an initialization vector), and you actually need to perform the hash twice in a specific way. See the Wikipedia article on HMAC.
rook over 13 years

@Nicholas Knight My -1 stays. This isn't the only cryptographic system so solve this problem. You still require a method of transmitting a secret and protecting the session id. This proposed security system is trivial to bypass.
Tommy over 13 years

I believe I said that in my opening sentence. Tell me what is wrong with SSL and server side hashing?
rook over 13 years

@Nicholas Knight your answer does not protect anyone, and is by no means a replacement for ssl. Furthermore this is an incorrect usage of an HMAC.
rook over 13 years

@Nicholas Knight An hmac is an authentication code for a message, what message are you authenticating? Your just transmuting the authentication code without a message. This is meaningless, just like trying to protect the password without trying to protect the session. Don't assume the people around you are idiots that can be easily fooled, read my profile.
Nicholas Knight over 13 years

@The Rook: Whatever message is being sent. e.g. "order X number of widgets shipped to 1234 Some St.". If you don't understand how HMAC can be used to authenticate web interactions, you are not qualified to be speaking on matters of security, much less criticizing others.
Nicholas Knight over 13 years

@The Rook: You are still not understanding this. The session ID is irrelevant, there shouldn't even be one in the normal sense. You need a single-use (and preferably random) IV to prevent replay attacks. That is all.
rook over 13 years

@Nicholas Knight At the end of the day you need a random number (a cookie) to maintain state for HTTP. This cookie is commonly used to reference server side data such as PHP's $_SESSION super global. If at any point the attacker is able to obtain this cookie value and that cookie is corresponding to an authenticated session, then the account is hacked. This is not only a problem with this proposed security system but also a problem if HTTPS is implemented incorrectly, Read OWASP A9 in the 2010 revision.
Nicholas Knight over 13 years

@The Rook: You are making wild and completely unwarranted assumptions about the design of the application and the authentication system. If someone were relying on the session ID to tell them if a request is authentic, you would be right, but my point is that they SHOULDN'T DO THAT, and nothing about HTTP requires your design (a design, I might add, that I view as inherently flawed anyway). HMAC with single-use IVs offers a safe alternative -- every individual request is cryptographically authenticated.
rook over 13 years

@Nicholas Knight 1)Why are you using an Initialization Vector in an hmac? 2)What message are you authenticating? 3)What is your secret? 4)How are you transmitting this secret? 5)How are you preventing the attacker from hijacking the session? My -1 stays.
Nicholas Knight over 13 years

@The Rook: 1) The IV is used to prevent replay attacks (the attacker can't simply capture a message and send it again). 2) The message is whatever the request is. 3+4) The secret is a password or other key, agreed upon through some safe-enough means outside the scope of the discussion. 5) The session does not exist from a security standpoint, the entire message is authenticated before any action is taken by the application in response to the message. Any use of a "session" is a convenience for the application after a message has been verified (not that you'd still be using a session).
Nicholas Knight over 13 years

@The Rook: By the way, I really don't care about your downvote. Have I asked you to reverse your vote? No. Get over yourself.
rook over 13 years

@Nicholas Knight So we are talking about a safe transport layer and your saying the transmission of a secret is outside of this conversion, right..... And for the record IV's are only used in Symmetric ciphers, call it something else. And you don't know why session id's are useful to the attacker and you probably don't understand why xss is used to obtain the document.cookie value. Well this conversation is over because you do not grasp the very basics.
Nicholas Knight over 13 years

@The Rook: The OP didn't ask for a safe transport layer, he asked for a way to not transmit the password in plaintext. I could call the IV a salt, but I won't, because apparently calling it an IV when the entire world knows what I'm talking about anyway annoys you. XSS assumes a threat model not in evidence, and is still avoidable -- the IV is supposed to be generated on the server and retained pending usage in the next message.
rook over 13 years

@Nicholas Knight Read my profile, do you really think I'm ling to you? You should recognize that you need to learn more and be less upset when others point that out. This is a life skill.
Nicholas Knight over 13 years

@The Rock: I really don't care what your profile says -- though as you yourself point out, I shouldn't trust what you say, anyway. And I certainly won't trust someone who brags about being the top-voted in security questions, but deletes answers he gets downvoted on. For the record, though, I don't think you're lying, I think you're inexperienced in the design of web applications and cryptographic systems. Attacking badly-designed systems is not the same as creating good ones.
rook over 13 years

@Nicholas Knight "What I cannot create, I do not understand" - Richard Feynman. For record my exploit that was in the news (theregister.co.uk/2010/05/11/phpnuke_infection_purged) also resulted in a patch in the Linux Mainline. Have a Nice Day!
Nicholas Knight over 13 years

@The Rook: You wouldn't be the first script kiddie to stumble upon a previously-unknown vulnerability, and citing The Register isn't exactly lending you any more credibility.
rook over 13 years

@Nicholas Knight Let me be blunt, read the owasp top 10, especially A9. Do not post a security answer unless you really know the answer, someone could get hacked. Its a serious matter.
Nicholas Knight over 13 years

@The Rook: Let me be blunter: I'm right, you're wrong, and trying to order me not to do something because you disagree with that assessment is unlikely to get you the hoped-for results.
rook over 13 years

@Nicholas Knight Another good idea would be to look into exploiting XSS attacks. Also active MITM attacks such as SSLStrip, Moxie Marlin Spikes Blackhat 2009 talk was awesome. I'm glad i got to see that one in person when i spoke at BH 2009 (BitTorrent Hacks was my talk :). A study in scarlet is also a good paper for PHP security, its a bit old, but still worth while.
Nicholas Knight over 13 years

@The Rook: Let me make this abundantly clear: If your assessment of the security of a proper HMAC solution for authenticating web requests were accurate, fundamental properties of cryptographic signatures would be broken. They are not, therefore you are wrong.
rook over 13 years

@Nicholas Knight I respectfully and completely disagree with you. HMAC's are meant to prevent tampering of a message. Or to quote wikipeida "As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message."
Nicholas Knight over 13 years

@The Rook: It is precisely tampering we are trying to avoid here. We are seeking to ensure, without transmission of the shared secret itself, that a request is coming from an authorized user. HMAC can be used to provide that assurance. We are not here to ensure privacy, merely integrity.
rook over 13 years

@Nicholas Knight I respectfully and completely disagree with you.
vpalmu over 13 years

Perhaps both of you ought to realize this is web programming here. There is zilch to stop a MITM attacker from replacing the code itself with code that uses AJAX to send him a copy of the password.
Nicholas Knight over 13 years

@Joshua +1 for actually describing a valid threat model. It still makes certain assumptions about what the OP is doing, but they're more likely correct. Your bare assertion of not doing better than your original solution is still inaccurate, though.
Nicholas Knight over 13 years

Regardless of JavaScript integrity, it should be noted you'd still be open to session hijack with this.
Nicholas Knight over 13 years

@The Rook: What, because you think it's wrong? I do not cower in the face of bullies.
rook over 13 years

@Nicholas Knight Please read the wikipedia page again. And keep in mind it doesn't say anything about passwords or authenticating users.
Nicholas Knight over 13 years

@The Rook: Your obsession with remaining ignorant of how message authentication is used could be mildly entertaining, but it's well past that at this point. I really have nothing more to say to you on the subject, and my answer is going nowhere.
rook over 13 years

@Nicholas Knight You blow my mind. You fail to grasp even the most simplistic of attacks like xss and session hijacking, yet you insist on giving people security advice. That is all.
Nicholas Knight over 13 years

@Rook: That you think Firesheep would have any impact on a proper HMAC scheme simply proves you truly have no idea how to use HMAC.
rook over 13 years

@Nicholas Knight Even better, just ask a question on SO about the use of hmacs. Like "Is an hmac a suitable defense for replacing https as a defense for firehseep?" You'll get upvotes.
Nicholas Knight over 13 years

@Rook: No one here has ever claimed HMAC to be a 100% general-purpose replacement for SSL, but within certain constraints (which the question as presented did not indicate were not viable), it is possible to use it to ensure message authenticity in browser<->server communications. It has nothing whatsoever to do with cookies, session IDs, or the real-time exchange of credentials (e.g. usernames and passwords). Your religious obsession with the SSL-or-bust mantra does not change that.
rook over 13 years

@Nicholas Knight Look you won't listen to me, MAC is only for authentication and has nothing to do with secrecy. firehseep is all about secrecy and nothing to with message authentication. Don't take my word for it, ASK SO you'll get a fantastic answer and points.
Nicholas Knight over 13 years

@Rook: And you won't listen to me. The question did not specify secrecy. Look at the last paragraph of the question, he just wants to prevent the password from leaking, not the messages authenticated with it.
Nicholas Knight over 13 years

@Rook: I suggest you go back and read through the entire discussion very carefully and with an open mind. You're attacking things that were never there because your own careless reading gave you a bad first impression.
Nicholas Knight over 13 years

@Rook: Watch your language. The password wouldn't go through the HMAC-authenticated channel, and there is no need for a session ID (they're a common implementation detail in webapps, not a fundamental property of them, I've written many that use no such mechanism).
rook over 13 years

@Nicholas Knight Okay so the message M is the POST and GET variables concatenated together? The Password is the key K. When a user logs on he stores K in a persistent data store on the client side. All forms have a onSubmit= which calculates the hmac code for each request sent by the client. The password is never sent, and no session id is required. Replay attacks can be mitigated by a sequence id. The attack: append a script tag to a client's page load which grabs the password from the persistent data store. Conclusion: completely worthless.
rook over 13 years

@Nicholas Knight further more I don't believe you should inform me on how I should exercise my constitutional rights, but this is a non-issue.
Nicholas Knight over 13 years

@Rook: Possible mitigations include not doing traditional page loads. And you have no rights here, merely privileges granted at the whim of StackExchange. This is a privately run website, neither the US-specific First Amendment nor any other supposed "constitutional rights" apply.