Auditing Web Site Authentication

Auditing Web Site Authentication
by Mark Burnett
last updated April 24, 2003

Consider this scenario: you build a Web site that requires some kind of user log-in. You allow users to create usernames and passwords and require a valid username and password to get in to your site. But is your Web site authentication scheme secure? Every time I register at a site, I marvel at the consistently laughable - sometimes pathetic - security among even the world's largest Web sites. As the Web becomes more a part of our personal lives, the threat of fraud and identity theft grows accordingly.

Inadequate user security is a problem that Web developers must address. Perhaps it is lack of standards. Perhaps it is a lack of auditing. This article addresses both of those issues by establishing a standard audit procedure by which to measure your own security. Test this list of questions against your own Web site's authentication scheme and see how it stands.

Does the system require both a username and password?

This one should be a no-brainer, but occasionally I run across a site that requires a password but no username. The problem with this arises if the user tries to set a password that another user has already used. You will have to notify the person that password is already taken and then they will know someone else's password, which, given that usernames aren't being used, may give him ready access to the system.

Does the system allow for, encourage, or enforce strong passwords?

If your security system depends on passwords, then you can only have strong security if you have strong passwords. Therefore, enforce minimum password lengths and do not allow passwords that closely match the username. Using numbers and punctuation characters will make a password stronger, but you can also encourage longer passwords, which are just as effective (see Ten Windows Password Myths). You can also make passwords stronger by allowing spaces and encouraging users to choose pass phrases. Furthermore, allow users to use any keyboard character in a password; don't limit them to characters and numbers. Also, set liberal limits on maximum password length: 128 characters or more.

AOL's ScreenName - which includes AIM, Netscape Network and Compuserve - allows passwords as short as three characters but will allow a maximum length of 16 characters, which is far too liberal on the minimum length and too restrictive on the maximum length.

Does the system allow for password aging and enforce a password history?

Hotmail was born July 4th, 1996 - nearly seven years ago. That's almost 2,500 days at the time of this writing. Now ask yourself, how many of those millions of early Hotmail users do you think still use the same password they set nearly seven years ago? If you do not want to enforce password aging on your Web site, you should at least occasionally remind people how old their password is.

Password histories prevent users from changing their expired passwords, then changing them back again. You do this by saving the last few passwords a user uses. Of course, users can circumvent this by changing their password a few times, filling up the password history, and then setting it back to the original. You can counter this by either having unlimited password history entries or enforcing minimum time periods before users can change their passwords again.

Does the system use easily-guessable or default usernames and passwords?

You should avoid using common, easily guessable, or sequential usernames. Avoiding these will help limit exposure to attacks against specific accounts. You should never assign default or easily guessed passwords to any account; instead, ask users to select their own passwords.

Is it possible to harvest usernames from the application?

Some applications allow the guessing, or harvesting or usernames from your application. If an attacker is able to collect a list of usernames, he can launch a brute-force attack looking for weak passwords. Revealing usernames can also lead to other problems. For example, the forums at groups.msn.com show the user's name with each post. Of course, you would want to know each user's name, but consider that having a user's name means you also have their e-mail address and Instant Messenger name. A spammer could easily spider the site and gather millions of account names.

Do error messages provide too much information about usernames or passwords?

Once I was logging into an online banking site, but mistyped my password. I got an error message stating that my password didn't match. It also told me that passwords are four characters long, can only be upper case letters or numbers, but cannot start with a number. While that information may be useful, it also lets a hacker know the limits of the password key space. Another Web site issued a notice that my password was made up of the last four digits of my Social Security number, which is hardly private information. Make sure your error messages do not reveal too much information about the nature of a password.

Does the module detect and prevent brute-force guessing of usernames or passwords?

To prevent intruders from launching brute-force password guessing attacks, take measures to detect and prevent these attacks. To reduce exposure to brute-force attacks, lockout accounts with high numbers of failed logins and be aware of total failed logins across the system.

Does the source code contain any hard-coded username or password checks?

If it does, remove them.

Does the system make use of obscurity to authenticate users?

I once saw a system at an e-commerce Web site that allowed users to access private files only if they knew the long, obscure URL of the files. This is similar to hiding a key under a doormat: you are safe only if people don't know you hide the key under the doormat.

Can users change their username?

Occasionally, users may need to change their username for one reason or another without creating an entirely new account. Some systems, however, do not allow this because the username is the primary key in the database. eBay allows users to change their username so they won't lose the hard-earned feedback on their account. On the other hand, you must carefully consider the effects of allowing users to do this. A user may want to change their username to avoid a bad reputation, and you certainly do not want to facilitate that.

Do you require e-mail addresses for usernames?

Microsoft's Passport requires that you set your username to a valid e-mail address. Usernames that are e-mail addresses may allow spammers to harvest e-mail addresses and make it difficult to change a username. It also forces users to change their username each time they change their e-mail address. You should allow users to use e-mail addresses for their account names, but do not force them to do so.

Do users automatically receive online accounts even though they will not use them?

Many banks automatically provide online account access for all their account holders, even if those account holders don't need to access their accounts online. Maybe these customers don't have Internet access, don't want to bother with learning how to use it, or don't trust their bank's security. Providing access that is not used can be dangerous because it results in unattended online accounts and many users who are not even aware that they have even have online accounts.

Can users easily change their own passwords?

If you don't make it easy for users to change their passwords, they are less likely to do so. Changing passwords should be an obvious and convenient feature of any authentication system. One thing you can do for users when their password gets old is to put a small reminder at the top of the page, including a link to change their password.

Are users required to re-authenticate before and after changing a password?

When you allow users to change their passwords, have three fields: the old password, the new password, and verification of the new password. This prevents intruders from changing passwords on hijacked accounts. Say, for example, that someone logs in to a Web site, and then leaves the site to browse to other sites. Suppose then that they leave their desk with the browser window open. Someone else may be able to browse back to the site, change the user's password, and then have full control of the account. There are also situations where stealing a cookie or other authentication token allows someone else to hijack a user's account. If you always prompt for old passwords before setting new passwords, you will reduce these types of attacks because the attacker must know the user's actual password.

After users set a password, you should expire any session tokens and require them to log in again. Recently a friend received an e-mail stating that there was a problem with his eBay account. The e-mail had a link to log in to eBay to fix the problem. He clicked on the link, entered his username and password, but immediately realized that he might have been tricked into logging in to a fake site. Without delay, he changed his password, but then saw bogus auctions appearing on his account. Next, he found that his contact e-mail address had been changed. eBay's fraud detection kicked in and suspended his account, canceling over 250 active auctions. Even though he quickly changed his password, it was too late; a hacker had already logged in and had full access. In fact, the intruder was able to do anything he wanted until he closed the browser window or logged out. By forcing a logout after changing a password, you can terminate any active sessions.

Finally, when changing a user's password, always e-mail them a confirmation that the password has been changed, and perhaps include the IP address that initiated the change.

Does the system allow for password retrieval?

As an alternative for allowing users to retrieve passwords, you should instead have them reset their passwords. Allowing users to retrieve passwords means that passwords are retrievable; they are stored in a database table in either plain text or using reversible encryption.

Consider this example: a hacker breaks into someone's computer and has full access to the victim's PC. The hacker sees that the user has an online banking account. So he logs in to the banking site, clicks on the "Forgot My Password" link and waits for an e-mail. As soon as the mail containing the password comes in, he deletes the mail and logs in to the site. The user never knows that the password was compromised.

The best way to deal with lost passwords is to reset the password and e-mail the user a secure link back to your Web site. In the e-mail you should clearly state that a password reset was initiated and from which IP address it was initiated. Once they click on the link and have connected back to your Web site, they can select a new password for their account.

Does the system require some form of verification before resetting a password?

Another way to prevent the above scenario is to always prompt for some kind of personal information before sending an e-mail for a password reset or information request. You cannot assume that a user is the only person who will see the e-mail.

Does the system send sensitive information via e-mail?

Another issue with retrieving passwords is how you deliver the password back to the user. For example, when I looked at E*Trade's password retrieval scheme, I was at first quite impressed. You cannot retrieve a password, you can only reset it. The password retrieval page is SSL encrypted, so others cannot sniff the network and see your information. You even have to provide some personal information to initiate a password reset. The flaw with the system is that once you reset the password, it sends you a plain text e-mail with a new, temporary password. E-mail is not secure and is plainly visible on the wire between the user and the Web site.

AOL's ScreenName allows password retrieval without any personal authentication: all you need is a screen name to e-mail a user's password. If you are able to sniff a network, all you have to do is go to the password reminder page, enter the screen name, and then see what password is sent to the user.

Another common practice is to send users a confirmation e-mail containing their username and password, along with the recommendation to save that e-mail for future reference. Not only does this put the passwords at risk by sending them plain text over the wire, but it also encourages users to save these e-mails in their mail client.

Does the system assign temporary passwords?

If your system assigns temporary passwords, you should require either a password change after the first log-in or limit how long users can use temporary passwords. Several years ago, I subscribed to an online book service but later forgot my password. I submitted the password change request but I was required to answer a secret question, which I had not set up. I ended up sending an e-mail to the customer service department. A customer service representative promptly sent me a temporary password. In her e-mail she told me to change the password after logging in, because she gives everyone the same temporary password when she resets passwords. As soon as I logged in, I went to change my password, but couldn't figure out how to do it. Eventually I did change it, but I would guess that many others would quickly give up and just keep the temporary password. This can be avoided by doing two things: don't let customer service reps set passwords and limit the use of temporary passwords.

Does the system use password reminders?

Although they seem useful, password reminders or secret questions can actually weaken a system's security. For instance, when I signed up for an online air miles account with one major airline, it required that I provide a password of at least eight characters, a great practice that would allow a minimum of 218,340,105,584,896 possible passwords. However, it then asked me for a secret question, and gave me two fixed choices: my mother's maiden name or a pet's name.

The interesting thing about this is that there are only about 25,000 common surnames in the United States, which is roughly the number of permutations and combinations afforded by a three-character password. But if a hacker doesn't have time or a script to enter 25,000 names, there is a one in ten chance that someone in the U.S. will have one of the following names: Smith, Johnson, Williams, Jones, Brown, Davis, Miller, Wilson, Moore, Taylor, Anderson, Thomas, Jackson, White, Harris, Martin, Thompson, Garcia, Martinez, Robinson, Clark, Rodriguez, Lewis, Lee, Walker, Hall, Allen, or Young.

The top twenty pet names, according to a dog tag manufacturer, are: Max, Buddy, Molly, Bailey, Maggie, Lucy, Jake, Rocky, Sadie, Lucky, Daisy, Jack, Sam, Shadow, Bear, Buster, Lady, Ginger, Abby, and Toby.

If you do provide fixed secret questions, you should provide at least twenty, but preferably more questions from which to choose. Another option is to let the user select the secret question and provide an answer. While this provides many more options than a fixed set of questions, not all users will use them responsibly. Here are some examples of secret questions I have seen:

What is my name?

What's my e-mail address?

What is my password? (if you knew that, you wouldn't need the secret question would you?)

Another option that I sometimes see is just a simple password hint. This is the absolute worst thing you could do, as users often enter their actual password as the hint. If you really must do something like this, then make sure that the hint does not contain the user's actual password.

Secret questions can be useful but it is important that they not be the equivalent of a password. A secret question should be used to validate users so that you can reset their password, but should not be used to log in to the account.

Conclusion

This concludes the first part of this two-part article discussing some questions to audit the security of Web site authentication. This installment has focused on issues surrounding usernames and passwords. The second part of this article will explore issues surrounding user privacy, session authentication, user security, and cookies.

Auditing Web Site Authentication, Part Two
by By Mark Burnett
last updated May 5, 2003

Inadequate user security is a problem that Web developers must address. Perhaps it is lack of standards. Perhaps it is a lack of auditing. This is the second part of an article addressing both of those issues by establishing a standard audit procedure by which to measure your own security. Test this list of questions against your own Web site's authentication scheme and see how it stands. The first article focused on issues surrounding usernames and passwords. This article will explore issues surrounding user privacy, session authentication, user security, and cookies.

Does the system transmit user credentials over a secure channel?

Whenever users log in, set personal information, answer secret questions, etc., always be sure to use SSL for the connection. Further, make sure that you specify a unique realm for all SSL pages to be sure that the information is not revealed when browsing to non-encrypted pages.

Many Web sites such as Hotmail and Yahoo! do provide secure login pages, but this is not the default option; users must click on another link to log in securely.

Are passwords stored using a strong hashing algorithm?

You should never store a user's password in plain text. At a minimum you should use as strong encryption algorithm. The best thing to do is not store the password at all, but create a hash of the password using a message digest or one-way hashing algorithm. These algorithms derive a hash that cannot be used to determine the original password. The occurrence of any two passwords creating the same hash is extremely rare, so this method is very secure. To verify a password, you hash the user's input and compare it with the hash stored in the database.

In most cases, a Web site does not need to know a user's password; they just need to know that the user knows it. Hashing algorithms accomplishes that.

Session Authentication

Can anyone bypass authentication by accessing a module directly?

To avoid backdoors, make sure that every protected resource authenticates the user's session. Never assume that a user will follow the correct path to a protected resource and never assume that an obscure filename will protect from unauthorized access.

Does the system allow authentication to the Web server's operating system or network?

Many Web authentication systems are tied to operating system accounts. While this may be convenient for some purposes, you must carefully consider the consequences of doing this. For example, an attacker may be able to use your authentication system to guess passwords on administrator or other privileged accounts. They may also be able to lock out or otherwise impair important system accounts.

If you do use operating system accounts, limit the scope of logins through carefully planned user groups, organizational units, or even using separate domains.

Do users have the option to log out of their session?

Always provide a conspicuous log-out link that abandons the session and destroys any session tokens. Make sure that users know that the safest way to end a session is to click on the log-out link.

Does the system destroy session tokens upon logging out or timing out?

I have seen systems that delete any existing session tokens for users after they are authenticated. But you should also delete session stale tokens. Even better, add a timestamp to session tokens so that they expire after a period of time, even if the session has not timed out from inactivity. Every Web page should check the validity of a session token and require re-authorization if necessary.

Does the system prevent account hopping?

A common programming flaw is to check a user's log in, then set a flag that indicates that the user is authenticated. Instead, you should generate a session token that is only valid for that user and check that token on each page. Otherwise, users may be able to switch to another user's account through URL or cookie tampering. For example, consider this URL:

 
http://www.example.com/users/accountinfo.asp?userid=1254

My first thought when seeing a URL like that is to see what happens if I change the userid value to something like userid=1253, or even better, userid=1. If this system only looks at an authentication flag, it might let me view the details of someone else's account.

User Security

Can a third party trick users into authenticating to fake login pages?

Sites such as eBay, Hotmail, and PayPal have a big problem with users getting their login information hijacked because someone else tricks the user into logging in to a fake login screen that collects usernames and passwords. While this is in part owing to browser flaws, poor client configuration, and na�ve users, your site design and security policies can help minimize this. For example, your site should have a single, dedicated, and simple URL for user logins. For instance, consider some of these login URLs:

 
http://www.citibank.com/domain/redirect/signon/myciti.htm?
BVE=http://Web.da-us.citibank.com&BVP=/cgi-
bin/citifi/scripts/&BV_UseBVCookie=no&US&_u=visitor 


https://www.aa.com/apps/utility/logInOut/LoginMember.jhtml;jsessionid=
0CC3OQ2ND1JEAJJNDSNAEQBFFUGLTT?
anchorEvent=false&_requestid=316005&_requestid=316005 


http://www.amazon.com/exec/obidos/flex-sign-in/ref=ya_hp_pi_1/103-
5972766-0490219?opt=a&page=help/ya-sign-in-
secure.html&response=account-name-change&method=GET&return-
url=account-name-change

What I would prefer is to see URL's such as these:

 
http://login.citibank.com/ 
http://login.aa.com/ 
http://login.amazon.com/

None of these latter URLs actually exist; but which do you think would be easier to spoof? If Web sites would use simple login URLs, only allow users to log in from those URLs, and educate users of this fact, account hijacking could be reduced.

Another thing you can do to help the problem is take preventative measures on your end to monitor referrer strings on your login pages. Watch for common red flags such as concurrent logins from multiple IP addresses, and educate users.

Do you educate users on how to protect their account information?

Every Web site should have a security page to teach users how to protect their account information and to understand your security policy. For example, your security page could tell users that you will never ask them to log in from an e-mail and that no one from your company will ever ask them for a password. Explain that the address bar should always show a simple login URL as described above. Users should also receive tips on how to select strong passwords and how to avoid common Internet scams.

Do you let users see their account history?

An excellent way to catch intruders is to get the users involved. For instance, upon logging in you could show users the last few login times, complete with IP addresses. Users should also have the option to view a detailed account history showing detailed login information, account modifications, password changes, etc.

Can users easily report security incidents?

Users often notice suspicious behavior with their accounts but do not know what they should do about it. Every Web site should have a clear method for reporting suspicious activity and you should encourage users to actively report security incidents.

Can users customize their security options?

If you can't find the right balance between user security and user friendliness, let users decide for themselves. For example, users could set their own session timeouts, IP restrictions, failed logins allowance, etc. Yahoo! has an option that allows users to select how often they are prompted for a password and Hotmail.com let's users select their session timeout. This allows your users to be more secure if they want more security without affecting beginner users.

Can users revoke or delete accounts?

If you allow users to create accounts, you should also allow them to easily close those accounts.

Cookies

Will a hijacked cookie allow a user logon?

Writing a persistent cookie to a user's system may be convenient but it is also a great security risk. If an attacker is somehow able to hijack a user's cookie, the user's account will be compromised. Other alternatives you may consider are to only provide limited account access without re-authentication or to tie the cookie to other identifying information such as IP address, User Agent string, etc. Nonetheless, all cookies should have a reasonable fixed expiration date that requires re-authentication. Ultimately, the best solution is to require a login every session.

Account hijacking can be a serious issue for users but can affect you as well. Say, for example, that a user places a large order but later says it was fraudulent; that someone else hijacked his or her account. If you require a login each session, it becomes more difficult for users to repudiate transactions on their account.

Some of the world's largest Web sites have an option to automatically log in from a cookie. If you do this, keep in mind that the person logging in could either be the user, anyone who knows the user's password, anyone who has physical access to the user's computer, anyone with administrative network access to the user's computer, anyone who has broken in to the user's computer, or anyone who can see the network to sniff traffic.

If you want to ignore this advice and allow automatic log in using cookies, at least give users the option to not save or erase cookies. You can erase a user's cookie by sending them a blank, expired cookie.

Is sensitive information stored in cookies?

Account login is not the only risk with cookies. Many sites store personal account information in cookies. Never store actual user information in cookies; rather, store a token that points to user information on the server's database.

Are cookies marked as secure?

According to RFC 2109, cookies can be marked secure, preventing their transmittal to non-SSL Web pages. But many Web sites overlook marking cookies as secure. The problem with this is that if a user browses from a secure page to a non- secure page on the same site, the browser will continue to send the cookie. If a cookie is marked as secure, the browser will not send it to non-secure pages.

Do cookies specify a domain and path?

Cookies also have Domain and Path properties to limit a cookie's scope. If you fail to set boundaries for cookies, it may be possible for an attacker to exploit a cross-site scripting flaw on another Web page or even another server to hijack a user's cookie.

General Principles

Beyond these questions you should step back and ask yourself if your Web authentication system follows generally accepted best practices. For instance, does the system use multiple layers of defense? Does it properly limit the scope of trust? Is it simple and does it maintain a minimal attack surface? Does the system properly prevent spoofing, tampering, repudiation, information disclosure, denial of service, and privilege escalation attacks?

Despite the dramatic increase in security education and training over the last few years, passwords continue to be security's weakest link. Your Web application must do its part in keeping passwords secure. Some may argue that the principles in this article are a bit extreme, and perhaps it is just wishful thinking on my part for suggesting them, but they are a standard by which you can measure your own security. Obviously, you must take into consideration the unique risks and exposures of your own Web site. If you use user logins as a casual means to identify users, maybe all these security measures do not make sense. But if you are a financial, medical, educational, or government institution, maybe you should take a good hard look at your authentication system.