Hyperguarding your Web Applications

Posts Tagged ‘developers’

Strong Passwords for Developers

Posted by hyperguard on May 13, 2010

Came across a new blog this week—EthicalHack.co.uk that we wanted to share with our readers.   It is written by Vishal Garg, and dedicated to application (hacking) security.  A great read, and definitely worth following.

That being said, we wanted to highlight Vishal’s latest post on web application designers and developers choosing strong passwords for web applications.  This topic is usually discussed from the end user’s point of view—not from the developers—and all too many times weak passwords are being implemented.  This in turn requires end users to choose strong passwords, which they tend to be faulty of.  Vishal provides four helpful tips to consider when implementing strong password policies within web applications:

1. Password Complexity

A strong password should contain characters from at least three of the following four categories (although implementing all four would be even better):

  • Upper case letters (A through Z)
  • Lower case letters (a through z)
  • Numbers (0 through 9)
  • Non-alphanumeric characters (e.g. !”£$%^&*@#?+ etc.)

2. Password Uniqueness

A strong password should enforce uniqueness of characters—avoid character repetition, number and character sequences, full or part of the password that is the same as the user name or common dictionary words.

3. Password Length

Password length is directly proportion to the amount of time required to crack the password.  Although the optimum length to hinder most password cracking attempts is considered to be more than 14 characters, but implementing a policy that requires minimum eight characters along with above requirements would still be sufficient to stop most of the attacks.

4. Password Aging and Expiry

Password aging and expiry may be considered for high profile web sites.  But this requirement needs to be considered very carefully.  If implemented poorly, this may prove to be counterproductive; e.g. asking users to change passwords very frequently may prompt them to choose weak passwords (e.g. Password1 – a password meeting first three complexity requirements, but still considered a weak password), or to write their password somewhere.  If considered carefully, strong password implementation policies would prevent users from choosing weak passwords and help prevent compromise of user accounts through brute force attacks.


Posted in Post | Tagged: , , | Leave a Comment »