Why do web applications insist on defining strict password rules?

Question

You've all encountered the various websites that force you to have a password that is 6 characters long, must have 1 number, and must rhyme with 'annoying.'

Obviously there are legacy reasons why sometimes this is necessary but other times it's all for security. I find that it's rather annoying because I have a standard set of passwords that often don't match these peculiar rules so I have to make and remember a new one.

It seems that there are more important things to worry about in terms of security if you're worrying about how complex the user's password is. If someone can actually get a hold of that password then you clearly have larger problems to worry about. Do your part and lock down your end of the system before relying on the user to worry about YOUR security.

My actual question is: What are the alternatives to these complex password rules to mitigate the risk of rainbow tables or brute force hash reversers without relying on the user to carry the weight of remembering something complicated?

Some ideas: salting, ...

Answer 1

Use KeePass

http://keepass.info/

It sure will minimize the hassle.

Answer 2

Almost every site will be salting and encrypting your password regardless of what you choose. The issue isn't legacy code, database security on the server side or anything like that, the developers will have that covered in most cases. The problem is dumb users submitting retarded passwords that get broken quite easily. The point of the rules is to FORCE you to not choose too stupid of a password.

Here's a reference link. http://www.codinghorror.com/blog/archives/001206.html

Answer 3

The reason for the password rules is to try and ensure a "stronger" password, which means, in effect, that it takes more trials on average to find the password with a brute force attack. Most people, even after the many examples, like the recent Twitter mess, will use a Joe password, or a dictionary word that's vulnerable to a feasible brute-force attack.

The best thing to do is to ask what the value of the data behind the password is, and then what the cost (effort) of cracking the password would be. If the value is small, you dn't need complicated rules, and maybe you don't need a password at all. If the value is high, then you need to make it more difficult.

Answer 4

Keepass also has the advantage that it will run directly (eg not even have to install it) from a USB flash drive in most cases in windows. Put both keepass and your database file on the USB key and u have a quick and easy portable password reference database. Make sure u secure keepass with a nice strong password though as if u loose your USB drive u don't want all and sundry getting into your password database.

Answer 5

Anything an untrained user (the normal type for most web applications) will find natural and easy to remember will be easy to crack. It doesn't matter what you do to store it, because cracking software can go through all passwords an untrained user is likely to use. Salting and hashing are effective only when the users have good passwords.

The solution is either to ask the user to remember something more complicated (which you are rejecting) or to base verification on something the user has, rather than what the user can remember. This can be a written-down password, one of those security fobs that generate unpredictable numbers that change every few seconds, or something more esoteric.

What a website can do is allow all sorts of strong passwords. I detest sites where I want to use strong passwords (typically financial or medical) that have rules like "no special characters". (Of course, I don't like reusing strong passwords; I don't want anybody who cracks my HMO security to order freely from my Barnes & Noble account.)

This probably isn't the answer you wanted, but the bad guys have capabilities that will overwhelm the sort of casual security most people are comfortable with.