Andrew talks about how he believes that password security that is based on MD5 is bad.

There are a number of ways to do this. First off is the “dictionary attack” which means we check the dictionary for words and try them all or combinations of them. Lets presume that although you’re foolish enough to think this password encryption scheme makes sense, that you have at least thought of that and put some kind of sensible password verification which prevents stupid passwords from being chosen (such as dictionary words). However, if you use a password system like “must be 20 characters long” then you can walk into the office and see that all users will have a post it prominently placed because they can’t remember a 20 character long password. Or they will store it in IE’s password memory feature.

Now this is all true. Password security is not as secure as most people might think. However MD5 is better than clear. Actually MD5 is pretty bad. You should use SHA1 instead, as MD5 has been proven to be insecure.

The best way to see for your self is to download one of the excellent free password recovery tools (Note euphemism) John the Ripper is the best for Unix and Cain & Abel is the best for windows. First time you run Cain & Abel on a windows machine can be quite frightening.

These tools will show the importance of more complex passwords. I worked at a major German investment bank in London (who shall remain nameless). The application that we inherited was from an outside developer (written in NetDynamics AAARGH!!! Never Again!!!). All the passwords were stored in the clear. A few of them had been changed from their default passwords, while most of them not. So a good %80 of the passwords for a major critical financial application in a major bank, where the same and accessible to us developers. The others were most probably the same as their email passwords and machine passwords.

I implemented a change to a SHA1 based password scheme, quarterly password renewal requirements and several complexity requirements to the password.

So what was the excercise there? Obviously to make the system more secure. Amongst other things it was to hide the clear text passwords from the developers and support people. It is about increasing the security.

If you in addition to using SHA1 also use additional requirements of password complexity. Just having a minimum of 8 characters makes it much more difficult by an order of magnitude to crack. For my own passwords I use APG which is excellent. I cant tell users to use complex passwords, but I can require some level of complexity and allow them to reset their own passwords.

The fact that many people forget is there is no such thing as a secure system. There are only varying levels of security. For example, who cares what you use for password security for your web application, if people can access your oracle server directly with ‘scott’/’tiger’ or your appserver with direct unprotected RMI/CORBA calls. I have seen systems in banks, where SWIFT processing severs were available through unprotected CORBA. Granted, banks generally work on a multi level security system, where that would get caught before an actual transfer would be made. However if you can fake that, then you can maybe fake the other documentation, or cause an internal SWIFT Denial of Service, bringing the bank to a standstill.

While we often laugh at users with their passwords on post it notes, we as developers tend do be the largest security risks. Think about that. Always analyze exactly what you aim to protect with a security policy and think about technical as well as often more importantly non technical solutions.