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.
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".
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.
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.
- 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.
A final note
No password will be forever infallible, even when encrypted. In 1998 the DES 56 bit encryption was broken, that is 2^56 possible combinations, or, 72,057,594,037,927,936 ( over 72 quadrillion ) possible keys. Time taken, 56 hours. Of course, this was a very large, expensive, and purpose built system. The moral of the story is not to make it easy for crackers to walk into your system. If the time, effort, or money is too great, most will simply move on. As a developer, it is your responsibility to secure the system.