Learn how to create good passwords easily. Your pet's name is not a good password. There is a tool to help you to choose a good password for a new online account, or - if you are a systems administrator - for getting secure passwords for newly-created accounts. There is no need to settle for "letmein", "w3lc0m3" or "password1" as default passwords.

Better still, is to understand what constitutes a good password. I aim to develop this into a compendium of the best advice for password creation. Some accounts need little security; others need strong security. It is not always obvious which is which.

How to use passwords

Firstly; passwords that you have to use for work. Never re-use them, and certainly never use a password that you have used when working with one employer, when working for another employer. It's safe to assume that if you need a password at work, the password will be stored as plain text somewhere. The prevalence of Intranets makes this problem worse; you may have given your password to many mini-empires within the company that you work for, to access their part of the intranet. I'm sure that your previous employer is entirely ethical, and wouldn't consider using your password to try and break into your new employer's network. If there was a security breach because somebody somehow knew your password, it would be safer to be entirely confident that it was not due to password re-use.

Other accounts are those which are personal to you. As a general rule, the better-known the company, the better you might trust the password. So you might have a password of "fr3d" with eBay, and "fr4d" with PayPal; they're the same company, and if one gets hacked, the other is about as vulnerable. Also, "fr4d" is actually more secure than "fr3d" because "fr3d" matches a known word ("Fred") better than "fr4d" does.

Don't use "fred" as the basis for your Google, or Amazon, or Bank password, then. Dedicate that password to the account you associate it with. This may well mean that you have many, many passwords.

There is nothing wrong with writing down your passwords.

Just don't keep them online, and do keep them secure. Don't write them on Post-It Notes on your monitor or under your keyboard. Do write them on paper, keep the paper in a sealed envelope, and check the seal on the envelope regularly. Also, it might be a good idea to tell your spouse or close kin about your password arangements, to help them to deal with your assets in the case of your death. (Like making a will, this isn't a terribly palletable issue, but we all die. It could be fifty years from now. It could be tomorrow. It could even be today.)

Categories of password

I categorise passwords into three different categories. In a few situations, you can find out the category used to secure your password just by asking. Usually (particularly with website passwords), you just need to look at how (if at all) the "forgot password" function works. This isn't a totally canonical list; email may not be the medium, your login name may be used in place of your email address, and so on. The underlying structure remains the same, however.
The three categories are:

  1. We'll email your password to your registered email address.
  2. We'll email your password reminder to your registered email address.
  3. We'll reset your password and email the new password to your registered email address.

1. Plaintext Passwords

Category #1 requires the website to store your password in plaintext: if your password is "letmein" then there is a database with "letmein" stored within it. If someone can break into that website's database, they will be able to get at your password. In fact, an attacker would then be able to retrieve all passwords stored by that website. (That need not concern you, but it's a security flaw for the website). More directly, someone who can get your email password can retreieve all passwords for any websites you have accounts on which use this category of password control.

2. Password Hashes

Category #2 avoids this, and uses a "reminder" system to avoid storing and using the actual password. They can store an encryption, or hash, of your password, and when you log in, they will compare the hash in the database with the hash of the password you typed in to the login form.

For example, if your password is "letmein" the MD5 hash of that password is 0d107d09f5bbe40cade3de5c71e9e9b7. It is easy to create a hash; however, it is very difficult to convert the hash back to the original password. By storing the hash of your password, and comparing that to the hash of the password you provide when you log in, the website avoids having to store "letmein" anywhere on the system. This means that if an attacker gets in to the database, they still won't know your password. It also has the side-effect that the website can't remind you of your password if you forget it. For that reason, they store an additional field; a question to which only you are likely to know the answer. "Mother's maiden name" and "Pet's name" are common (though poor; see below) examples. If you can provide your email address (or other identification token), and answer the "secret question" you can change the password.

Whilst far better than category #1, this is not as secure as it might seem. For one thing, your email address is far from secret. For another, many websites use the same questions; if I can break in to just one website that you use, I can find your mother's maiden name, and then get in to many more accounts on other websites. Even banks often use mother's maiden name as a security check. Forget cracking into databases; pick a friend, colleague, or cohort, whose family you don't know. Start up a conversation with them, with the intention of finding out their mother's maiden name (or their pet's name, or their favourite colour, or whatever "secret question" you like).

In a five-minute conversation, it is easy to discover a relative stranger's email addreess, mother's maiden name, favourite colour, and/or other such non-secret information. Blogging, pursuing family trees and posting to usenet are just a few more ways in which we can inadvertently make this supposedly-secret information extremely public.

One very large company that I know of, suggested to their employees that, to avoid this problem, they provide not just false, but meaningless answers to such questions:
          Q: What's your favourite colour? A: Fish.
          Q: What's your mother's maiden name? A: Photograph.
This is completely pointless; it would be easier to remember the password than to remember the incorrect answers. Joel Spolsky mentions one solution:
          Q: What is Aunt Vera's cat's colour?
          A: Aunt Vera doesn't have a cat.
This is a decent decoy; however, he will still need to remember that the answer isn't "She doesn't have a cat" nor "She doesn't have one" nor "She's not got one" and so on. Still, it's a good technique, especially if (as in this example) you can frame your own security questions.

3. No plaintext storage

This is a more secure solution; The database simply does not know what your password might be, and doesn't depend on brittle (once discovered, completely useless) pseudo-secret information. Instead, it simply assumes that you know the password, and will simply reset the password if requested. The better of these don't even acknowledge that an email has been sent; if you enter an email address into the "forgotten password" form, they will simply confirm that, if the address (or other ID) supplied relates to a registered customer, then they will have been sent an email. Otherwise, the form itself could be used to find out who has an account on the system. This would make phishing fraud more directly targetted, for one thing.

If your account is attacked, you will receive an email saying "your new password is 'd93p2w3d'" so long as you have access to your email account, you will know that somebody has requested a change, but (a) they don't know the new password (unless they've cracked your email also), and (b) you know that an attack is happening, so you can start to take actions to mitigate the risk, such as removing personal information from the account, changing the email address to one which is more securely protected (in case the attacker can also get access to your current email account), changing the password of your email account (in case the attacker does have it), and so on.

The Schneier Test

In his excellent book Beyond Fear, Bruce Schneier proposes five steps to determine the effectiveness of a proposed security solution.

Step 1: What assets are you trying to protect? Online identity.

Step 2: What are the risks to these assets? Access to further personal information, and the ability for an attacker to conduct transactions (e.g. eBay, PayPal, banking) in my name.

Step 3: How well does the security solution mitigate those risks? That is really the question being answered above. Category #1 uses a password to protect access to the account. Category #2 encrypts or hashes that password but protects it with potentially easily-guessable questions. Category #3 is similar to #2, but by not using brittle (once-guessed, then useless) secret information is actually more secure for keeping less information about you.
All the techniques listed above use a registered email address as the recipient; taking control of a mailbox would allow an attacker to find some information; Category #3 is actually weak in this event.

Step 4: What other risks does the security solution cause? Category #1 adds an uncontrolled risk that the database may be compromised. Category #2 is possibly even riskier, by potentially exposing "secrets" used elsewhere. Category #3 can allow a Denial of Service attack, in that an attacker could change your password without your permission (though you would be informed of the change by email; assuming that your email is secure).

Step 5: What costs and trade-offs does the security solution impose? Category #1 is the cheapest and easiest to implement, at the cost of weak security. Category #2 requires more storage, more work for the user in creating and managing the account, and requires the storage of answers to common questions ("Mother's maiden name" etc) in more databases beyond your control. These answers can also control access to more important databases (such as your bank account, etc.). Category #3 has a cost of not being able to provide a simple "remind me of my password" feature, and a trade-off that attackers may be able to reset your password (although you would be notified of the new password, and the attacker would also need access to your email account to find the new password - defense in depth).

Update, Oct 2017: in Changes in Password Best Practices, Schneier notes that NIST have updated their policy documents, specifically with:

  1. Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don't help that much. It's better to allow people to use pass phrases.
  2. Stop it with password expiration. That was an old idea for an old way we used computers. Today, don't make people change their passwords unless there's indication of compromise.
  3. Let people use password managers. This is how we deal with all the passwords we need.

Password Generator

This tool should generate strong passwords, although you can tweak the complexity with the form below.

Even if you just need one password, it is good to request a few, and choose one which you will find memorable.

Password LengthHow many characters to use. Eight (8) is a suggested minimum. ( max 100 )
QuantityHow many passwords to generate. ( max 100 )
Lower CaseInclude lower-case letters ( a-z )
Upper CaseInclude upper-case letters ( A-Z )
NumbersInclude numbers ( 0-9 )
SymbolsInclude symbols ( /!#$%^* )

It is easier to define a bad password than to define a good one. A good one will not be easily guessable by using common dictionary words (in any language), even if mutated (hello -> h31l0, for example.) A good password is genuinely random (eg, "58kn9xjo" - a program designed to guess passwords would have got h31l0 within minutes, but would be unlikely to guess that within months, if at all.)

The more variation you include in the password, the better. However, this may also make the password more difficult to remember. If you have to write the password down to remember it, then it is far less secure, so do try to find a password which you can remember, even if a more complex one would be more secure.

This facility defaults to upper-case and lower-case letters, and numbers. This leads to passwords like these:

  1) udm2YVqd
  2) edkt0ubr
  3) iLV31pad
  4) bq14h7n3
  5) 01uyLB4r
  6) gdbfzdyk
  7) qin4wPEy
  8) 77SE3794

These are reasonably secure. However, I do not suggest that you use these particular examples, as they have now been posted on the net!

Memorise your Password

It is very important to remember your password, so you do not need to write it down. Be creative. For example, the 3rd item shown above ("ilv31pad") could be memorised with the phrase "In Las Vegas, Every One Pays A Dollar":

  • ilv : In Las Vegas
  • 31 : Every One
  • pad : Pays A Dollar
Or whatever works for you. Better still, take a suggested password and change it into something you can more easily remember.

As you add options (upper/lowercase, numbers, symbols), the generated passwords become more difficult to guess. They may also become more difficult to remember.

Password Advice / Generator
Share on Twitter Share on Facebook Share on LinkedIn Share on Identi.ca Share on StumbleUpon

Get the Book:

Buy my 600-page Shell Scripting Book...

Or from other Amazon in other countries: USA, Germany, France, Spain, Italy, Canada, Japan, India, Brazil
Or from other retailers

Buy this Tutorial in Paperback or for Kindle:

USA, UK, Germany, France, Spain, Italy
Or Kindle in these countries: Canada, Australia, Japan, India, Brazil, Mexico

Buy this Tutorial as a DRM-Free PDF

(Free Sample)

$9.99 US Dollars

£4.99 UK Pounds

€6.99 Euros

You can join our Shell Scripting community on Facebook: