Users are generally a large component of Web applications and a focus point for a Web application’s security. In fact, much of a Web application’s security is intended to protect users and their private information.
Every Web application has different levels of risk and sensitivity. You must assess this risk in your organization to determine how much emphasis you put on user security. How you build your Web application will greatly affect how your users participate in security. Your users may or may not take security as seriously as you want them to, but as a security professional, it is your job to ensure that the data is properly protected.
Consider a magazine’s online article archive that is available to authenticated subscribers. The owners want to protect their copyrighted content, so they require users to authenticate to gain access to certain articles. However, readers will not store personal information on the site, and they might not be careful with security, perhaps even sharing their login information with friends to allow them to gain access to protected articles.
Perhaps more often, users are more concerned about security than are the Web site operators. Too many companies do not put a great emphasis on security until after it is too late. In March 2001, the Federal Bureau of Investigation (FBI) National Infrastructure Protection Center (NIPC) issued an advisory that hackers were targeting e-commerce and e-banking Web sites, stealing credit card information, and attempting to extort money from the site owners. The hackers exploited well-known Windows vulnerabilities, all of which were moot if the site operators had kept up to date with security patches. The NIPC advisory stated that hackers have stolen more than a million credit card numbers from 40 companies. Obviously, these companies recklessly handled sensitive user information by not taking security seriously. Their lack of diligence put private user information at risk.
Brute-force attacks These attacks involve the process of discovering user credentials by trying every possible character combination. Brute-force attacks can be optimized by first trying dictionary words, common passwords, or predictable character combinations.
Spamming We’re all familiar with this one—it involves the process of sending large quantities of unwanted e-mail to a user or Web site, thus jamming Internet lines and sometimes causing servers to crash.
User security begins with the selection of a username and password. You demonstrate to users the importance of security in the way you select or let users select usernames and passwords. In this section, you will learn about:
|Summary:||Use technical measures and policies to ensure strong user passwords|
|Threats:||Brute-force attacks, account hijacking|
If passwords are the central mechanism of your application’s security, you must ensure that users have strong passwords. Establish a policy to ensure that passwords are complex enough to prevent someone guessing them easily. You can create a robust password policy by:
Many popular Web sites do not enforce minimum passwords lengths, or they enforce a minimum length that is much too small to be secure. Figure 1.1 shows a Web site that allows passwords of only three characters and limits the maximum length to 25 characters. The minimum length is much too short, and although 25 characters is a long password, why impose any limit at all?
Many users will select predictable, easily guessable passwords if you do not enforce complexity requirements. Weak passwords are vulnerable to password-guessing brute-force attacks. If passwords are not long enough and do not contain multiple character sets, the number of guesses required to brute-force the password is greatly reduced. If an attacker is able to guess a user’s password, he or she could use those user credentials to access restricted content, obtain sensitive user data, impersonate the user for a variety of purposes, delete or modify sensitive data, or even cancel the user’s account.
To check password complexity, use a RegularExpressionValidator control or a CustomValidator control, as shown in Figure 1.2. This code assigns a CustomValidator to txtPassword. When validating form input, the control calls the PasswordCheck function. This is illustrated using C# in Figure 1.2 and VB.NET in Figure 1.3.
Figure 1.3 Validating Passwords Using a CustomValidator Control: VB.NET
|Summary:||Usernames or passwords that are easy to guess expose accounts to attack|
|Threats:||Brute-force attacks, password guessing, account hijacking|
One of the most prevalent security holes in the history of computers is the selection of easily guessed passwords. Despite years of password advice, users and sometimes administrators continue to use passwords such as password, letmein, or simply leaving passwords blank. One Web services company had its salespeople assign passwords to new customers. The salespeople made no effort to come up with secure passwords, and customers made no effort to change their default passwords. After two years in business, they had 200 customers, all with the same password: dragon.
Several years ago I created an account at a now-defunct online auction site. The registration process never asked for a password, but instead the site owners e-mailed me an automatically generated password, which was my username plus the number 22 at the end. Of course, they recommended that I change my password once I had logged into my account the first time, but they didn’t explain how to do that. Curious about how many users actually changed their passwords, I tried logging in as other users, appending the number 22 to the end of the username as each user’s password. That didn’t work, but I tried 11, 33, 44, and so forth, and was quickly able to guess passwords of nearly any account on the system.
The lesson: If you automatically create passwords for your users, expect that few of them will ever change the default password, unless doing so is enforced on the first logon sequence. Therefore, if you create passwords for users, be sure to use a strong random password algorithm that does not create predictable passwords. One example of a strong password generator is the Pafwert tool, available at www.xato.com/pafwert.
A common problem with many free or shareware CGI scripts such as Web forums or shopping carts is that they have administrative functions with default passwords. If you provide such an application, simply do not provide default credentials, but do allow users to create the initial password through the installation process.
Just as troublesome as easily guessed passwords are easily guessed usernames. Usernames are not meant to be secret the way passwords are, but you should try to limit other people’s ability to guess any username, because they all follow a sequential or predictable pattern. (See the section “Preventing Credential Harvesting” for more detail on credential harvesting.)
It is also important to avoid common default administrative account names such as administrator, admin, system, or operator. Password lockout policies sometimes do not apply to administrative accounts and therefore are attractive targets for brute-force or other attacks.
Easily guessed, predictable, or default passwords are vulnerable to password guessing and brute-force attacks, as are easily guessed usernames. Predictable or default passwords may result in the compromise of a large number of accounts. Some common CGI scripts use default passwords, and an attacker could use a search engine to locate vulnerable sites.
Design your system so that users set their passwords the first time they use the account or application. Use randomly generated passwords only if necessary and to allow users to initially log on to their accounts, after which the application forces them to change their passwords. Avoid designing a system that expects the username or password to follow any specific pattern.
Also avoid any code that automatically generates usernames or passwords, unless you take extra steps to avoid predictable patterns. Allow users to select their own usernames and passwords whenever possible.
|Summary:||Credential harvesting exposes users to a variety of attacks|
|Threats:||Brute-force attacks, social engineering, spamming|
Several years ago I received a phone call. The gentleman on the other end called me by name and said he was from my bank and needed to confirm my account information in their records. I was immediately suspicious, but before I had a chance to respond, he began to read off my full name and street address. But he read my address incorrectly, which happened to be the way it was listed in the phone book, tipping me off to the fact that he simply used information from the publicly available white pages to trick me into revealing other personal information. This person harvested names from the phone book to use as scam targets. Consider these risks in the following examples of credential harvesting.
Bob, a well-known spammer, has written a script to crawl through the thousands of Web pages every day at all the popular auction sites. On each page his script extracts the username of every auction user it finds. After collecting several million account names, he takes the lists and combines each username with each of the most common e-mail and Internet service providers: hotmail.com, msn.com, juno.com, aol.com, earthlink.net, yahoo.com, and so forth.
Next Bob sends out an e-mail to every one of these combined addresses and tracks which accounts are valid. When all is done, he has well over a million valid e-mail accounts. Of course, the first spam e-mail he sends out is one offering a million valid e-mail addresses for the low price of $99.
Chuck is a hacker. He steals identities and financial information from unsuspecting e-commerce customers. He knows that one large retailer’s Web site allows customers to save their credit card information to make future purchases more convenient. Chuck wants to break into customer accounts and grab this stored credit card information.
For his first attempt, he makes a small list of common usernames and passwords and tries a scripted brute-force attack against the Web site. It doesn’t take long for him to realize that this site locks out accounts once a user enters five bad passwords in a row. But there’s another way to brute-force passwords: Instead of trying a lot of passwords against one account, he can try one or two common passwords against many different user accounts. Statistically, he knows that if he tries a few common passwords against enough accounts, he will get a match.
Now the only problem is how to collect account names. To do this, he writes a script to sign up for accounts using random but common usernames. The script fills in and submits the signup form and watches for the message, “Sorry, that username is already in use.” If he gets that message, the script saved the username. If not, it cancelled the session and started again with the next name.
After several hours, the script gathers several thousand usernames from this busy Web site. He takes that list and feeds it into his brute-force script, which eventually finds three accounts with the password: asdf. Three accounts might not be a huge score, but he now has the scripts and runs them every day, changing them slightly each time to turn up more results.
By harvesting usernames, an attacker might be able to collect e-mail addresses for spamming, attempt to trick other users into revealing passwords using social-engineering techniques, attempt brute-force attacks across multiple accounts, or exploit other weaknesses in an application. Stopping credential harvesting is really just a matter of not showing usernames and not using predictable credentials. However, some Web sites are completely based on user credentials, so you must use a variety of measures to limit credential exposure.
Design the system so that the username is not the database primary key. This solution allows users to change their usernames without losing important account information or history. One technique to protect usernames is to allow users to create one or more aliases that are not used to log in to the account. Avoid usernames that are sequential or that follow predictable patterns. If connecting users to external accounts, such as checking accounts, do not use the checking account numbers as user IDs, because these account numbers are often sequential and an attacker could easily discover this information.
The best way to prevent username harvesting is to simply never show usernames on your site. However, if this is not practical for your Web application, you can try fooling some automated harvester scripts by varying the encoding used to write the usernames.
Another important guideline is to avoid passing the username as a query string parameter to prevent it from showing up in browser histories, proxy logs, and HTTP referer [sic] headers of other sites. Consider the following URLs that may appear in another Web site’s Web logs.
|Summary:||Idle accounts make easy targets for hackers|
If you are a hacker and want to hijack someone’s Web site account, what type of account would you go after? You certainly do not want an account that someone uses every day, but you also don’t want an account that someone never uses.
Once an attacker gains control of an account, he or she may change the password and completely lock out the legitimate user. Hackers have many motivations for taking over someone else’s account. For example, they could use a hijacked auction account to list fake auctions or use a PayPal account to make fraudulent purchases.
A couple years ago, hackers penetrated a banking Web site and gained access to the bank’s entire database. The hackers used their knowledge of electronic funds transfers to move funds to other online financial accounts. Some account holders noticed the problem and reported the transfers to the bank. The bank immediately reviewed all recent electronic transfers and contacted customers to find out if the transactions were legitimate or not. Most customers were surprised by the breach, but many of them were also surprised to find out that they even had online accounts that the bank had automatically created for them.
Users are often the best ones to spot fraud, but not with idle accounts. One travel agent found that she could transfer accrued air miles from one customer to another. She found some seldom-used accounts that had high air-mile balances and transferred small amounts from each to the account of a relative, thinking the customers would not notice the change. However, she was not aware that the airline sent e-mails to the customers confirming any air-mile transfers. Several customers complained, and the company quickly tracked down the agent responsible for the transfers. This company side-stepped the idle account problem by following up with an e-mail to users.
Online accounts are potentially dangerous, especially those that deal with financial transactions. An attacker can potentially steal and abuse the identity of a legitimate account. If users are not aware of the breach, an attacker can sometimes access the account for an extended amount of time without detection.
Design the system to track account activity and aging, and provide a method for placing an idle account on hold without completely closing the account, as shown in Figure 1.4. Clearly define how and when users receive notification of account changes or transactions, and provide a clear method for users to report suspicious or fraudulent transactions.
Centralize the code for account changes and transactions so that you have an integrated location for recording, analyzing, and notifying users of these actions. Develop a process to suspend and eventually purge idle accounts.
|Summary:||Passwords stored in databases are a risk to your application as well as others|
|Threats:||Account hijacking, potential liability|
In February 2001, RealNames, a company that substituted complex Web addresses with simple keywords, announced that hackers had accessed its customer database, revealing credit card information and passwords of all its customers. A month later, Web hosting company ADDR.com announced that a hacker stole personal information and passwords of some 46,000 customers. Month after month since then, we have heard similar stories of hacked servers and stolen passwords.
Obviously, the first solution is a terrible one, and the second isn’t much better: Although the password is encrypted, that encryption is based on a secret key. If the Web application must perform this encryption and decryption, the application must somehow store this secret key. If a hacker gains control of the application and the application can decrypt passwords, the hacker too can decrypt any passwords.
One important reason for not storing actual passwords is that by if you do so, no one at your organization ever has access to user passwords. This is important because it is not uncommon for users to reuse passwords for many different systems. If some people in your organization have access to passwords in your application, it could mean that those people also have access to a user’s accounts on other Web systems.
If passwords are stored in a database, an attacker can potentially gain access to all user accounts, even if the passwords are encrypted. This puts all users at risk, especially if they use the same passwords on other systems, as many users do. Some hackers collect large lists of username and password combinations to use in brute-force attacks of other systems.
Identify the hashing algorithm that would work best for your organization. Because hashes are still vulnerable to brute-force attacks, the best solution usually is not the algorithm with the best performance. In this case, a slower algorithm means the brute-force process will take longer. Design the system so that you never have to actually retrieve a password. Passwords should only be set or reset.
In rare instances, however, the application must store a password for later use. For example, I once audited an application that had to authenticate to a third-party data provider. Because the data provider required authentication, the application had to store the password using reversible encryption. Because the application required a retrievable password, the company had to compensate by taking extra measures to protect the encryption key, which it did by placing the encryption and decryption code in a COM component.
One weakness with using reversible encryption in a Web application is that in the real world, the encryption key rarely changes. The problem is that if you ever want to change the encryption key, you must decrypt all ciphertext in the database and then re-encrypt it using the new key—something that few Web or database applications are designed to handle. If you plan to use reversible encryption, plan also to have a mechanism to regularly change the encryption key and update all encrypted data.
Use one-way hash functions and store the hash in the database. When a user logs in, run the hash function on the password the user enters, and compare that hash to the one in the database. One advantage of hash functions is that they consist of only numbers and letters, allowing users to enter any keyboard character as their password without you having to take extra measures to handle special characters.
SeeChapter 4, “Encrypting Private Data,” for more information on using the encryption features provided by the .NET Framework.
|Summary:||Old or reused passwords provide more opportunity for attackers|
|Threats:||Brute-force attacks, account hijacking|
As an application ages, so do user passwords, because users normally don’t make the effort to regularly change their passwords. It is not uncommon to see users with passwords as old as the system itself, sometimes going several years without changing a password. This is especially true with Internet service provider (ISP) e-mail accounts that provide no easy method for changing passwords. You should always require users to change their passwords at regular intervals, a practice that few Web sites follow.
But setting the right interval isn’t always easy. If the maximum password age is six months, the risk of compromised passwords increases. However, if you go the other extreme and require password changes every 30 days, you will find users writing down their passwords more and developing patterns such as sequential passwords or passwords based on dates. Requiring users to change their passwords too frequently can actually make the system less secure. Furthermore, if users log in to your Web application only once every few months and find they have to change their passwords each time, they are likely to get annoyed.
If your Web application is an online banking system, you might want to consider maximum password ages of three to six months. On the other hand, if you provide an online flower shop, you may get away with letting users keep their same passwords for a year or more.
Related to password aging are password histories, which are historical lists of previous passwords a user has selected. Password histories prevent users from alternating between the same two or three passwords every time one password expires. A system should reject any password that matches those in the history list. Many systems will remember the last three to five passwords, but some may keep a history of 20 or more passwords. Keeping a password history doesn’t require a significant amount of resources, so it usually makes sense to keep as many as possible.
Despite password aging and history lists, some users are still determined to reuse the same passwords. They circumvent these security measures by resetting their password enough times to fill up the history list and then setting their password back to the original that just expired. The countermeasures are to keep long history lists and to set minimum password-aging requirements. Minimum password ages are the least amount of time that must pass before users can again change their passwords.
Passwords are nothing more than an obscure secret word or phrase. Given enough time, an attacker could eventually guess a password through brute-force methods or through exposure from operating system or application vulnerabilities. As passwords age, the risk of an attacker compromising that password increases. Furthermore, if an intruder has obtained a password without alerting the user, the intruder will have access for as long as the password is valid. Without password aging, the intruder will have access until the user manually changes his or her password.
Password aging and histories require extra database fields to track when a password was set and to keep a list of recent passwords. There is also the extra processing requirement of hashing the password and comparing it to each entry in the history list. You might want to allow different aging policies for individual users or groups, or choose a systemwide policy. One advantage of systemwide policies is that you can immediately expire all passwords in case there is a major security incident such as a server intrusion.
You should check a password’s expiration date immediately after a user successfully authenticates to the system but before allowing access to the system. If you centralize your authentication to a single include library, you can more easily perform the password-aging check. If the password has not yet expired but is getting close, you might want to warn the user several days ahead of time. Figure 1.5 is an example of a password expiration screen.
|Summary:||Make it easy and encourage users to regularly change their passwords|
|Threats:||Brute-force attacks, account hijacking|
Many security experts warn against using “security through obscurity”(the practice of securing something by hiding it) as a defense mechanism. But passwords or authentication credentials—the center of many security systems—are nothing more than security through obscurity. A password’s strength completely depends on our expectation that no one else will be able to guess or otherwise discover the password.
Given enough time, attackers can discover passwords, either by exploiting some system vulnerability or through the process of a brute-force guessing attack. Our only defense is to regularly change passwords, hopefully before anyone has a chance to discover the current one. Therefore, an important feature to include in any Web application is the ability to change passwords.
I once knew of a company with a financial trading application that required users to log in to perform trades. Since most brokers performed many trades throughout the day, they simply minimized the Web browser on their screens and remained logged in. The brokers complained about constantly having to authenticate because their browser sessions timed out, so the developers eliminated all session timeouts on the server. At the end of the day, most of the brokers left their computers running, and most of them also failed to exit the browser application, leaving them logged in to the application. Some users would sometimes go all week using a single browser session.
Keeping an open session presented a big risk, but an even greater risk was how the application managed password changes. To set a new password, users browsed to the preferences page, clicked on a link to change the password, and then entered the new password. But consider this scenario: Another broker waits until a target goes to lunch and then sets a new password using the target’s open session, having no knowledge of the previous password. The target session remains logged in for the next week, but the other broker has full access to the account with the new password. It is not until the target is forced to log in again that he or she discovers that the password has changed.
If users do not regularly change their passwords, they face an increasing probability that others will be able to discover their passwords and therefore gain access to their accounts. The harder it is for users to change passwords, the less likely users are to change their passwords. This situation is worsened if users are not reminded or forced to regularly change passwords. Without techniques such as entering previous passwords, expiring sessions, and notifying users of changes, an attacker might be able to use an account for an extended period of time without detection.
Design the system so that changing passwords is a simple and intuitive process. Avoid practices that discourage changing passwords, such as overly oppressive password complexity requirements. Always require authentication before and after changing passwords.
After a user logs in, provide quick links to the most common account management tasks, including changing passwords. If your security policy does not require users to change old passwords, consider a simple warning including a link, like the one shown in Figure 1.6.
A password-change page should consist of three text boxes: one to enter the previous password, one to enter the new password, and a third to verify the new password. Figure 1.3 demonstrates a sample password reset screen.
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:
|Summary:||Follow a well-planned procedure for resetting lost or forgotten passwords|
|Threats:||Brute-force attacks, account hijacking|
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.
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:
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.
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.
1. 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.
2. 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.
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.
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.
|Summary:||E-mail is insecure and you should not use it to convey sensitive information|
|Threats:||Sensitive information leakage, account hijacking, user privacy|
Whoever has access to the firstname.lastname@example.org mailbox will receive a copy of this sensitive information.
E-mail is by nature an insecure medium: There is no guaranteed authentication of either the sender or the recipient, e-mail traffic is not encrypted as it traverses various networks in its path, many e-mail servers and clients do not encrypt stored messages, and there is no way to prevent others from receiving bounced, quarantined, or rejected copies of your e-mails. E-mail is also subject to attacks such as cross-site scripting, client vulnerability exploitation, scripting attacks, malicious attachments, and social-engineering attacks.
Another potential risk of e-mail is that a user is not guaranteed to always have the same e-mail address or domain. Some companies automatically forward e-mails addressed to departed employees to the new employee in that position. There is also the issue of expired domains that are registered by new owners, giving the new domain owner access to all e-mail sent to the entire domain (see 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.
|Summary:||Users will not change temporary passwords unless forced to do so|
|Threats:||Account hijacking, password guessing|
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.
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.
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.
|Summary:||Secret questions are not a replacement for passwords|
|Threats:||Sensitive information leakage, account hijacking, user privacy|
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.
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.
|Question||Range of Answers|
|What is the name of your favorite pet?||The top 20 dog names are Max, Buddy, Molly, Bailey, Maggie, Lucy, Jake, Rocky, Sadie, Lucky, Daisy, Jack, Sam, Shadow, Bear, Buster, Lady, Ginger, Abby, and Toby.|
|In what city were you born?||The top 10 largest U.S. cities are New York City, Los Angeles, Chicago, Houston, Philadelphia, Phoenix, San Diego, Dallas, San Antonio, and Detroit; one in three of all U.S. citizens live in the top 250 cities; the top 10 most common U.S. city names are Fairview, Midway, Oak Grove, Franklin, Riverside, Centerville, Mount Pleasant, Georgetown, Salem, and Greenwood.|
|What high school did you attend?||There are approximately 25,000 to 30,000 high schools in the United States; you can use Classmates.com to get a list by U.S. state and city.|
|What is your favorite movie?||For a list of the all-time top 250 films, see www.imdb.com/top_250_films.|
|What is your mother’s maiden name?||There are approximately 25,000 common surnames; one in 10 U.S. citizens have the surname 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.|
|What street did you grow up on?||The 15 most common street names are Second/2nd, Third/3rd, First/1st, Fourth/4th, Park, Fifth/5th, Main, Sixth/6th, Oak, Seventh/7th, Pine, Maple, Cedar, Eighth/8th, and Elm.|
|What was the make of your first car?||Most cars are built by Acura, Audi, BMW, Buick, Cadillac, Chevrolet, Chrysler, Daewoo, Dodge, Ford, GMC, Honda, Hummer, Hyundai, Infiniti, Isuzu, Jaguar, Jeep, Kia, Land Rover, Lexus, Lincoln, Mazda, Mercedes-Benz, Mercury, Mitsubishi, Nissan, Oldsmobile, Plymouth, Pontiac, Porsche, Saab, Saturn, Subaru, Suzuki, Toyota, Volkswagen, or Volvo.|
|When is your anniversary?||The average length of a marriage is 7.2 years, giving 2,628 likely dates.|
|What is your favorite color?||There are around 100 common colors, even considering colors such as taupe, gainsboro, and fuschia.|
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.
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:
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
A security system is never complete without user participation. Users have a unique perspective that allows them to spot security problems that administrators and developers may overlook. But to participate in security, users need knowledge and tools. It is up to you to provide the knowledge and tools they need. In this section, you will learn about:
|Summary:||Users must know how to protect their accounts|
|Threats:||Account hijacking, social engineering, identity theft|
With the increasing dependence on the Internet for financial and business transactions comes an increasing threat of Internet crime. Identity theft, fraud, and online scams are rampant, and Web site security can only go so far. At some point, users must take responsibility for protecting themselves.
Despite great advances in security technology and techniques, users consistently fall for the same scams they fell for since the very beginning of electronic communication. For example, users will click links on HTML pages and e-mails and will eagerly enter account information in an e-mail-based form, and many users will divulge their passwords to someone who claims to be an administrator or help-desk technician.
Many users of online financial institutions and other Web sites have fallen victim to spoofed e-mails intended to steal user account information, an attack know as phishing. In these cases, users receive an e-mail such as that shown in Figure 1.12, explaining an account problem and asking them to authenticate using the provided form. The form submits the personal information to a Web server controlled by the fraudster and then transparently forwards the information on to the real Web site. The user is not aware that his or her information has been stolen until it is too late. Fortunately, these e-mails are notorious for poor English grammar and spelling, such as the word unnormally in Figure 1.12.
Another variation of the scam is to send users an e-mail that looks like plaintext but that is actually an HTML-based e-mail. Links appear to be one (legitimate) URL but take the user to another URL with a fake login form that looks identical to the original. Yet another variation is to encode or obscure the URL in such a way as to trick the user into thinking she is visiting one site while she is, in fact, visiting another.
If users are not aware of the techniques used by scammers, fraudsters, and identity thieves, the users will consistently fall victim to these social-engineering techniques. Users who are not smart about security may fall victim to account hijacking or identity theft and put themselves as well as others at risk.
|Summary:||Involving users in security will raise awareness and help limit attacks|
|Threats:||Account hijacking, social engineering|
Once I was talking with a friend about a scam e-mail sent to customers of a major bank, asking them to log in to their accounts through a form provided in the email. I mentioned that a surprisingly large number of users fell for the scam, despite the obviously poor grammar in the e-mail message. My friend mentioned that he had actually received that e-mail and was proud to say that he immediately recognized it as a scam and deleted the message. But how many users could he have protected if he had instead reported the e-mail to the company?
Many users are aware of scams, fraud, or other suspicious incidents and never report them. My friend’s reasons for not reporting the suspicious e-mail was that first, someone else probably will, and second, he wouldn’t even know where to start to report the e-mail.
Users can play a great role in security if you make it easy for them. Since some users are already technically savvy and security-educated, you should give those users access to advanced security tools or security options. For example, some advanced users might want to set an option to only allow access to their accounts from specific IP address ranges. Advanced users might also want access to advanced security reports for their accounts.
If users have no way of identifying and reporting security incidents, the impact of a security incident could be larger than necessary. Design the system in such a way that all account actions are easily audited and reported. Provide conspicuous links for identifying and reporting security incidents. Create a modular design that allows users to easily customize their own security options.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form. You will also gain access to thousands of other FAQs at ITFAQnet.com.
A: Many people believe that generating completely random passwords will best protect users. But keep in mind that it is extremely difficult for users to remember a random password such as jD4nWpa8v, likely requiring them to write it down. Perhaps a better solution is to create a more memorable password made up of multiple random English words and punctuation. Users are more likely to remember these passwords, and you can even get away with giving users longer passwords.
A: If you are using a hashing algorithm, the hash itself is a fixed length, regardless of the size of the password. In other words, a seven-character password produces a hash the same length as a 200-character password. So if you use password hashes, you do not need to enforce a maximum password length.
A: Some Web applications are based on user interaction and cannot completely prevent username harvesting. To counteract this potential danger, allow users to change their usernames and set aliases for their accounts.
A: This is the most secure policy, but it could cause users to find measures to circumvent this inconvenience by writing down passwords or following predictable patterns. A better solution is to encourage stronger passwords and allow users to keep them longer.
Q: After a password reset, what is the point of putting a link in the e-mail rather than the actual password? If a hacker can access the user’s e-mail, he can just as easily access the link in an e-mail. Why not just e-mail the user a temporary password?
A: It is true that a link in an e-mail is just accessible as the password itself, but there are other reasons for doing this. First, it establishes a secure communication channel when the user clicks the link. Second, it allows the Web server to record the client’s IP address and time of visit. Third, it prevents the user from saving an e-mail containing the password. And finally, if the user no longer owns the e-mail account or if the e-mail is routed incorrectly, it prevents others from obtaining the user’s password.
A: Temporary passwords are not bad, as long as you force them to be temporary. The best technique is to mark them as already expired so that when a user logs in she is forced to immediately change her password.
A: The best way to get users involved is to allow users to discuss security in a public forum or via a mailing list. Such a forum is a great way for your organization and your users to discuss current security issues. But be careful to monitor the forum, since they are sometimes used as a way to social-engineer users into revealing their passwords. A fraudster once posted phony support phone numbers at an online payment support forum, instructing users to call those numbers to report security incidents. If someone called those support numbers, the fraudster on the other end first asked them to “authenticate” themselves by revealing their passwords.