The Developers and Programmers Passwords 101

If you’ve ever designed a user registration script, a membership site or any script that creates or stores user passwords, there are some practices which every good developer should be aware of. While most small scale applications are not in danger of being targeted by anyone with malicious intent (simply due to the fact that they don’t have enough user accounts to make a blip on the radar), there is a point in the life of any good script whereby it becomes large enough that people can and will target your password list and security will become an issue. By implementing a few simple measures and understanding how password security is compromised you can limit the possibility of your password list being compromised and minimize the potential damage caused.

1. Hash & Salt

One of the most commonly committed cardinal sins of password storage is plain text- that is, storing passwords in plain text. This is frightfully common and I even remember one shocking instance of a fairly popular web application storing password and username combinations in a .txt file. Storing passwords in plain text is not only lazy, it’s a huge security risk. The most common method of storing usernames and passwords is within a MySQL table via PHP. This article explains the fundamentals of password hashing in such a setup, how it works, why it works and how easy it is to implement.

But, in a nutshell, hashing is the process of performing a one way algorithm on a user-supplied password so you can store it as a value which is useless by itself. Any potential hacker would also need to know your local hashing algorithm before they stood even a chance of brute forcing their way in to that account. Furthermore, brute force and dictionary attacks can also overcome by the simple salting method whereby you generate a unique salt for each password locally and store this with the hashed password.

The article linked provides PHP code to hash, salt and store passwords in a secure manner and provides much more information than I could hope to.

2. Passwords Will Be As Secure As You Require Them To Be

People are like lightning; they take the path of least resistance. In the realm of passwords, this means people will magnetize towards the shortest and most easy to remember possibility. In short, what this means is that if you have no restriction on the number of characters or types of characters allowed in your passwords, you will end up with passwords like ‘abc’, ’123′, ‘password’ and ‘secret’. This is not an exaggeration for dramatic effect, people will actually choose and use these types of passwords.

By enforcing some, if not all, of the restrictions below you can ensure the security of your password list will greatly increase:

Minimum character length. Require at least 8 characters. It is generally accepted and confirmed that 8 characters is the minimum required to generate a secure password. You may be scared to enforce long passwords in the fear that people will simply not sign up, but this is a misguided fear. If someone wants to sign up for your site the password field requiring an extra 2 characters on top of their existing password is an unlikely deterrent.

Other password enforcement policies should include:

• Password must contain characters and numbers.
• Password must contain uppercase and lowercase characters.
• Password must contain at least 1 symbol (outwith a-Z 0-9).
• Password must not be based on a dictionary word.

The Password Meter is an excellent resource to test the strength of a password while having a look at how it’s being analyzed. The script is free to download for use with your own applications. While there are pros and cons of making password strength a requirement, there is absolutely no reason not to show strength to the user in a system like this.

As a side note, never require passwords to be too strong. An 8 character password that someone remembers is much more secure than a 16 character password which has to be written down or saved on a desktop (and is therefor susceptible to being hijacked).

3. Retrieval/Reset Mechanisms

Password retrieval is part of password management which, in the field, commonly has vulnerabilities and programmer induced pitfalls. The most common mistake made, bar none, is to send out the users current password upon request. I.e. the user forgets password, clicks the ‘forgotten password’ link and enters their email. The script sends out a copy of their password via email and they get access to their account again. The problem here lies in the fact that hashing is one way. If you store the users password as a hashed value there is no way to send out a plain text version.

Therefor, any site or service you are registered with which sends you a copy of your existing password upon request is not maintaining your password securely. This is a useful tip to know, especially if you are using the same password on more than one site.

Instead, when someone clicks ‘forgot password’ and enters their email, the savvy programmer will have his script generate a new password, send it to the specified email, then store it in his database using hash & salt. This means the user will need to take the extra step of changing their password to something memorable again, but vastly improves the security of your password system and keeps the user safe.

4. Lockout Mechanism

An importantly overlooked part of maintaining a secure password system is having a lockout mechanism. This is a system whereby someone can report their account as hijacked or compromised which, upon review, will be temporarily locked. This prevents compromised accounts being used for malicious purposes. For example if someone gets access to Mrs Bloggs account, logs in as her and sends a message to Mr Blogg asking for his email address password or bank account details so she can “make a payment to the Jones’ next door” (better thought out rouges involving other personal info have been used successfully in the field). It’s uncommon, but it does happen and having a lockout mechanism limits damage caused and protects your users from each other.

An additional lockout mechanism which virtually negates the possibility of brute force attacks is password lockout. Include a simple script to count login attempts. If there are more than 3 failed login attempts, per minute for example, then lockout login attempts for that account for an hour. This makes it very unlikely for dictionary or brute force attacks to succeed and/or go unnoticed.

You can discuss this article and see what others are saying about it in the PHP Discussion Forum
Did you find this article useful? Why not buy Sean a coffee?