views:

275

answers:

6

Hey just a quick question for any experts out there. I have a site that lets users interact through messages and to sign up you just make a username and password, verify your age, and optionally, add an email. There isn't really any sensitive information I suppose. Is it worth using https. Will it prevent session hi jacking and will it hinder performance?

+3  A: 

It is worth it at the very least if you transmit passwords and email addresses, or any other private or personally identifiable information. Session hijacking is possible if there's any non-HTTPS communication, but that's a risk many websites are willing to accept, and depends on your situation.

Performance issues depend on your hardware and your stack, but there will be "some" performance hit from HTTPS vs HTTP. It's not enough to stop you from protecting passwords and sensitive user information.

quixoto
thanks for the advice.
Scarface
A: 

I've thought about this before as well. I would think you would want a secure connection when users are logging in or changing information.

Kevin
+14  A: 

I think that as soon as you have some kind of login handling you should protect the password of the user. You can do that either through https or by using http digest authentication.

My main point for encryption is that quite a lot of your users will have the same password to your site as they have to their bank account or something similar. Even though the information at your site is not sensitive, the passwords may indeed protect something important.

Anders Abel
appreciate the expertise, I think both you and dan story's answers are great, I upvoted you guys.
Scarface
-1 After the user logs in the attacker will just hijack the Session ID. The entire session must be protected with https, this is in the OWASP top 10. I wish i could give another -1 for the digest auth, because its even less secure.
Rook
see my comment on answer rook.
Scarface
+19  A: 

Anytime you use a username/password you should absolutely secure the entire session with HTTPS. The cost to you is fairly minor compared to the potential cost to your users if their passwords are exposed. Research consistently shows that people use the same password for nearly every system they access.

Additionally, beyond the risk of password exposure, consider that your site is a communications tool. What's the potential risk or harm to your users of being impersonated? Of having malicious messages sent under their identity?

It's just not worth the risk. Secure the transport at the very least.

Dan Story
great answer, thanks man
Scarface
-1 After the user logs in the attacker will just hijack the Session ID. The entire session must be protected with https, this is in the OWASP top 10.
Rook
rook what are you talking about, can you be more specific lol. How can you use https through a specific port, and only protect part of a session. How is the answer wrong, he is just recommending protecting server interactions through a encrypted protocol. Isn't the session automatically protected with https if that is what your server is using to communicate?
Scarface
I think he thought I was suggesting only protecting the login page with HTTPS. That was absolutely not my intent; once you prompt for a sign in, the entire session must be secured until the user logs out.
Dan Story
I am sorry, I am kind of noob at security, but doesn't https do that automatically if you configure your server to use that protocol since all interactions go through encrypted communication. What do you mean by secure entire session?
Scarface
Sorry guys i thought it was obvious. Every http request has your session id or "cookie". If the attacker can get this value, like by sniffing the line, then they can use it to authenticate as if they had already provided the username/password. Please read the owasp top 10, this is clearly laid out under session violations: http://www.owasp.org/index.php/File:OWASP_T10_-_2010_rc1.pdf
Rook
@Scarface If you simply secure your entire site using HTTPS, you don't need to worry about this. Many high-volume websites are divided into multiple server clusters, one using HTTP for non-sensitive content and one using HTTPS for sensitive content. The advantage of doing it this way is that you save the bandwidth and CPU overhead of encryption; the downside is that you have to be very careful how you bridge the two clusters to make sure secured content never leaks to the non-secure servers.
Dan Story
@Dan, YES THANK YOU. You must protect the **ENTIRE** session.
Rook
Thanks a lot guys really appreciate you breaking it down. That really makes sense now Dan, appreciate that comment.
Scarface
A: 

For some people, passwords and age would be considered sensitive information, though. Are you prepared to deal with some people who may have a different view than you?

JB King
+3  A: 

Yes, SSL/TLS is required to maintain a securely authenticated session. If you have a login, then the login's post and THE ENTIRE SESSION must be protected by https. It is easier and more secure to forward all traffic to https, even if you have a simple web application.

The problem is that a session id (cookie) can be leaked if you use http. If that session is authenticated then a hacker can use that session id to authenticate with the server without a username and password.

This is clear requirement of The OWASP top 10 A3: "Broken Authentication and Session Management" http://www.owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf

Sending a cookie over http is also a violation of CWE-614 and CWE-311.

Rook
thanks for breaking it down.
Scarface
@Scarface Your welcome, you should award the answer to me. Becuase the top 2 are incorrect, someone could get hacked.
Rook
Note that this matters most if anybody cares if there's a little spoofing going on.
David Thornley
@David I guess you have never been to Defcon and witnessed the mighty Wall of Sheep.
Rook
@The Rook: The appropriate degree of security depends on things like how much it costs in time and inconvenience and equipment and how important it is. If you got into my OpenID account, you could log in here and say stupid and embarrassing things under my identity, but I could get that fixed. If you got into my eBay, or Paypal, or bank accounts, I'd consider that far more serious.
David Thornley
@David https is the only way to protect your session. You're more welcome to ignore other vital parts of the OWASP top 10, would you like to argue about the merits of patching sql injection and xss? Is your server not even worth $30?
Rook
@The Rook: In what way is allowing session hijacking on a discussion forum going to cause my server to disappear? If malicious input can trash it, it can come from somebody who hijacked a session or somebody who created an account just to do this.
David Thornley
@David, Easy. So you are the administrator of this said forum. You are at your local "Harbucks Coffee and Eatery" which has free WiFi. You login and your password is sent via https, then immediately afterwords your session id is sent in clear text. A hacker is running something like Hamterized (http://www.tgdaily.com/security-features/33258-defcon-2007-the-wall-of-sheep-gets-%E2%80%9Chamsterized%E2%80%9D), he takes your session id, and then uses javascript:document.cookie='stolen session', to login and then delete all posts. This is why gmail now uses https for everything.
Rook
@The Rook: Tell me why the intruder can't make his own account. From the question, it sounds like you make up an account name, a password, and an age, and you're in. That's the right thing for gmail to do, of course, since email is generally a more important thing than a web discussion forum.
David Thornley
@David, but your account is the one that's valuable. But that's obvious. Please take this issue up with owasp: https://lists.owasp.org/mailman/listinfo/owasp-topten and Mirte: http://cwe.mitre.org/data/definitions/614.html .
Rook
@The Rook: The account may or may not be valuable. Whatever somebody else does to it may or may not be reversible. Therefore, it may or may not be worth protecting against session hijacking.
David Thornley
@David At about this point I think you know your wrong.
Rook
@The Rook: Actually, no, I think you're being too black-and-white. Different solutions have different security trade-offs. The site in the original question looks like it needs minimal security. BTW, why would you think I'd do admin functions in the clear over wifi? It didn't occur to me at the time that that's what you were talking about, since it's obviously a bad idea. As an admin, I need more security, and I'm more willing to do things in a manner that may be less convenient but more secure than the average user.
David Thornley
Come on David just admit it, I taught you something.
Rook