Research reveals reality of password sniffing over HTTP connections
When you load in a login form over HTTP, ‘anything you do after that is a little bit pointless'.
According to a blog post by security researcher Troy Hunt, websites commonly have a login page on an unencrypted page and potentially allow users to have their passwords captured.
Hunt, whose research on security failings by Tesco last summer led to the information commissioner investigating the supermarket chain, claimed that often website owners will say that the password ‘posts' to HTTPS so passwords are secure.
He said: “Loading login forms over HTTP renders any downstream transport layer security almost entirely useless. What people forget about SSL is that it's not about encryption. Well, that's one feature of secure sockets, another really essential one is integrity in so far as it gives us confidence that the website content hasn't been manipulated.
“Anything you load over an HTTP connection can be easily changed by a man-in-the-middle, which is why it's absolutely essential to load those login forms over a secure connection. OWASP is very specific about this in part 9 of its top 10 web application security risks and summarises it well in the transport layer protection cheat sheet.”
Hunt said that he was highlighting this issue, as well as a number of websites he had spotted doing this as "they're high-profile sites yet they all load the login forms over HTTP and post to HTTPS".
He recommended loading a login form over HTTPS, either by linking to a dedicated login page or popping it up in a separate window or even loading a whole site over HTTPS.
“This is all a bit odd really; these sites have gone to the effort of implementing some SSL but then blown it by loading those login forms over HTTP,” he said.
“As we saw with Woolworths (which Hunt used as an example in a video), posting over a secure connection is completely useless if there's no integrity in the login form itself, an attacker may already have the credentials by then if the connection is compromised - which is the very risk they all implemented SSL to protect from in the first place.”
In an email to SC Magazine, Hunt said that the point he was trying to make was in regard to the ubiquity with which this pattern is employed.
He said: “I've seen so many cases where someone has tweeted an organisation about this and received a dismissive response that I wanted to demo the risk as simply as possible. This is not one of those ‘here's all your passwords' risks, it requires effort to weaponise, but as I said in the blog post, that effort protects against exactly the same risk they're concerned about by posting to HTTPS in the first place so it's odd not to do it properly.”
Asked if the reason why HTTPS has not been deployed across websites was because of the impact on the user experience, Hunt said that this was not the case, and there were many places where this is done already.
“I think more websites aren't doing this for the same reasons more weren't protecting authentication cookies before the emergence of Firesheep – the awareness isn't there,” he said.
“Certainly the barriers such as cost and HTTPS support by partners is lowering (and I dare say it's now non-existent in most cases), I put it down more to developers not understanding the risks than anything.”