Often, while my students are working on a lab, I’ll take this time to search for more class demos. It seems that many of the demos we discuss in class soon get fixed. I’m not sure how or why, but this is often the case. Parameter manipulation — they’re all fixed within a few weeks of discussing them in class. The list goes on, but this is so frequent that I stopped tracking them. Regardless of the reasons, these vulnerabilities get fixed, and I’m glad they do. And I really don’t mind doing some basic research into finding more. So here’s today’s example, as it applies to password policy and authentication fun.

I’ll start off by listing some common authentication-related vulnerabilities I often see and then discuss some error messages I recently found on a popular travel site. I’ll also add some “malicious” ideas, just for fun–to get you thinking.

Common authentication-related vulnerabilities:

  • Password policy is weak
  • Password policy is strong, but not enforced
  • No account lock out (or worse, account lockout tracked at the client side)
  • Login error messages let me know whether the username is valid
  • Password hints!

Related error messages from a recent find at a travel site:

  • “A password must be 5-12 characters long and have no spaces.”–when registering an account.
  • “The e-mail and password you have entered do not match. Please try again.”–when attempting to log in with an invalid username or password.
  • “That e-mail address is not on file. Please try again.”–when attempting to display the password hint for an invalid account.
  • Note: the password hint is happily displayed if you enter a valid username.

Some initial thoughts

  • How easy is it to harvest emails or buy a few million email addresses?
  • Could a quick script cycle through a list of email addresses and capture password hints?
  • How difficult would it be to guess a few password hints based on several hundred or thousand captured password hints?
  • This site allows you to save a credit card on file and use it to book travel/hotels/more without verifying anything.
  • I wonder if I could book travel on someone else’s account without them knowing. All I need to do is suppress the email confirmation or point their registered email to a different one. By the time the con has been exposed, the postcards I sent from Mexico will have been received.

Do you see where this is going? The main culprit wasn’t the password policy itself. If I had to write the equation, it would look a lot like this (seriously):

Mediocre password policy + password hints + stored credit card info + having a lot of users + nongeneric error messages + not verifying anything on checkout = free trip to Mexico.

Now, let’s go cliff diving in Acapulco!