If you're like me, you select special unique passwords for the sites that count, such as banks, and you use a fairly simple password for things like accounts on blogs and message boards where you're not particularly scared if somebody learns the password. (You had better not be scared, since most of these sites store your password in the clear so they can mail it to you, which means they learn your standard account/password and could pretend to be you on all the sites you duplicate the password on.) There are tools that will generate a different password for every site you visit, and of course most browsers will remember a complete suite of passwords for you, but neither of these work well when roaming to an internet cafe or friend's house.

However, every so often you'll get a site that demands you use a "strong" password, requiring it to be a certain length, to have digits or punctuation, spaces and mixed case, or subsets of rules like these. This of course screws you up if the site is an unimportant site and you want to use your easy to remember password, you must generate a variant of it that meets their rules and remember it. These are usually sites where you can't imagine why you want to create an account in the first place, such as stores you will shop at once, or blogs you will comment on once and so on.

Strong passwords make a lot of sense in certain situations, but it seems some people don't understand why. You need a strong password in case it is possible or desireable for an attacker to do a "dictionary" attack on your account. This means they have to try thousands, or even millions of passwords until they hit the one that works. If you use a dictionary word, they can try the most common words in the dictionary and learn your password.

Hashed password

There are two main places where dictionary attacks and more advanced brute force attacks are probable. In the first example, passwords are stored encrypted or hashed, and the final hash is public knowledge or might be learned by an attacker. This was the state of the original Unix password file, though it's quite uncommon today for the password hash to be public information. Encrypting or hashing passwords makes a lot of sense. In this case, the site does not know your real password. Instead, they have the ability, if a password is typed into them, to test if it's the right one. If it is they let you in. This is good because it's difficult to learn your actual password from what they store. You can use it somewhere else without fearing (almost) that they will be able to pretend to be you.

For true security, however, this is still a question of trust. Since you do type your password to them on the login screen, you only have their word that they forget it after you type it. If they wanted to, they could still remember it and thus learn your shared password, or the words you use in a password. (Many people, while not using the same password at mutliple sites, do simple variants of a core, and are at risk from any of the sites who can learn the core.)

You do gain some security if their password database is compromised. The thief doesn't have your password. However, the thief now can do a dictionary attack easily on all the passwords, and will learn any passwords that are things like simple words or people's names.

The downside of hashed passwords is the site, because it doesn't know your password, can't recover it for you. You can tell most sites don't use hashed passwords because they offer to e-mail you your password if you forget it. A site that uses hashed passwords can only offer to reset your password, and possibly e-mail you a new random one. ==Easy login== The other way an attacker can try dictionary words is if the login screen lets them try to login quickly and frequently. If a web site lets you try 1,000 different passwords, it can be attacked this way. That's why most good login designs will only let you fail to login a modest number of times -- enough to help you remember which passsword you used, but not enough for a dictionary attack.

They must be good about this, and deal with attempts coming from a botnet of thousands of machines, and with attacks that try lots of userids with each password instead of lots of passwords with each userid.

However, as long as a site does this, and especially if it stores the real password in its databases, a strong password does not gain you much for sites that aren't that important, and it's wrong to force people to follow your particular rules. Indeed, putting on rules that are too restrictive often causes people to make other mistakes, like write down these new hard-to-remember passwords, or choose them with very simple applications of the rules. For this reason a recent study showed that making people change passwords every few months could actually hurt security rather than help it.

Choosing

All this said, a dictionary word may not be the best choice. And a guessable password using simple information about you (such as pet's name, family member names, etc.) is always a bad idea. Things like mother's maiden names and last-4 of SSN are very foolish choices, though banks will use them.

A good way to create a decent password that's easy to remember is to take a sentence that means something to you (though not a famous aphorism) and use the initials. Rather than write that down, you can even remember something like "It's the first sentence on page 99 of my paperback edition of a given book." If you want it to be stronger, you can then add digits or spaces to make brute force attacks very difficult but still be able to remember it.

Real Answers

As I have written before, however, passwords for remote login are not a great idea. For unimportant sites, a simple digital signature login with a password only used for roaming ability makes sense. (With digital signature, providing a public key gives the site zero ability to use it to log in to a different site, and traditional phishing is impossible.) For important sites, we must move to having a physical token we carry with us -- the obvious choice is the cell phone -- combined with a shorter PIN number entered from time to time in case the token is stolen. Let's have real security where we need it, but not apply overly complex security where we don't.