The Basics of Password Security - Security Series #4

So let's get the basics out of the way. When it comes to password security, there are some things that, I hope, we all know. Things like:

  • Password should allow and required both alphabetical and numeric characters
  • Passwords should allow and require both uppercase and lowercase letters
  • Passwords should allow and require special characters
  • Passwords should probably be at least 7 or 8 characters long. If you need to have them with fewer characters, you should have a REALLY good reason for it.
  • Password should be changed every [Insert period of time here]. Depending on the security level of your system this might be every month, quarter, or six months. Weekly is probably overkill, except for the most secure of systems and annually is probably too lax.
  • Passwords should never be, or even contain, the username.


                    <cfif form.password CONTAINS "#form.username#">
                        <cfthrow ...>
                    </cfif>
                

Now, how about some things you may not have known.

  • Don't set a minimum length above 8 character (unless you have a good reason to). If you force your users to remember really long passwords they will just write them down on sticky notes and put them on their monitors.
  • Don't force your users to change their passwords more often than what is appropriate for the security of the system for the same reason as above.
  • Some systems out there have been known to truncate passwords to shorter lengths, perform Upper() or Lower() on them or strip out special characters (@, !, ?, #, $, %, etc) before inserting them into the database to remove complexity. They then do this to subsequent login attempt, giving the illusion of strong security. This is STUPID, never do it.
  • Where possible, password should be submitted via SSL. If you are working on a professional project that costs tens or hundreds of thousands of dollars or even $1000, somebody can pony up the dedicated IP and $20 for an SSL certificate. You don't need to use it for every page, just the ones involving authentication.
  • The login form itself should be loaded using SSL. While, this is not necessary, it will help you end user feel better to see the lock at the bottom of the screen. Technically, as long as the action page is posting to a secured "https://" page, the transmission will be encrypted. When the login process is complete, it can redirect the user to an unencrypted page.
  • NEVER send login credentials on a URL string. This includes on background AJAX calls. URL strings do not get encrypted in SSL transmissions and are subject to being sniffed or intercepted. Always send via POST.
  • On sites where usernames are displayed, for example on Social Networking sites, a "Display Name" should be used instead, and that display name should be different than the username that is used for logging into the system. Remember that the user name is fully half of the information required for authentication on the system. If you are giving away that information, then... you get the idea.

This has been a quick list of helpful tips covering some of the no-brainers, and some of the quickie suggestions that did not warrant their own blog post. Some of them will come up in others posts (like submitting credentials on the URL), and others may eventually get their own posts (like Login Names vs Display Names). Thanks for reading, I am enjoying the research I am putting into these posts and I hope that people are finding them helpful

Comments
Tom K's Gravatar

How about not storing the p/w's in the database in plain text?



Enjoying this series btw !

# Posted By Tom K | 5/13/08 3:32 AM
dickbob's Gravatar

Great series Jason! Do you intend to get into any technicalities?



I'm struggling to find a good REGEX to enforce my password rules which follow your suggestions.



Any suggestions where to look?

# Posted By dickbob | 5/13/08 3:46 AM
Jason Dean's Gravatar

Thanks for the comments.



@Tom, You're absolutely right, that is always good advise. I'm plaining a post on password storage, since that is a bit more complicated topic, I thought it deserved its own post. It's one thing to say don't do it, it is quite another to say how to do it right.



@dickbob,



Yes, I will be getting into technicalities. Those postings take a lot longer to write, so I am getting these easier posts out while I am working on the longer ones.



I will look into your regex question and get back to you, I have my Regex book at work. I am still at home :)

# Posted By Jason Dean | 5/13/08 6:45 AM
Matthew Jacoby's Gravatar @dickbob - why don't you give nFront Security a try? Their product, nFront Password Filter, allows for the configuration of up to 6 different password policies for your domain. It heavily extends the Microsoft requirements and will instantly increase your network's security.

@Jason - this is a very good series! People don't realize that passwords are any networks primary line of defense to sensitive data. You can have the most sophisticated firewall in the world, but if Sally down in accounting uses the password "abc123" it's practically useless.

Don't hesitate to get in touch with us if you would like to see how it works and how easy it is to install.
# Posted By Matthew Jacoby | 6/8/08 10:56 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner