Web Application Security Followup: Password Strength

Published: 2007-09-24
Last Updated: 2007-09-24 22:53:18 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

One of the early leaders in security issues with banks is password strength. A lot of readers write in about banks that do not allow users to pick long passwords. The leader so far is a bank which only allows 7 character passwords and only allows letters a-z and numbers. (update: someone just wrote in with a bank that only allows 6 (!) characters)

We probably all know that longer passwords are better, and a common tip to achieve long passwords is a passphrase vs. a short password. A passphrase requires the use of punctuation marks and spaces, which some banks don't appear to allow either.

Now it may sound obvious that web applications will not allow single quotes (') or less than / larger than symbols, in order to avoid sql injection or cross site scripting. However, this is a bit a poor solution. And remember that passwords are not supposed to be stored in the clear anyway.

Regarding storing passwords in the clear: Some users report somewhat arbitrary password requirements like 20 characters. This may actually be an indication of passwords stored in the clear. A hashed password should always result in the same length hash, no matter how long the original password. On the other hand, if the original developer picked a "char(20)" database column to store the passwords (in the clear), then the password will be limited to this size.

Couple "mitigating" notes:
- Frequenlty, web application password strength is limited by legacy backend systems. This may also require the use of clear text passwords. Legacy issues may also be responsible for case insensitive passwords.
- if you only got 8 characters to work with, you can still use the passphrase approach, but you just pick the first/second or whatever character from each word. "I visit the ISC 3 times a day" becomes "ivti3tad".

A couple lines pseudo code on how I like to see passwords stored:

store password:

$userid=validate_userid($Form->get("userid"));
$password=validate_password($Form->get("password"));
$hash=sha1($userid+$password);
$db->store($hash);

check passwords:

$userid=validate_userid($Form->get("userid"));
$password=validate_password($Form->get("password"));
$hash=sha1($userid+$password);
$dbhash=$db->select("usertable","password",userid=$userid);
if ( $dbhash == $hash ) {
$Session->set("userid",$userid);
redirect("logged in");
}
redirect("badlogin");

 

 

Keywords:
0 comment(s)

Financial Website Security

Published: 2007-09-24
Last Updated: 2007-09-24 12:51:38 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

Financial websites (banks, credit card companies, investment companies) are probably the biggest targets for hackers out there. I am sometimes a bit surprised by some of the blatant security issues some of these websites have. Just a few weeks ago, after "reseting" my password with a credit card company, I received my old password in plain text via e-mail. One of the classes I teach most frequently for SANS is the Web Application Security class. I do use a number of problems like this in the class to make the material covered more real. However, it would be nice to have a more complete catalog of these problems.

If you run into a blatant big problem with a financial site, please let us know. We will notify the site, but if you wish we will not mention your name. DO NOT "HACK" OR PENTEST ANY SITES WITHOUT WRITTEN PERMISSION FROM THE OWNER OF THE SITE. We are looking for problems that you run into as a regular part of doing business with the site.

Once we notified the sites, we will post some examples here. Again, we are looking for *big* problems like:

  • passwords sent in the clear
  • insufficient user identification to reset the password
  • cross site scripting (again, DO NOT TEST)
  • SQL errors / Java errors and the like visible to the user.
  • Site does not allow long passwords.
  • badly formated / worded e-mails that encourage phishing.

Things I consider minor or things we don't want to cover right here:

  • non SSL login forms that submit to SSL servers (we already covered that in the past).
  • login pages that give different errors if a username doesn't exist.
  • site downtime.
  • site allows the user to opt in for certain e-mail notifications, even if the notifications reveal balances and the like.

Please use our contact form to submit reports. Did I mention NO HACKING?!

 

Keywords:
0 comment(s)

Comments


Diary Archives