Password hashing (non-SSL)

views:

352

answers:

+5 Q:

Password hashing (non-SSL)

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

+17 A:

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

Kevin 2010-08-11 17:53:20

+1 Real SSL encryption + clear text transmitted passwords. Hash on the backend.

Byron Whitlock 2010-08-11 17:54:41

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

Ishtar 2010-08-11 17:57:45

@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. :)

hobbs 2010-08-11 18:21:07

@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.

Kevin 2010-08-11 18:21:47

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

2010-08-11 18:29:19

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

hobbs 2010-08-11 18:37:01

Sorry Kevin, this is downright wrong.

Joshua 2010-08-11 19:17:33

@joshua then can provide an explanation as to why?

Kevin 2010-08-11 19:19:37

@joshua, your method id flawed.

Kevin 2010-08-11 20:14:02

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.

Justin Johnson 2010-08-12 07:37:29

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

Ishtar 2010-08-12 12:38:50

+1 A:

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.

Tommy 2010-08-11 17:55:22

Excellent link!

Justin Johnson 2010-08-12 07:45:41

-1 his method is not secure, don't give people false hope.

Rook 2010-08-12 18:49:11

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

Tommy 2010-08-12 18:53:06

+1 A:

I always recommend people use SSL where they can, but for completeness, it should be noted that it is possible to perform authentication securely without SSL through careful implementation of HMAC -- Hash-Based Message Authentication Code.

You must be sure to use a cryptographically secure hash algorithm with HMAC (I'd suggest SHA-224 or better), and you must remember that although you can authenticate without revealing the key/password this way, your data still has to be transmitted in cleartext, so this can't be used as a substitute to SSL for things like credit card transactions etc.

Nicholas Knight 2010-08-11 18:15:38

-1 How do you plan on transferring the secret for you hmac?

Rook 2010-08-12 04:14:33

@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.

Nicholas Knight 2010-08-12 05:48:29

@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.

Rook 2010-08-12 15:02:41

@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 2010-08-12 15:18:07

@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 2010-08-12 19:25:36

@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.

Rook 2010-08-12 19:32:14

@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 2010-08-12 19:54:29

@Nicholas Knight I thought you would have deleted this post by now...

Rook 2010-08-18 00:56:08

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

Nicholas Knight 2010-08-18 01:41:41

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

Rook 2010-08-18 01:48:10

@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.

Nicholas Knight 2010-08-18 01:53:15

@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.

Rook 2010-08-18 02:02:05

Have you seen firesheep?

Rook 2010-10-26 20:26:55

@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.

Nicholas Knight 2010-10-29 22:45:11

@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.

Rook 2010-10-29 23:30:38

@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.

Nicholas Knight 2010-10-29 23:53:52

@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.

Rook 2010-10-29 23:56:15

@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 2010-10-30 00:04:52

@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 2010-10-30 00:08:06

@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).

Nicholas Knight 2010-10-30 00:15:30

@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 2010-10-30 04:21:34

@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.

Rook 2010-10-30 10:27:20

@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.

Nicholas Knight 2010-10-30 11:59:00

Your only option here is to re-create what SSL does for your HTTP variable in JavaScript. You would then post the encrypted single variable payload of all the data, same as SSL would. There are some origin related drawbacks and HTTP vs HTTPS behaviours with headers you have no control over, and keep in mind that even your cookies (and session) are sent with each request.

The issue is you're authentication is based on values submitted to the server, which HTTPS encrypts. Hashing the password server side only means that you're now authenticating with a hash of something a user has typed, which means it's still open to the same exploits as if you didn't hash in the first place.

If you have the actual ambition to start working on this monster framework then kudos to you, best of luck, and take a look at the SJCL http://crypto.stanford.edu/sjcl/ as a starting point.

2010-08-11 18:27:14

Joshua 2010-08-11 19:15:50

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

GregS 2010-08-12 00:25:20

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

Joshua 2010-08-12 02:04:37

@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.

Rook 2010-08-12 04:16:37

The started with a constraint of non-SSL. You will never get better than this with non-SSL.

Joshua 2010-08-12 15:17:20

@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.

Nicholas Knight 2010-08-12 16:34:14

@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.

Rook 2010-08-12 18:48:24

@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.

Nicholas Knight 2010-08-12 20:03:09

@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.

Rook 2010-08-12 20:16:24

@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.

Nicholas Knight 2010-08-12 20:20:44

@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.

Rook 2010-08-12 20:22:52

@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 2010-08-12 20:27:25

@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.

Nicholas Knight 2010-08-12 20:29:48

@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.

Rook 2010-08-12 20:30:57

@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.

Nicholas Knight 2010-08-12 20:36:58

@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.

Rook 2010-08-12 20:40:31

@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.

Nicholas Knight 2010-08-12 20:45:08

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

Rook 2010-08-12 20:55:21

@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.

Nicholas Knight 2010-08-12 21:00:20

@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.

Rook 2010-08-12 21:16:56

@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.

Nicholas Knight 2010-08-12 21:22:25

@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.

Rook 2010-08-12 21:25:59

@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.

Nicholas Knight 2010-08-12 21:27:51

@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."

Rook 2010-08-12 21:30:22

@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.

Nicholas Knight 2010-08-12 21:33:04

@Nicholas Knight I respectfully and completely disagree with you.

Rook 2010-08-12 21:35:28

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.

Joshua 2010-08-12 22:12:39

@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 2010-08-12 22:53:27

+1 A:

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

Aragorn 2010-08-12 04:55:51

+1 A:

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

Joshua 2010-08-12 22:19:25

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

Nicholas Knight 2010-08-12 22:55:14

ansaurus

tags:

views:

answers:

Password hashing (non-SSL)

related questions