Best practices for login pages?

Question

I am working on a single sign-on login page using Shibboleth that will be used for a variety of web applications. Obviously we would like to make this page as secure and usable as possible while limiting the effects of phishing scams.

What are the best practices to keep in mind when designing a login page?

Some questions that have come up around this issue:

• Is it important for the login page to always look the same on every display?
• Conversely, would it be beneficial for the login page to have a random design?
• Is it better for the login page to look the same as all of your other pages or should it have its own unique design?
• If the login page has its own unique design, should it incorporate other constant elements from your site's design (such as global navigation)?
• Is the login page an appropriate place to provide the user with additional content (such as latest news)?
• Are there any additional security features that should be included to help keep people safe?

Answer 1

keeping the same design in your login page will let know your users they are attempting to log in to your page if design change randomly user may think the site has been moved, or they are being victims of pishing. so i would recomend to keep the same guidelines as your content pages

Answer 2

One other "no duh" thing that I still see on a lot of applications I go to, if the credentials specified are invalid, do not indicate which one is invalid. Simply say something like "invalid user/password combination" instead of "invalid password" that will prevent those folks from social engineering to know a user base accessing your site.

Answer 3

A useful tip for come circumstances: You can disable client-side password saving by adding autocomplete="off" to the password field.

That doesn't work on all browsers (if I remember, IE 6+ and Firefox 3+)

Answer 4

include application level dos prevention

Be non-specific with login failures. A generic "Login failed" instead of "Unknown Username".

Use a captcha or other turing test.

Answer 5

Realize that your user is going to spend all of 10 seconds on that page generally, it really doesn't matter what it looks like so long as it is obvious where to put your user ID and password. Other than that just don't be one of those sites that offers to email me my password if I forget it. At least let me believe that it's hidden in a nice salted hash somewhere where you can't retrieve it ever.

Answer 6

No matter what you design, a Phisher will be able to imitate it. Preventing phishing completely is a difficult problem. You will essentially have to have some means of identifying your users before they log in. Some banks do this now. You enter your name, and then they show you an image you yourself have selected, and then, once you are certain it's the same image, you enter your password. This may be a greater level of complexity than what your site requires.

On the technical side, Bank Of America accomplishes this by using a Flash Local Shared Object called PassMark. Your browser silently sends back this data identifying yourself to the Bank. If you delete the LSO, then you will not be shown your image because BofA can't identify you. Even this is still vulnerable to man-in-the-middle attacks.

Answer 7

Seems like a no-brainer, but use HTTPS if the app requires it. Heck, even if it doesn't warrant it because people tend to reuse the same passwords. You can get a SSL cert cheap these days. If they lift a password from your site they can try it elsewhere. Even many banks don't have the login page on a secure line. It posts to an HTTPS page, but there is still no protection of a man in the middle type attack.

I agree with Omniwombat. Phishing is a hard problem to solve well and seemingly impossible to solve it completely.

Answer 8

Usability notes:

Personally I hate when sites put the "forgot password" or "forgot username" or "help" links inbetween the password field, and the Login button. As a keyboard user, I shouldn't have to TAB over them to get to the submit button.

Better yet, also capture the Enter keypress on the password field so that I can auto-submit with the Enter key.

Answer 9

The best i've seen so far in an attempt to stop phishing is a bank's login interface. The login is done in 3 parts, first the user enters their account number (debit card number, credit card number...), the second step will randomly list 1 of 3 questions specified by a user (eg: What highschool did you attend for grade 10), the last part, if the first two are successful is to display an image and some text specified by the user at sign up, with the password field below.

Answer 10

@Joe Lencioni, and everyone else interested in Shibboleth

Your site pages should have the overall same look and feel on each page.

Regarding Shibboleth, and SSO. It is important to note which role your organization is associated with. Are you an Identity Provider - IdP (authenticating the user and then sending the response to the SP), or are you the Service Provider - SP (who will grant authentication based on the response and attributes sent by the IdP.

If you are a SP, you have whatever flexibility you desire to link your users to an IdP for them to login. Many SP create their own WAYF (Where Are You From) page that will redirect the user to the login page of the IdP.

If you are an IdP, you should have a login page that looks familiar to the user so they can login and then be redirected to the SP with the attributes that are needed for the SP to grant proper access.

As far as phishing scams go, it is important to keep Shibboleth metadata current. I believe many Federations recommend downloading metadata every (1) hour.

Many Shibboleth questions can be answered here: https://spaces.internet2.edu/display/SHIB2/Home

Hope this helps you out.

Answer 11

Smashing Magazine has pretty complete round-up about login forms. Web Form Design Patterns: Sign-Up Forms

Answer 12

Think like a user as well as a security guard: if you make them do a captcha every time to login, they're going to get pretty sick of it.

If you're trying to prevent Denial of Service, then maybe make a captcha appear only after there are enough (failed?) login attempts in a certain time period.

Consider using NTLM, OpenID, or Shibboleth to make login as automatic as possible for most users.

Don't make people go to a separate page to register. Presumably you will have username and password fields, and a login/submit button. Just add a "register as new user" button as well, so that new users can use the existing username/password fields. If you need to collect additional details for new users, popup a form (using DHTML, not a popup window) to collect them.