Working on the assumption that SSL serves both to encrypt data and to provide assurance as to the identity and legitimacy of the website, should the practice of providing a logon form on a page requested over HTTP be avoided, even when it posts to HTTPS?

The question relates to a post I made yesterday about the Who's who of bad password practices and some of the feedback suggesting that not visibly seeing the certificate represented in the browser before authenticating was fine if indeed the form posted securely.

To my mind, this sells SSL short as you not only lose the ability to validate the legitimacy of the site before handing over your credentials but you also have no certainty that it is posting over HTTPS. I'm conscious the likes of Twitter and Facebook take this approach, but should they? Am I overlooking something here or is this a practice which should be discouraged?

4 Answers
4

Secure Login Pages
There are several major considerations for securely designing a login page. The following text will address the considerations with regards to SSL.

Logins Must Post to an SSL Page
This is pretty obvious. The username and password must be posted over an SSL connection. If you look at the action element of the form it should be https.

Login Landing Page Must Use SSL
The actual page where the user fills out the form must be an HTTPS page. If its not, an attacker could modify the page as it is sent to the user and change the form submission location or insert JavaScript which steals the username/password as it is typed.

There must be no SSL Error or Warning Messages
The presence of any SSL warning message is a failure. Some of these error messages are legitimate security concerns; others desensitize the users against real security concerns since they blindly click accept. The presence of any SSL error message is unacceptable - even domain name mismatch for the www.

HTTP connections should be dropped
If a user attempts to connect to the HTTP version of the login page the connection should be denied. One strategy is to automatically redirect HTTP connections to HTTPS connections. While this does get the user to the secure page there is one lingering risk. An attacker performing a man in the middle attack could intercept the HTTP redirect response and send the user to an alternate page.

It may be worth adding that there are automated tools for doing precisely what the OWASP best practices state: "an attacker could modify the page as it is sent to the user and change the form submission location..." The link includes a Black Hat presentation on the attack.

Technically its still secure - your browser should tell you if it doesn't like the certificate after the SSL handshake but before sending any HTTP data, however as a user, I would be very wary of a site asking me to provide authentication details before it has switched to HTTPS - without some digging around, and some knowledge of the subject, I don't know until after I've sent the information whether the place I was sending it to is secure (or where I was expecting).

Even if I trust the site, this approach can be undermined by a MITM attack no the HTTP page.

your answer contradicts your first sentence: that "Technically its still secure". Problem is, "secure" can mean several different things here.
–
AviD♦Jan 18 '11 at 11:08

1

But of course technically, it's only secure if the site is legitimate and hasn't been tampered with before the credentials have been entered which you can't ascertain when no cert is visible, right?
–
Troy HuntJan 18 '11 at 19:46

3

No, technically it is still insecure, at least against man-in-the-middle attacks. The page could have been modified and might be sending your password off to Timbuktu. Browser warnings are not effective at stopping such attacks. Your last sentence is correct, but your first paragraph is incorrect.
–
D.W.Jan 19 '11 at 7:28

@Troy - "secure" isn't just protecting the confidentiality of the transport, its also authentication, etc.
–
AviD♦Jan 19 '11 at 8:39

To add to the answers already provided. There have been practical cases where having non-HTTPS landing pages allows for attackers to modify the site and grab users credentials. This example, is the most recent that I've seen. In this case it was done at the ISP level, but equally it could be done by wireless hotspot providers or anyone using the relevant tools to carry out a Man-In-The-Middle attack.