Home » Posts tagged 'Passwords'
Tag Archives: Passwords
Updates to Password Standards
Password best practice is changing. Two of the important governmental standards bodies, CESG in the UK and NIST in the US have issued, or are about to issue new guidance.
The CESG Guidance is now published, and makes a series of “tips” for managing and designing password systems.
The NIST Guidance is in draft format and is more prescriptive in it’s requirements. The SHALLs and MAYs are here, but the context and reasoning is important and worth understanding.
Both revisions are focused on making Passwords usable for people and have the following characteristics:
- Length is more important than convolution. The days of “must include numbers, letters, mixed cases, and four symbols from the DaVinci Code” have gone. However, all characters should be permitted within the passwords. Longer passwords (upto 64 characters in the case of NIST) should be possible.
- Passwords proposed by the user should be checked against a Blacklist and matches rejected. There is no recommended blacklist, however using available password dictionaries may be a good start.
- Allow the use of password management tools: allow users to paste passwords into the entry fields.
- No default passwords. No sharing of passwords between users.
- Limit the rate at which users can attempt to log in, rather than the number of attempts. This reduces the possibility of brute-forcing an account, but reduces the number of account lockouts requiring an account reset – a form of Denial of Service. Combine this with threat detection based on seeing multiple failed login attempts by a user, reporting it and acting on it.
- Store passwords properly. You never store passwords, only store suitably salted, stretched and hashed value for the key.
Storing Passwords
Simple: Don’t store passwords.
If a plain text, or badly encrypted, password database is leaked, either by an attacker, or inadvertently by an employee or user, then all users are compromised.
The purpose of a password is to confirm that the user who registered with the system some time ago is the same person wishing to use the system now.
- When a user registers they submit a password. Process the password with a non-reversible calculation and store the result.
- When a user tries to log in, process that password using the same non-reversible calculation.
- If the originally stored result and the log in attempt match, the original passwords must have matched.
There are complexities in this process, and errors in logic or mathematics can fatally weaken this approach . Therefore a developer should not develop their own system, but use a published library solution.
There are three fundamental concepts in processing these passwords. Each is designed to make life difficult for an attacker trying to reverse the calculation, or pre-calculate all the possible outputs.
- Salting: The process of adding a system specific piece of data (the Salt) to the password. This makes the result of the password calculation different on different systems, a breach on one does not compromise all.
- Stretching: Increasing the length of a password. A user may only have a 12 character password, but stretching it with a suitable Salt increases the effective complexity of the password. This calculation is designed (by repetition) to take a long time to slow down an attacker, reducing the number of password calculations he can test per second.
- Hashing: A non-reversible function that takes a stretched password and turns it into a value that can be safely stored. Cryptographic Hash functions are normally designed to be very quick to perform as they are used to validate documents, cryptographic certificates and so forth, hence the stretching phase is required to slow an attacker down.
The process of handling passwords, and other vital data, is a specialism. It is worth obtaining assistance in the design of such systems.
