July 20, 2010

Restrictive Password Rules Are Bad, mmmmk?

There are all kinds of things that a discussion of password security could go into, for example:

  • Why passwords need to be stored properly on the data system
  • How does a mixture of password implementation policies protect the system from account hacks?
  • The risks of rainbow tables and cloud computing
None of those topics are the topic of this discussion, but they are all integral to the security of your password authentication system.  Never mind that secondary authentication via tokens or biometrics are really the way to go if you want system security.  Lots of enterprises and most Internet services are still stuck in the userid/password authentication age.  In order to understand the topic that I'd like to discuss, it is important that all of the above

  • Why restricting your users to seemingly arbitrary or complex rules actually lessens the strength of your password system.
The prevailing argument is that users will not create complex passwords unless they are forced to do so.  Because of this, users must be forced to create passwords that will not fall prey to 'dictionary' attacks against the account.  And this argument has some merit.  After all, even with the proper policies in place, if the user selects a password of 'password', their account will fall prey to someone trying to break in.

However, some have taken the step of implementing password rules to a level that it is actually damaging to their password system, and they may not realize it.  After all, the password 'password' may no longer be the first most used password on their system because it isn't allowed, but the password "1234qwer!@#$QWER" is probably at the top of any good hackers list, and is allowed by even the most restrictive of password rule systems.  Just because this second data string doesn't make sense to us doesn't give it any magical properties of being more secure than the 'password' password.  Nay, for a computer, the second password has more patterns in it that the first ever did.

Recognizing a bad password is not something that is easily understood (although it's not an impossible task for an AI engine), but what the system administrator needs to know is that their password rules need to be in  place that will make it as unlikely as possible that the user would create such an easily guessed monstrosity, and that the password the user creates will be both secure and easy to remember.  This means both having restrictions (to ensure that single words and '123456789' are not used as passwords), and having reasonable and easy to meet restrictions that the user will be able to come up with a good password when asked.  Once the restrictions get too tight, the user is going to logically process the rules into a pattern because they cannot easily come up with something that meets the restrictions.

Another problem is restricting the size of a password field is something that should never be done.  Limiting a user to only 8, 10, 12, 14 characters is entirely arbitrary, and speaks to improperly implemented password storage systems.  If you have a maximum limitation on your password, it screams to the world that you are storing the password either in clear-text in a data system, or something that any hobbyist cryptographer could crack open (rot13?  XOR data field?).  If you properly implement password storage as one-way salted hashes in your system then it won't matter how long the user password entry is.  You should give them more than enough room to enter any reasonable string - arbitrarily, say 256 characters, so you can size the field and protect from buffer overflows, but you get the idea.

What about complexity requirements?  They need to be simple to understand, and should be free of 'systemic' requirements.  You should not forbid the use of any valid entry character.  This may mean even allowing the entry of such no-no's as ',@ and " - if you don't accept these characters, you're again telling the world that you're doing something with the password you shouldn't be doing, like storing them in a database.  Complexity should be simple to follow and easy to come up with something useful...perhaps a restriction to use at least one character from each of the sets:   UPPERCASE-LETTERS, LOWERCASE-LETTERS, SPECIAL-CHARACTERS, NUMBERS.  This is easy enough to follow just by using natural passwords like I*Hate%Passwords.

The more restrictive your rules, the more likely your users are to rebel by using something systematic (QWERTY12345qwerty!@#$%).  If you frustrate your users, they'll just be looking for a way to get around your 'stupid rules' rather than be a partner in protecting their information.  You'd much rather get someone to be inventive (like: Rosemary'sBaby1997).  This password may seem simple to you and me, but it's because our minds are tuned to pick up and categorize the symbols in the password.  For someone who doesn't know the password, it's going to take a LOT of guessing to get that password from the system.

And if you're properly hashing, salting and securing your password (shadow) file - a dictionary attack is going to have a hard time guessing that password at 3 allowable guesses per hour (between lockout).

Less focus should be spent on protecting yourself from system administrator staff who may have access to the secure password hashes and salt.  If they want to get into your system, they have much more direct ways to impersonate users than pulling down that data and running computations against it.  Instead, the focus on password security needs to be:

  • Implement proper password storage and validation
  • Partner with the user - don't piss them off
  • Implement password and account policies that don't enable hackers to use your own CPU power to attack your accounts. (Account locking after so many guesses, only allow single sessions when feasible - session timeouts, disable session re-use, etc...)
  • Log and monitor logs for suspicious activity
  • Warn users when their accounts have been used (and ask them to validate the usage)

July 08, 2010

Dropping Data into the Cloud

Yesterday I signed up for DropBox, a personal cloud storage folder that stores and synchronizes a folder across any machine that I install the software and login to my account with on the web. It's sort of like a flash drive that I don't have to carry with me, and they start you off with 2.25GB of storage. You can earn up to 8GB of free storage (if you tell other people about the service and they sign up through your referral link).

A short word on a security standpoint. DropBox makes a claim to encrypt your data, but the software that you would use to encrypt your data is theirs, so trusting it to actually secure your data would need to be earned. Their encryption claim states that your password is the only way to decrypt your data. You'll be storing your password in the client you use to access the information, though, so if someone steals one of your devices with a client, you're going to lose the security of the account until you change it. Using cloud storage for your information is entrusting your data to complete strangers. If you decide to use the dropbox service, you need to understand that it is completely likely and eventually probable that at some point in time, your information (that you've placed in your dropbox) will be made available to someone else. It could be an internal break-in from a DropBox employee, but even more likely it will be a weakness in the DropBox system that exposes your data.

So, what good is cloud storage? It's good for storing semi-public information. For example, I use it to store several copies of my resume that I need to be able to access just about anywhere. I've also put some pictures in the dropbox to share with a friend. If you treat the storage container as if it were a public lockbox and the lock is no more secure than a gym locker padlock, then you'll be able to keep the right frame of mind on the service. Be careful out there.

EDITED: DropBox claims to encrypt your data, with a key protected by your userid/password. Remember that the security of an encryption algorithm is only as secure as its implementation and the security of the encryption key. If your userid/password can get the decryption key, then the security of that information is how strong the encryption is. There is no mention as to how that information is protected at DropBox.Com.