Bad password requirements

This morning I signed up with a major credit card company website.  Much to my surprise I was greeted with this requirement while choosing a password:

Your Password should contain 6 to 8 characters . at least one letter and one number (not case sensitive), contain no spaces or special characters (e.g. &, >, *, $, @) and be different from your User ID.

Let's review these limitations:

  • 6-8 characters - Requiring a minimum of 6 seems reasonable but still not very strong.  Capping the length at 8 seems strange since this is still not very strong and why would you want to prevent someone from using a longer (and probably stronger) password?  Unless your database field or legacy systems only support 8 characters ...  Does that really mean they are going to store this password in clear text?  Maybe they use some sort of arcane encryption or hashing (hopefully) algorithm that limits the digest size to 8 characters.  Still seems unlikely.
  • At least one letter and one number - This seems like a smart option to force different character sets and improve the password strength.
  • (not case sensitive) - What?!  This reduces the size of the alphabetical character set by half.  This also throws into question whether they are really hashing this password - are there hash algorithms that ignore case?  This requirement makes no sense and definitely feels like a requirement for a legacy system.
  • No spaces - This is a shame since a non-written character like a space can be a great security mechanism especially when at the start or end of a password since it is invisible if the password is ever written down.
  • No ... special characters - Why would you explicitly prevent the use of another character set that can greatly improve the strength of the password?  Again this feels like a legacy requirement.

How strong is this password that they are forcing you to use?  I took a look through LockDown's Numbers and you can easily see how the number of possible combinations for this password is limited by the lack of character sets and case sensitivity.

I am really glad that I used an auto-generated password for this account. :)

Are you hashing and salting passwords in your applications or do you also have bad password requirements?

 

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?

8 Comments

  • I recently saw the same password requirements (Wonder if it was the same card) and had a lot of trouble finding a suitable password. Further more these are backed up by very simple security questions like what high school did you attend. A lot of the information for security questions is available.

  • Case Sensitivity is the number one reason why people enter passwords incorrectly. Can't say I blame them for going that route. Not allowing special characters seems rather odd.

    I worked at a place where the instructions for creating a pasword that was acceptable was so convuluted that tech support was constantly hammered with requests to reset passwords.

    Ask Grandma to figure this out:
    Passwords are case sensitive
    Passwords cannot contain dictionary words
    Passwords can't be similar to a previously used password.
    Password must have at least 3 letters.
    Passsword must have at least 3 numbers.
    Password must have at least 1 character that is not a number or a letter.
    Password must be changed every 30 days.


    I guess you need to find a balance between security and usability.

  • Most often this means that the password is stored unencrypted. American financial institutions are notoriously bad at security.

    Many Banks and financial institutions have multiple applications working on the same datasets and need your password for their authentication. Lots of these applications are old large systems (it may even be possible that one this one uses a mainframe somewhere that only supports the 36 charset) written before most people thought about secure passwords.

    I would try to avoid using this company as it is likely that they are not secure. Unfortunately your other options are pretty much just as bad.

  • I mostly work with web applications that I've inherited and just require customization. None of them use hashing or salting for passwords. They didn't even encrypt social security numbers until I came along and changed that. Currently I'm waiting for a hosting company to install WSE 3.0 so I can secure my web services. If you think about it, that situation should never have come about.

  • ha ha, sounds like am**. I liked how for a couple days, when you typed the password wrong, it TOLD you the requirements right there in the error message. i don't think it does that anymore.

  • rrobbins,

    Yes, most times when we do a security audit of an application, the first thing we find is cleartext passwords in the user table in the database. :)

  • Aside from problematic legacy code, often "restrictions" are placed on passwords to prevent the amount of support calls they receive about a lost password. It's a trade off of security Vs. convenience. Let's look at reasons to NOT use a a hash:

    1. Their system is probably old, and they are running on some old hardware. Hash algorithms are expensive for CPU cycles. That really doesn't apply with today's hardware, but if they have some server boxes running a Pentium II that's 300 MHz, it's noticeable.

    2. Passwords longer than 8 characters tend to be forgotten quickly, or lost. A lost password can be fixed in 2 ways, really: 1) a reset implementation, or 2) they just email it to you. While they may not be hashing it, they might use 2-way encryption like 3DES or AES. Since encrypted data is variable in length unlike a hash, they want to prevent a large database, and depending on their database, how much data they can put in a column.

    3. Back about 8 years ago, an 8 character password was considered "safe", but that was with weaker hardware, and with better hardware, it might be easier to crack. If they do use a hash, but no salt, then it can easily be attacked using a Rainbow Table.

    While I can understand any of these reasons, which may or may not even be the case, I find it ugly for a website where all of my credit and money is.

    My recommendation would be to implement a hash, such as SHA1 or SHA256. SHA1 is a reasonable solution for a password. It has some known exploits, but none that can be exposed if you are using it for passwords, even a 2000 character password is safe with SHA1, and add a salt to prevent rainbow table attacks.

    Using SHA-2 based algorithms (such as 256, 512) also slow down a rainbow table attack, due to the needed computing power, there are not that many precomputed tables for SHA-2 algorithms, or they are not even close to complete.

    Just my 2 cents..

  • Kevin,

    Very insightful - thanks! We should hire you. :)

    (For anyone reading, Kevin is already on our Thycotic team ...)

    Best.

Comments have been disabled for this content.