Wordlist for Common Pet Names

If you are testing web applications for security, be sure to examine the Forgot Password functionality and attempt to subvert it.  It's another way that users can authenticate to the app and is often less secure than the primary method.  First you'll need to enumerate usernames (try the username wordlists I made available a while ago).  Once you have some valid usernames, the Forgot Password functionality will often present you with a challenge to answer one of the user's personal security questions.

One of the most common security questions you see is "What was the name of your first pet?".  If the application doesn't limit the number of attempts, you have a very good chance at answering this question by iterating through different names with a tool like Burp Intruder.  The last time I did this successfully, "Rocky" was the name of the user's pet.

You need big list of common pet names to do this.  That's exactly what I'm providing here for your download pleasure.  My wordlist currently has over 1,400 pet names.

  Click here to get the pet name wordlist

Enjoy!  Obviously my list can't cover every conceivable pet name, but please let me know if you think I'm missing a common one.

Implementing Forgot Password with Email

It turns out that application developers sometimes need to implement a forgot password feature but don't have much identity data about the users in the system.  Neither can they always be so flexible as to require users to establish personal security questions.  These things are a key part of my forgot password security recommendations.  But the reality is that sometimes you don't have any information about a user except their username and email address.  Heck, sometimes email address IS the username.

In this type of situation, implementing a secure forgot password feature is challenging.  Sending a password reset link via email is probably the best option (barring a non-automated solution where users call customer support).  So here I will offer up some specific ideas on how to secure the process when using email.

1. When a user invokes the forgot password process, don't say anything about whether the username entered was recognized or not.  It should simply display a generic message such as: "Thank you. If the username you provided is valid, we will send you an email with instructions on how to reset your password".
2. Along with the above, don't show the email address where the email was sent.  It might give legitimate users a warm, fuzzy feeling but it definitely helps attackers in a number of scenarios.
3. The password reset link in the email message should incorporate a GUID or similar high-entropy token. The token could be a parameter in the query string or part of the URL path itself.  It doesn't really matter.
4. Allow only one valid token per user at any given time.
5. Make sure the email message does not include the username.
6. Make sure the link can be used only once.  In other words, invalidate the token immediately when an HTTP request containing that token is received.
7. The link should expire.  Depending on your situation, implement logic to invalidate the token 10, 20, or 30 minutes after the email is sent out.  Make it a configurable value so it can be adjusted if needed without a code change.
8. The password reset page (the one that appears after clicking the link) should force the user to re-enter his username.
9. If the username entered is incorrect 3 times in a row, lock the account.  Remember, your application knows which username is associated with the token.  The person attempting to reset the password should know it as well.
10. After a successful password reset, send a confirmation email to the user to notify them it happened.  This can alert users to fraud if they didn't initiate it.
11. Throughout each step of the process, make sure the application is logging everything that occurs so there's a solid audit trail in case something goes haywire.

So those are the mitigating controls I came up with.  Feel free to let me know in the comments if you have any other ideas!

(updated on May 5, 2014 based on some feedback I received)

How I Keep Track of My Passwords

We all know that you shouldn't re-use the same password on different websites, but this is extremely difficult in practice considering the number of sites people use today.  Password managers were developed to help solve the problem of remembering passwords.  Some examples are KeePass, Password Safe, and LastPass.  They work fine for many people.  However, I personally don't like the idea of depending on a password manager.  I want the ability to pull the correct password out of my brain in case I'm ever in a situation where I don't have access to the password manager.  There's also a risk that your passwords could be compromised (this is true about any data that is stored, encrypted or not).

I have over 100 different passwords, but I don't have any problem remembering them.  I don't write them down or use any sort of password manager.  I came up with a system that enables me to remember my passwords.  It works for me, so I'm sharing the technique in case anyone else thinks it might be helpful.

With my system, you only have to remember two things.

1. A core password.
2. Your scheme.

First, come up with a strong core password of about 8 or 9 characters.  This core piece should be random gibberish and needs to have a lowercase letter, an uppercase letter, a number, and a special character.  An example is kM92ax4!. Whatever you decide upon, memorize it.

Second, pick a scheme based on the website's domain name.  The scheme is used to supplement your core password.  As a simple example, your scheme could use the last 3 characters of the site's domain, add one letter to each (this is actually an encryption technique called "ROT1"), and append this to your core password.  

So for the site "www.verizonwireless.com", we see the last 3 characters of the domain are "ess".  Therefore the 3 additional characters would be "ftt" and your final password is kM92ax4!ftt.

For sprint.com, your final password is kM92ax4!jou.

For att.com, your final password is kM92ax4!buu.

Come up with a any scheme you want as long as it's based on the website domain.  Here are some other possibilities:

• Prepend the first character to your core password/append the last two 
• Capitalize one or two of the letters
• Subtract two letters ("ROT24" encryption) instead of adding one
• Look at the first two chars + last char of the domain, instead of the last three

You get the idea. The scheme remains constant, but your password changes.  Whatever you decide, never tell anyone your core password or your scheme.

My system isn't perfect.  It doesn't work on sites that have a short maximum password length (like 10) or onerous password requirements (like requiring you to change it every 90 days).  But overall it has worked great for me.

Account Lockout Fail

A while back I was hunting for vulnerabilities in a web app's Forgot Password feature. On the first page you had to enter your username and email address. The second page asked a personal security question. That is quite weak. I recommend asking for at least 3 pieces of data on the first step. Asking for only two inputs, especially when they are username and email address, is not very secure. Username and email address are often related. If you know one, you might be able to guess the other. For example, the email address for user "jthomas" could be "jthomas@yahoo.com". I also recommend asking two personal security questions on the second page, not just one.

Anyway, one of the things I like to check is whether or not the account is locked after a certain number of failed attempts to answer the security question(s). This is an important defense against attackers who are trying to break in via the Forgot Password functionality. Sure enough, the message "account has been locked" appeared after I purposefully entered 3 wrong answers.

I was just about to make a note about this commendable practice, but something caught my eye. The input field was still there on the page. That's not something you normally see. Usually the application takes it away after a lockout occurs. So being a curious fellow, I proceeded to enter the correct answer to the question. Lo and behold the application sent me to the next page where I was allowed to reset the password on the account. Now that's an account lockout fail! I'm not sure why or how the developers created a lockout message without actually coding the lockout. Just another example of how difficult app security can be.

Latest Forgot Password Best Practices Doc

A new version of my white paper entitled "Best Practices for a Secure Forgot Password Feature" is available. You can download the white paper here. No significant changes were made in terms of content, but it does have fewer pages and a more pleasing look now. The link I had given out previously is no longer valid.

The white paper was used as the basis for the OWASP Forgot Password Cheat Sheet.

Who Has the Answers to Your Security Questions?

I'm back after a summer that was crazy busy for me. Recently, I had two eye-opening occurrences where other people viewed the answers to my personal security questions - you know, those questions that web sites ask in case you forget your password. These incidents weren't security breaches, just normal business processes that appear to be more prevalent than I thought.

In the first incident, I got a new cell phone for my daughter at a retail store of one of the major providers. I gave the clerk my cell number so he could look up my account and he then asked for my "PIN". I didn't know it. I knew my password for their site, but that's not what he wanted (I wouldn't have told him anyway). Since I didn't know my PIN, the clerk followed up by asking me "What's the model of your first car?". Whoa. I proceeded to answer the question. He looked at his monitor and said "okay, good".

The other incident involved Vanguard again. I got locked out of their site (not just unrecognized like last time). The darn thing wouldn't even allow me to answer my security questions. Forced to call Vanguard customer service, I explained to the CSR that I was completely locked out. Wouldn't you know the CSR simply asked me to answer two of my security questions? I provided the correct answers, and he immediately unlocked my account allowing me to log in again.

Moral to the story: These answers are not simply being used programmatically or being treated as confidential data. Realize that the answers to your personal security questions could be viewed by other people in many cases.

Forgot Password Best Practices v2

I just finished an update of my white paper that describes best practices for creating a secure "forgot password" feature. There are two important additions to the paper.

• A section to describe an extra step that can be taken to provide even more protection. This step involves using email as an out-of-band communication channel.
• A paragraph to explain that the recommendations may not be feasible for all web sites. The concepts presented in the paper are most relevant for organizations that have a business relationship with users.

I also dumped of "Billy Bob" as the name of the hypothetical user in favor of "Joe". I grew tired of the campy name and don't want to imply that users are stupid or unsophisticated, even though some could perhaps accurately be characterized in that way.