Creating Secure Passwords

By Kevin Waterson

The greatest security risk to password protection, is the user who created the password. Most developers have at sometime needed to create a system where passwords were required. Password protection comes in various implementations, from accessing a single file, or gaining entry to a system, or administration panel. The protection provided by passwords however, is only as secure as the password itself. A password that is predictable, or easy to guess can leave your security model less than adequate. However, it is not just end users who are at fault, as there is plenty of finger pointing at developers who permit insecure passwords to be used.

The Problem

Problems arise with passwords as users need to be able to remember them, so, in an effort to make the password readily re-callable many users will choose a word that is closely related to them. This could be their dogs name, the name of a favorite cartoon character or any other word the user may find easy to recall. The danger here is two fold.

Firstly, anybody who knows a user may also know the name of their dog, or their favorite cartoon hero, and gain easy access to the users information. The second, and greater risk, is the use of real words as passwords.

Using real words as passwords paves the way for dictionary attacks. Dictionary attacks are a type attack on a system where many user names are tested against a dictionary of passwords. For example, the user named john may be selected by a malicious user and then hundreds of thousands of words are tried as the password until the correct one is found. Upon success, all your data is now exposed.

Simple passwords can be cracked in seconds by a malicious user. To fend them off, there are several ways in which a user can make it harder for an attacker to gain access to their account. It is important to remember that the goal is to make the password so hard to crack, that it is not worth the time an effort for the malicious user to bother, and so they move on.

Much emphasis is placed on updating passwords every 30 days, and in some systems, this is mandatory as the password will expire.. This policy, however, is a double edged sword. While it ensures an extra layer of difficulty in gaining access, it also includes difficulty for the user in creating and recalling passwords. This can lead to even more simplistic passwords such as a dogs name or even the name of the month the password expires such as "june".

Password Length

Size is important! Many systems mandate a minimum of 8 characters for passwords. this is a good starting point as most users when left to their own devices will choose a lowercase password using the standard alphabet. If the allowed characters are only the lowercase alphabet, an eight-character password will have 26^8 possible values ( about 38 bits ). If the possibility of extra characters is permitted, that is, uppercase characters, punctuation, numbers, and special characters, the available pool of characters expands to about 88 characters, From this, an eight character password will now have 88^8 possibilities ( about 52 bits ), which would require an attacker to multiply their dictionary attempts by sixteen thousand.

If all characters available on a standard 101 keyboard were used, the total characters would be ninety four, which would raise the possibilities to 94^8, or, 6,095,689,385,410,816 ( over 6 quadrillion ).

It is within this space that developers need to take charge of the system they are creating or administering. By limiting passwords to just 8 characters and lower case, the door is left with the key in it. Developers need to make provision for secure passwords in their applications. Of course, access to web sites and systems via mobile/cell phones make the use of special characters difficult, but this is exactly goal, to increase the difficulty, and thus time required to access the system. Developers should be realistically looking at a minimum of twelve to sixteen characters for passwords, and enforcing rules that mandate the use of mixed characters.

As a user, there are simple measures that can be taken to secure a password. Many may seem like common sense, others may seem paranoid, but if information is to protected and accessible, then strong passwords are required.

Avoiding weak Passwords

At the end user level, care needs to be taken when creating passwords. Always avoid sequences or repeated characters such as "john1234" or "4444444444".

Substitutions

Never use look-alike substitutions of numbers as a basis of a password. It may look clever on SMS message, but modern dictionary attacks have these substitutions covered. Remember, a dictionary attack on a system can run up to ten million passwords in a single second. A password such as "Bulld0g5" may look easy to remember by is easily guessable with modern dictionaries. However, when combined with other measures secure password measures, such as length, variation of upper and lower case, this can be useful.

Guessable Passwords

Never use a login name, or any part of your name, birthday, number plate, or similar information about people close to you.

Dictionary Words

Dictionary words have been covered already, however, it should be mentioned that dictionaries are based on may languages, and spellings and mis-spellings, substitutions, reversals etc. Never use a word based on a dictionary word.

Password Duplication

Never use the same password on multiple systems. Should an account be compromised, this is bad, to have ALL accounts compromised would be tragic.

Never write passwords down / Always write passwords down

WTF?! OK.. Here there are two schools of thought. One says that by writing passwords down on bits of paper is sure fire method to having your password discovered. The second school of thought says trying to keep 39 passwords in your head is impossible, and leads to people using the same password on all systems. Perhaps a more sane approach is to secure the place where passwords are written or stored, and not leave them on post-it-notes stuck to the monitor.

Password Phrases

By using a password phrase, instead of a password on its own, longer and more easily remembered passwords are possible. A phrase such as "MyBlackDogAteMyWhiteSlippers" will by much more secure than the dogs name such as "Deefa".

If the system does not allow long passwords of phrases, taking the first letters of each word in the phrase can by useful such as "MbDaMWs!" offers a mixture of upper and lower case, and the addition of a special character. This is not infallible, by still better than "Deefa123".

Developing For Secure Passwords

All of the good intentions of a user to secure an account are meaningless if a system is not designed to allow, or enforce a security model. Here are some things that can be done to ensure a user account has strong password protection.

Length: Minimum password length should be twelve to sixteen characters. The increase in protection with each added character is to the power of two. Ultimately, password length will gain better protection than complexity.
Special Characters: Passwords should be a mix upper and lower case with at least 3 numbers and/or special characters. This should be enforced at the administration level, and not left to the whim of users.
Dictionary Words: When a user submits a password, it should be checked against a dictionary. The dictionaries crackers use are freely available should be used to check against. If a password is found in the dictionary, a policy of warning the user, or perhaps forbidding the password should be in place.
Password Storage: Never store passwords in plain text. As a minimum, passwords should be encrypted with SHA1 and salted.
Rotate Passwords Regularly: Passwords should be rotated, or changed on a regular basis. Thirty days is the usual time allotted as it should take longer than thirty days to crack a password thus providing insufficient time for a cracker to gain access. Some argue that is a password is secure, why change it? The answer is simple, should the user have written the password down and somebody 'found' it, rotating the password will limit access.
Account Closure: Be sure there is a rapid fire method to close down accounts should user depart or the account be known to be compromised.
Password Resetting: Users should be aware of when a password is due to expire. A system generated mail should warn the user to prevent them using the expiry date as their password.
Password Re-use: Do not allow passwords to be re-used for an account. Comparing a new password hash against old password hashes will eliminate this possibility, however, if a random SALT is used, this will prove impossible.