Hacking the Code ASP.NET Web Application Security [Electronic resources] نسخه متنی

Resetting Lost or Forgotten Passwords

Sooner or later, some of your users will lose or forget their passwords. Because of the potential security risk, you must carefully consider how to deal with lost or forgotten passwords. In this section, you will learn about:

Resetting passwords

Sending information via e-mail

Assigning temporary passwords

Using secret questions

Resetting Passwords

To avoid the customer support overhead of dealing with lost passwords, many Web sites allow users to conveniently retrieve or reset their own passwords. However, password reset features, if not implemented correctly, can introduce security weaknesses to your Web application.

You should always treat a lost password as a security event, taking extra precautions to protect the user’s account from intruders. Too many Web sites take a casual approach to lost passwords: Users enter a username or e-mail address (as shown in Figures 1.7 and 1.8), and in a few minutes they receive an e-mail containing the original password. Indeed, users who infrequently visit a site sometimes use the convenient password retrieval process instead of other methods to record or remember their passwords.

Figure 1.7: Password Retrieval Using E-Mail Only

Figure 1.8: Another Password Retrieval Method Using E-Mail Only

But retrieving passwords means that your Web application is either storing passwords in plaintext or using reversible encryption, both poor practices, as described earlier in the section “Storing Passwords.” If a lost password event occurs, you should always abandon the old password and require the user to set a new password. You should never allow users to retrieve a lost password, only to set a new password. Password hints that remind a user of the actual password are not much better, especially if the hint is the password itself.

The difficulty in resetting passwords is that you want to provide users the convenience of resetting their own passwords, but you do not want to weaken password security in the process. Before your application resets a password, you should be reasonably certain that it is the user, not an impersonator, on the other end of the transaction. Since the user no longer has the original password to prove his or her identity, you must take other steps to validate the user’s identity. Here are some ways to accomplish this:

Send the user an e-mail to the address assigned to the account.

Ask the user to answer one or more preselected secret questions.

Ask the user to provide one or more bits of information associated with the account (such as ZIP code or birth date).

For highly secure environments or when dealing with particularly sensitive information, you may even take further steps to verify a user’s identity:

Call the user at the phone number assigned to the account.

Send the user a fax to a preselected fax number.

Send the user a letter through the postal service.

Ask the user to appear in person and present identification at your main or branch office.

The purpose of asking the user to answer a secret question or provide other information is to verify that they know something about the account, as shown in Figure 1.9. This helps prevent random anonymous attacks against users, but it does not protect a user from attack from an individual who has knowledge of the user. Sending the user an e-mail will prove that the person requesting the password reset has access to the user’s e-mail account. It is possible for an attacker to have obtained access to the user’s e-mail account, but if the attacker can answer a user’s secret question and has access to the user’s e-mail, the user likely has a much bigger problem that you really cannot do much about anyway. Nevertheless, you still should never reveal the old password in the e-mail, only provide a link to reset the password.

Figure 1.9: Example Password Retrieval Using Personal Information

Design the system with a clear flow of events through the password reset process. Use secure session tokens with short expiration periods throughout the process. Never put usernames, e-mail addresses, or other identifying information on any URL.

The process for resetting a password should be as follows:

Ask the user to provide an account name and answer one or more questions that demonstrate knowledge of the account, as shown in Figure 1.10. Log the IP address of the client that initiated the request, and assign a secure token for the password reset session. Set a short expiration period for the session—24 hours or less.

Figure 1.10: Password Reset Process

Send an e-mail to the address assigned to the account explaining that a password reset has been requested; include the client IP address that initiated the request. Provide a secure link to your Web site using a temporary token linked to the reset process. Always provide an e-mail address or URL for the user to report a security incident if they were not the ones who initiated the password reset.

After the user clicks the link, ask the user to provide a new password and optionally a new security question and answer. Always check the session token to be sure it has not expired.

Figure 1.11 shows an example of a password reset process. This particular screen shows that the site correctly requires setting a new password rather than retrieving the old one. Although the site asks for an e-mail address and some personal information, a credit card number is by no means secure enough to verify a user’s identity. Any merchant that has taken an online order from a user will likely have all the information necessary to complete this form. At first it might seem like this process is more secure because it sends the user an e-mail, but remember that this is the user’s e-mail account, so it would be impossible to send the user an e-mail if her or she have forgotten the password. In this case, authentication will have to be sufficient to allow full access to the account. In addition to asking for the credit card information, this process should ask for additional personal information and ask the user to answer a secret question.

Figure 1.11: Example Password Reset Process

A common flaw in the password reset process is for a Web application to use hidden form fields or query strings to pass state information from one page to the next. For example, to ask users their secret questions, you must first find out who they are and then look up the secret questions. Therefore, most password reset processes begin with a user entering an e-mail address in a Web form. On the next page, the Web application presents a secret question and asks for an answer. Finally, the secret question is verified and action is taken to retrieve or reset the password. But sometimes a Web site will pass the user’s e-mail address or username as a hidden form field that an attacker can modify. Sometimes this will result in the password being sent to the e-mail address of your choosing. Another common flaw is that you can begin the process with one account and modify a parameter halfway through to jump to another account and finish the process.

Review the password reset process, ensuring that the application sufficiently validates the user’s identity before sending e-mail. Never send e-mail to any address other than the one assigned to the account. Walk through the reset process, watching every step to ensure that it is appropriately and securely linked to the previous step. Make sure that it is not possible to switch to the context of another account halfway through the reset process.

Security Policies

Treat password resets as a security event, logging the client IP address and taking other practical security measures.

Never retrieve a user’s password; only allow a user to set a new password.

Never use password hints to remind the user of the actual password.

Ask the user to show some knowledge of the account through secret questions or by providing information associated with the account; never allow an anonymous password reset.

Send the user an e-mail to confirm a password reset, providing a secure link to complete the process.

If practical, after a password reset, clear any sensitive information stored with the account, such as credit card numbers.

Expire all existing sessions after a password reset.

Sending Information Via E-Mail

Consider this e-mail I recently received after subscribing to a Web-based information service:

To: mburnett@xato.net
From: sales@example.net
CC: orders@example.net
Subject: Order confirmation
Dear M.,
Thank you for your subscription, below is the information for your account.
 Please keep this e-mail for future reference:
Username: MBurnett
Password: 300Watt-Orange
Your credit card #1234-5679-1111-1111 will be charged $19.95 at the
 end of your 30-day trial. 

The problem with this e-mail is:

It transmitted my username and password in plaintext across the Internet.

It transmitted my credit card information in plaintext across the Internet.

Whoever has access to the www.auctionbytes.com/cab/abn/y03/m05/i15/s01).

Design the system so that it only relies on e-mail as a secondary form of identification and notification. If possible, take advantage of S/MIME or PGP signing and encryption to strengthen e-mail communications. Allow users to provide you with a public key to be used for all e-mail communication.

If you want a user to have some confirmation of an order or account registration, provide a secure, temporary link via which the user can view this information on your Web site. Rather than sending users their usernames and passwords, instruct them during the registration process to remember this information. If you must provide confirmation of a credit card order, only provide the last few digits of the card number, and do not provide any other identifying information.

When composing e-mails, always consider the effect on the user if this information is intercepted or viewed by others.

Security Policies

Never send sensitive information such as user credentials or credit card information via e-mail.

Never rely on e-mail alone to verify a user’s identity.

Do not use e-mail to save the results of a Web form submission that contains sensitive information.

If possible, digitally sign or encrypt e-mail communications.

Assigning Temporary Passwords

I once signed up for an account at an online book Web site, but I did not use the site until a couple months later. By that time I had forgotten my password, and despite several attempts to guess it, I was forced to click the Forgot Password link.

To my surprise I was not taken to a Web form, but instead my e-mail client popped up with a blank e-mail addressed to the site’s customer service representatives. I was surprised that such a large site would rely on such a manual process, but I composed an e-mail and sent it off. A few hours later, I received an e-mail from a support representative telling me that my password had been reset, but she did not give me any instructions on how to log in to my account. I e-mailed her back and asked her how I set a new password. She promptly responded and told me my new password, which sounded suspiciously like a password she used often. I logged in to my account and could not find any place to change my password. After all, the password reset process was manual; could I possibly expect them to provide a password change feature? Because I was under a tight deadline, I gave up and simply used the assigned password. It wasn’t until a month later that I actually figured out how to change my password to something new. Chances are there are hundreds of customers who never got around to changing their passwords for that site.

Temporary passwords are normally not a good solution, and you can usually find a better method to accomplish your goal. Temporary passwords created by humans tend to be repetitive and easily guessed. Automatically generated passwords also tend to follow patterns or are difficult to remember. Users are not likely to change temporary passwords unless forced to do so.

Building the Code

Design the system so that it does not depend on temporary passwords. If there is no alternative, provide a means for generating strong passwords, and limit each password so that the user must immediately change it to something else. A system with password-aging capabilities allows more flexibility with temporary passwords.

Never expect a randomly generated or temporary password to be temporary unless you force it to be temporary. One technique in generating passwords for users is to create the password but set the expiration date so that it is already expired, forcing the user to change the password the first time it is used. Be sure to add this password to the password history list.

Hacking the Code

If you find that an application uses temporary passwords, try creating several accounts to see if there is an obvious pattern. Also try resetting your password to see if it creates temporary passwords there.

As an auditor, determine if users are likely to immediately change those passwords. It is usually not enough to recommend that they change their passwords; the application should enforce this policy.

Security Policies

Avoid having customer service representatives set temporary passwords.

If you must use temporary passwords, use a strong random password generator.

If you must use temporary passwords, provide a short expiration date or set the password as already expired.

Using Secret Questions

To help verify a user’s identity in the case of a lost password, many Web applications use secret questions. By answering a preselected question, a user can demonstrate some personal knowledge of the account owner. A classic example is asking to provide a mother’s maiden name.

Answering secret questions requires some knowledge of the user account, but secret questions break all the rules for strong passwords and have some significant weaknesses:

An attacker can sometimes discover the information with little research.

The answer to the question is usually a fact that will never change.

Users reuse the same secret questions and answers across multiple Web sites.

Someone close to the individual could know the answers to many of the questions.

People rarely change their secret questions.

The answers are often case-insensitive and usually contain a limited character set.

Some questions have a limited number of answers.

With some questions, many people will have the same common answers.

Secret questions usually ask for an obscure fact that hopefully only the account owner would know and supposedly would never forget. Many Web sites assume that the user providing the answer to the question is sufficient to identify the user. But many secret questions ask for facts that anyone could discover with little research. To make things worse, if someone discovers this information, you can’t just change a fact from the past.

I have seen countless Web sites that provide great tips on avoiding easily guessed passwords but then turn around and ask for a pet dog’s name or what city you were born in to answer a secret question.

Even if an attacker knows nothing about the target user, the nature of secret questions limits the possible range of answers. For example, consider the questions and ranges of answers shown in Table 1.1. As the table shows, many secret questions have so few possible answers that a brute-force attack against these secret questions is completely feasible. To make matters worse, some Web sites fail to detect or prevent brute-force attacks against secret questions. For years security experts have told people to avoid using pet names, family names, or dates in passwords, but secret questions go directly against that advice.

The key to properly using secret questions is to understand that they should never be the equivalent of a password. They should only be used to initiate a password reset, to prevent anonymous attacks against the password reset process. Providing the answer to a secret question should never be enough to validate a user, but combined with other factors, such as having access to the user’s e-mail account, secret questions can be effective in helping to identify a user.

The greatest threat with secret questions is that the answer is usually fixed and an attacker can sometimes discover this information through research. Because there is usually a limited set of answers to secret questions, they are also vulnerable to brute-force attacks. Finally, secret questions are usually ineffective against attacks by people close to the user. Individuals such as ex-spouses, once-close business associates, or wayward teenage children may have sufficient information and sufficient motivation to break into a user’s account.

Building the Code

The key to successfully and securely using secret questions is to clearly define their role as just one part of the password retrieval process. They prevent password resets without some personal knowledge of the user. Design the system to be flexible with secret questions and answers, allowing users to disable secret questions or requiring a telephone call for final confirmation. Another effective technique for security-sensitive Web applications is to allow or require users to answer more than one secret question. Consider the impact on the database of having multiple and perhaps a variable number of secret questions.

Avoid allowing users to select their own questions, since most users are not trained to select strong enough questions. Sites that allow users to select their own secret questions end up with insecure questions such as:

What year were you born?

What is your password?

What is the capital of Georgia?

Select good questions, carefully considering the possible range of answers as well as the likelihood of common answers. Use unique questions, and try to avoid subjects that return short, one-word answers. Also try to avoid questions that others commonly use, such as mother’s maiden name, pet name, or high school. But keep in mind that you should ask questions that users will always answer the same way.

Establish a large list of questions, but provide a short, random list for users to select from. For users more concerned with security, you might want to provide an advanced option to select from a larger list of secret questions.

If the user provides a predetermined number of incorrect answers to the security question, you might not want to return an error, but instead send the user an e-mail explaining that he or she answered incorrectly. This will prevent brute-force attacks against the secret question process and alert users to a possible attack against their accounts.

Here are some examples of good secret questions:

What is the first and last name of your first boyfriend or girlfriend?

Which phone number do you remember most from your childhood?

What was your favorite place to visit as a child?

Who is your favorite actor, musician, or artist?

Security Policies

Secret questions by themselves are not secure and should never be used as a password equivalent.

Allow users to change their secret questions and answers if necessary.

Detect brute-force attacks against secret questions.