9

The login page is the starting point to any web site and the most important thing to authenticate the user.

When I begin to build any web application, I take a lot of time to think about how to design a login page with flexible interface and so secure.

Is there any common advice, tips, or a "must do" list to take into consideration when I begin building the login page? I want general advice, because my DBMS may be Informix or MySQL or SQL Server.

Anyname Donotcare
  • 265
  • 2
  • 8

7 Answers7

13

Modern day version:

  • Use HTTPS for your entire site, including the marketing pages. Add the HSTS header.

  • If your target audience is computer savvy enough, then avoid the traditional username & password login completely. Offload that to a good federated login system, such as multi-provider OpenID, or Facebook Connect or Google's login.

  • For the functionality on your site that has higher security needs (the important stuff) use CSRF tokens.

  • add "secure" flag to all cookies or at least to session ID – Hubert Kario Jul 26 '11 at 18:09
  • 1
    and regenerate session ids on authentication, and set http only flags on cookies and protect your site against XSS and ensure that the files are not writeable and don't use any self-modifying code....the list goes WAY beyond any possible answer here – symcbean Jul 27 '11 at 12:46
10

Here's a few more:

  • whenever you can, avoid reinventing the wheel - if you can, reuse and improve your system from project to project, peer reveiwing each time.

  • keep the password obscured - don't show text on the page, transmit over HTTPS, don't log in the clear on the back end, store safely in database. Basically wherever the password goes, privacy should be maintained

  • do log errors; don't show too much info to users. Specially the "bad password" vs. "bad username" - don't tell the attacker that they have found a valid username, tell them "invalid credentials" or "bad username/password" without specifics. But do, on the back end, log the problems - is this a repeat of a username? what are the characteristics of the current failure? In a high end system, you'd have something watching and alerting admins if the behavior showed attack-like qualities.

  • Clearly show the thing the user is logging into on the page, and provide a link or on page display of terms of use. Do have this vetted with the lawyer/customer.

  • consider a password locking system and what fits for the users. For optimal reuse have configuration settings for # bad logins before lockout and # of minutes of lockout before re-enablement (with a setting for "manual reset only")

  • carefully consider any feature for password reset, these are hard to craft securely.

  • consider your users and anything they may need for authenticating your server - many aren't SSL/certificate savvy, so what can you do to minimize a user giving their password for your site to a hacker?

bethlakshmi
  • 11,606
  • 1
  • 27
  • 58
  • Good answer. What about application vulnerability scanning/testing before the site goes live in production? :) – lew Jul 27 '11 at 02:29
  • @lour - great idea! I was focused more on development "things to do", but scanning/testing is also a very good idea. – bethlakshmi Jul 27 '11 at 14:34
4
  • Use SSL
  • Hash and salt your passwords, preferably using a library instead of rolling your own.
  • Pass data to the SQL server using binding instead of trying to escape strings.
  • Don't output anything that's input -- prevent XSS entirely.

Phishing is another matter entirely.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
4

Skip building your own login page entirely... If you have the option use Claims Based Authentication and identity federation instead: http://claimsid.codeplex.com/ (that link is particular to .NET, but it has a good primer on CBA).

Steve
  • 15,155
  • 3
  • 37
  • 66
2

This page contains a lot of information regarding how to securely use TLS for your website. While there are other concerns for your authentication system (such as password storage, session management etc) this will still provide a lot of good information.

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Michael Coates
  • 31
  • 1
1

to expand on Jeff's 4th point -

  • Validate all input and encode all output - this will prevent the majority of the common attacks currently found on the Internet.

also,

  • Patch your O/S and your applications. When security patches come out for your database, patch them!
Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
0

Great points by others. Just wanted to add keeping in mind Sql injection and using parameterized queries/stored procedures to prevent it.

https://www.owasp.org/index.php/Top_10_2013-A1-Injection

Ashish Gupta
  • 141
  • 1
  • 4