I have SSL on my website....when the user logs in from a http page the form action is sent to https page, would this still secure the posted data?
Or would it be better to have the form and the page it is posted to both SSL?
Thanks
No you don't. As long as the form submits to an SSL page then that HTTP request/response is encrypted. Your users may not know that's going to happen, but that's how it works.
blowdart
2009-11-16 22:02:14
And what about redirects when/if authentication fails? With possibly cookies and session data? It is not by coincidence that almost all site use ssl on their login form. Yes the ssl handshake will take place before the data is sent but you never know if you are not going to be redirect back to this form page with critical data.
Aurélien Bottazzini
2009-11-16 22:20:17
What about them? What if the moon was full and you're bitten by a werewolf? Hypotheticals still don't make your answer correct. You've changed to a whole different question, which is around information leakage and poor management, neither of which is easily solved by blithe application of cryptography. The reason most sites put SSL on the login page, if they're using SSL (which isn't most sites) is the lock reassures users.
blowdart
2009-11-16 22:24:17
I am just trying to keep the global problem in mind that's all. I prepare for the worst, and hope for the better.
Aurélien Bottazzini
2009-11-16 22:34:23
+3
A:
Yes the transmission of the form data is still secure. You can use a network sniffer (Fiddler, NetMon, ...) to validate this. But for the user experience you should still put your login form on an SSL site. That way they see the "lock" icon in their browser. Also, there's no guarantee that the form hasn't been tampered with if you don't use SSL (as Adam said).
David
2009-11-16 21:55:08
+3
A:
It is absolutely necessary for both the page with the form AND the page being submitted to to be HTTPS. Unless the page with the form has HTTPS, you can make no guarantees about where that form is submitting to. It may not actually submit to an HTTPS page (are you expecting your visitors to view the source) or something may have inserted some malicious javascript to redirect the form to somewhere else. However if the form is also HTTPS then you know that it hasn't been tampered with.
Security is more than just ticking a box saying "I have encryption", it's a whole process.
But here's the important part (and why the only correct answer to this question is "both FROM and TO must be HTTPS) that most people forget: HTTPS (and SSL/TLS in general) isn't just encryption, that is only a part of it. It's about TRUST:
- You know where your data is being submitted to. This includes not just the server hostname but also the identity of who that hostname represents
- You know that nothing has been tampered with along the way
Without HTTPS on the FROM page, #2 above can't be guaranteed (the FROM page could be tampered with) which means that #1 can't be guaranteed. After all, if your form were somehow tampered with, how do you know what that form will do with your data in the end?
Adam Batkin
2009-11-16 21:58:13
Oh tosh, XSS vulnerabilities aren't mitigated by having a page on SSL - malicious script can still get at the form submission address and rewrite it.
blowdart
2009-11-16 22:01:32
That has nothing to do with XSS, it has to do with someone trying to steal your data. If the TO page is in the clear, clearly someone could intercept your data. If the FROM page is in the clear, they could alter the destination of the submission to be anywhere they want, allowing them to steal your data.
Adam Batkin
2009-11-16 22:03:25
You're the one that mentioned XSS "something may have inserted some malicious javascript to redirect the form to somewhere else". SSL does *nothing* to protect against that situation. Nothing at all. Your claim that that if the from page is in the clear is fine, but if your from page is SSLed that can still happen.
blowdart
2009-11-16 22:05:18
SSL would prevent the content from being modified in the network layer. There could still be an application vulnerability, though.
David
2009-11-16 22:08:16
blowdart: why are you assuming that ‘inserting malicious JavaScript’ is talking about XSS? Who needs XSS vulnerabilities when you have MITM, the attack SSL is supposed to guard against? If you don't have SSL on your login page, it's worthless to have SSL anywhere else as by the time you get to the logged-in page which shows as properly protected the attacker may already have your password. This answer is spot on.
bobince
2009-11-16 22:08:32
What on earth does MITM have to do with this? If you have an MITM attack going then you don't use javascript to change the form submit, you rewrite the whole thing at the attacking server.
blowdart
2009-11-16 22:10:31
Would SSL need to be on everypage the user has access to, like members area? or jus the pages which get the username and password first?
Elliott
2009-11-16 22:11:04
Because MITM is more difficult than simple sniffing (which SSL really is all a bout) or XSS or simple script injection.
serialseb
2009-11-16 22:15:12
@Elliot: It only needs to be on the login form and the page that processes the login form. That is, assuming you're using something like session to remember a user, and that you have those session protected (limited to a specific IP, with a timeout, etc...) Also: do not store the username (or password, but that should be a given) in a cookie.
R. Bemrose
2009-11-16 22:18:42
Thanks, I just call a function to check if they are logged in, I havent as yet checked if the IP matches or added timeout. Would I be ok using a session for the users ID and username?
Elliott
2009-11-16 22:19:57