How to Make a Secure Login Form with SSL

Most web developers know that if their users enter a username and password to login to a site that isn't secured by an SSL certificate, an attacker can see their username and password in plain text. But making a secure login form isn't always as simple as it sounds and many large web sites have done it incorrectly. Though it is often misunderstood, there are good ways and bad ways to secure your website's login form with SSL.

What are the risks? If an attacker can easily view someone's username and password, he can impersonate that user, and do massive damage by buying products, transferring money, reading email, etc. But there is a far more dangerous possibility: Because (ahem, unintelligent) users often use the same password on many sites (using the same password for their bank account as their Facebook account), an attacker can potentially compromise many other accounts. If you let people store a password with you, you must take responsibility for protecting it, even if the security of your own site isn't critical (e.g. a forum).

How NOT to make a secure login form

Let's look at two common mistakes web developers make when it comes to creating a secure login form:

Not securing the login form at all

Not securing a login form with SSL

Not securing a login form at all is the most common mistake on the web. Unless you don't care if someone knows your visitor's usernames and passwords, or unless you use one of the alternative methods of authentication listed below, you need to use SSL on your login pages.

Putting the https login form on an unsecured http page

For a high-traffic site, SSL takes more processing power. So why not put the login form on an http page (say the homepage) and have the form submit to an https page?  That will indeed encrypt the login information when it is submitted, but there are a couple of problems with this approach:

  • There is no way for a user to know that the login information is going to be encrypted (Without studying the source code for the site). Internet users have been trained to check for the "golden lock" icon (or more recently the "green bar") to ensure a web session is encrypted before submitting sensitive information to a site. This is important to protect against phishing attacks. Removing that visual cue (even though the submitted information is encrypted), makes it look like the form is insecure.
  • The form's action could easily be changed to another URL by an attacker. Because the login form page is transferred over http, a man-in-the-middle attacker could simply inject a different URL for the form to POST to. The user would have no idea until the username and password were already sent to the attacker. An attacker could even inject some JavaScript code to send the username and password to the attacker without the user knowing that anything unusual happened.

The most popular examples of this are Twitter and Facebook:

Twitter login on HTTP

Facebook login on HTTP

Those forms do actually encrypt the login information, but there is essentially no way for the user to know that. Do you think that is would be difficult to execute a man-in-the-middle attack on an http page with a login form? Well it isn't. There are even free automated tools, like SSLStrip, to do it. The only difficult part is becoming a man-in-the-middle on most networks.

How to create a secure login form

Now that we know how not to secure a login form with SSL, let's look at how we should do it. For convenience, many large sites and banks used to put their login form directly on their unsecured homepage. Fortunately, many (including http://www.bankofamerica.com/ and http://www.chase.com/) have changed to a more secure method that we can learn from. Even if we go to their homepage with http, it forwards to an https page. In combination with an EV SSL certificate that displays the unmistakable "green bar", the chance of a man-in-the-middle/phishing attack is virtual non-existent.

Secure HTTPS Login on PayPal

There are basically two options for creating a secure login form:

  • Make a separate login page that can only be accessed with https and (of course) submits using https
  • Always enforce https on the homepage and include the login form there. This makes it more convenient to log in and more secure because users are more likely to bookmark the https homepage than a separate login page.

The OWASP SSL Best Practices state it clearly:

Login Landing Page Must Use SSL
The actual page where the user fills out the form must be an HTTPS page. If it's 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.

Other options for creating a secure login form

What if you don't want to force https on the login page or what if you don't want to buy an SSL certificate at all? There are now several alternatives that allow you to securely authenticate users without having to do the work yourself:

  • Facebook Connect. Virtually everyone has a Facebook account and Facebook has made it easy for you to authenticate users using their Facebook username and password. The authentication happens on Facebook's own site (properly secured with SSL) so it is completely secure and means that users don't have to remember another username and password just for your site.
    Facebook login button
  • OpenID. Similar to Facebook connect, OpenID allows users to authenticate on another site and there are many OpenID services available now, though it isn't as popular as Facebook.
  • Twitter. Twitter also offers an API that allows your users to log in securely on their site using their Twitter account.

Securing your login form correctly with SSL is really only one small part of securing your site, but without it, you are giving your users a negative impression of security. By doing it properly, you are helping all web sites be more secure by reinforcing user expectations.

Originally posted on Sat Jan 29, 2011

Comments (10)

  1. krishnaTORQUE:
    Jun 23, 2013 at 07:18 AM

    What if I use SHA1 & MD5 both at a time for encrypt user's password? I do not have much knowledge about ssl. Would you like to give me a valuable details about it? That would me grate. Thank you.

  2. mark:
    Jan 14, 2013 at 05:57 AM

    Sort of interesting article that doesn't actually answer the question it poses. How do you "Make a Secure Login Form with SSL". The answer is not in this article.

  3. Robert:
    Oct 12, 2012 at 08:15 AM

    Good point, Patrick. :) I fixed that.

  4. Patrick McCalder:
    Oct 10, 2012 at 05:56 PM

    Am I the only one amused to find that this very page has a login form that does not use SSL?

  5. thk:
    Feb 19, 2012 at 04:59 PM

    If you used ajax to retrieve the form via https (which then posts to an https endpoint), but your ajax code/initial landing page were served via http, then the ajax code itself could probably be modified to load a different form with a different endpoint... so maybe it's best to just serve the whole landing page via ssl, all or nothing

  6. Abdhesh Mishra:
    Feb 02, 2012 at 01:29 AM

    Thanks for the information.

  7. Wright Computing LLC:
    Apr 27, 2011 at 11:39 AM

    Thanks for the post this really helps. I think I will set up the site with the SSL homepage to make sure it is secure

  8. TrojanCentaur:
    Mar 13, 2011 at 09:12 PM

    Wouldn't work. The original HTTP page (and other resources) can be altered and the AJAX code modified to retrieve a false form. There would be no way of knowing short of checking the source code for modifications (and who does that?)

  9. Robert:
    Feb 16, 2011 at 08:12 AM

    Thanks, Moz. The problem is that if any part of the login page is returned to the visitor over http (even if the login form submits using https with AJAX), an attacker can change the URL to be http or inject his own AJAX script that silently send the login information to him.

  10. Moz:
    Feb 16, 2011 at 02:52 AM

    Cheers for the info. Have you ever thought about using AJAX to return a login form and then submit it over https? Would that be a way around having to use https on every page? Moz





Allowed tags: <b><i><br>Add a new comment: