Everyone tells you that if you have secured your website using HTTPS, then you’re set to go and your customers’ login credentials and data are protected. This is not true. I am going to debunk that myth once and for all. Time and again I come across well-known brands that say they are protecting your data, but in fact they are not. The reason is simple and the fix straight forward, but there continues to be attacks using this security hole.
Going Back to Basics: What are HTTPS and SSL?
In a nutshell, HTTP becomes HTTPS when you layer the protection (encryption) afforded by the Secure Sockets Layer (SSL) protocol on top of it. SSL then encrypts traffic between a user’s machine and a web site. You can use this encryption to protect login credentials against eavesdropping, by ensuring that the credentials are only sent on a connection secured through HTTPS.
Well that all sounds like it will do a great job in protecting user data. But… is sending credentials over HTTPS sufficient to secure user login?
The answer is no.
It all goes wrong with a school boy error in the form of a common flawed implementation. This can be summed up in a few steps:
- The login page is delivered without SSL.
- The user enters their credentials.
- Credentials are sent to the server over HTTPS
Surely that’s secure, because the credentials are protected by transmission using HTTPS?
Unfortunately, this common situation has next to no security and I have seen it time and again on well-known sites that you share credentials and other personal details with (including financial).
Here’s how it all goes wrong:
The first step is the crucial one. This is because the system can be completely by-passed because the login page is delivered without SSL protection. This means the page can be intercepted and modified by a hacker, so that when the user enters their credentials, these can be delivered straight to the hacker, without the user’s knowledge or interruption to their normal login.
This isn’t a theoretical attack and is very easy to implement, particularly over public Wi-Fi. You can get a $99 device called WiFi Pineapple which does the job for you. This is a legitimate device, meant for PEN testing, but it works on the dark side too…
Putting it Right:
The only solution is to deliver all pages where a user enters their credentials using HTTPS. This is set in stone and should always be followed.
Even if you try to embed the login form within an iframe delivered by HTTPS and hosted on a parent page delivered without HTTPS, it is completely vulnerable.
The trouble is, this poses problems where the login form is on a page that includes content from third parties that are delivered from non-SSL sources, some common examples being advertisements and media; incidentally, embedding of third party content carries its own high risks – many ransomware infections are delivered this way, as was seen recently with the Hugo Boss and Huffington Post advert that was used to deliver the infamous CryptoWall ransomware through a vulnerability in Flash.
The only secure answer to this conundrum and to truly protect your users login credentials and data, is to redirect to a HTTPS page that hosts the login or registration form.
The other advantage of this, of course is that is adds some method of letting your users know it’s not a phishing site as they will be able to see the SSL certificate and chain showing your brand name.
To sum up, if you are using SSL and are serious about protecting your users accounts, never deliver any part of your login pages without SSL protection.