Password Complexity and Expiration

Enforced complexity and expiring passwords are two security functions that annoy users most. They're disruptive and frustrating.

Expiring passwords, of course, work like this: After a certain amount of time since you last changed your password, the system you're logging in to will consider it expired. You can log in one time with your expired password, but before the system will let you proceed, it will make you set up a new password.

You're already familiar with complexity requirements, too. This is where, when signing up for an account on a system where you can set your own password, or when prompted to change an expired password, you might see something like this (from U.S. Bank):

That's pretty easy to comply with. But how about this monstrosity, from Chase Bank:

Daunting, maybe, but at least it tells you what to do, unlike a Microsoft Windows server, which tells you when your password isn't complex enough, but doesn't tell you the rules!

You've probably experienced having to enter a password several times before you get one that meets the requirements (especially on a Windows Server domain)—yet another distractor from getting your work done.

You might wonder why a password like elmerfudd8 isn't considered complex enough. Who in the world is going to guess that?

Well, here's the thing. Given the current state of how Internet servers and web applications are accessed, a criminal can often gain access to the file containing the passwords for some or all users on a targeted system. Criminals exploit security flaws in the programming of websites, which are, even to this day, disappointingly common. Even the major providers like Microsoft, Google, and Yahoo!, with tremendous financial resources, experience compromise of millions of user account passwords from time-to-time.

Of course, the password file on any decent system is going to be encrypted in some form, so getting the password file doesn't get the criminal in right away. But, criminals can use technological tools to perform complex mathematical analysis on password files, which will enable them to extract unencrypted passwords they can then use to log in to the system with one or more users' accounts.

Now you can see why changing your password on occasion can also make sense, and also why some systems won't let you pick a password you've used before when changing your password. If a criminal steals a password file, he will set his computer to work decoding the passwords and just let it run, day and night. And it might be that no one even knows he stole it. If your password takes a year to extract from the file, then when your decoded password pops up on his screen a year later and he goes to log in as you, it won't work for him so long as you changed your password at some point since the breach.

So, now you can see how these security practices work, and work together, to limit the damage criminals can do. But, still, is it really worth the annoyance?

Frankly, if you have a small office with a local server that's not exposed to the Internet, low employee turnover, and trusted users, then you'll probably be just fine not using complex passwords or making users change their passwords.

If you run a public web site with password-protected login accounts, you'd best enforce password complexity, and have your customers change their passwords regularly. This is because you can count on some sort of breach of your system happening eventually, especially if you hire less experienced programmers and/or don't integrate security planning into all aspects of your website development cycle. While it might seem patronizing to be describing this here, it is actually very common for small and medium businesses, and even government agencies, to deploy web applications without even the most basic security mechanisms in place, most commonly because the non-technical decision makers are unaware of the risks and mitigation strategies relevant to account security in our modern era, and a vast majority of website developers, unfortunately, know little about web application security themselves, or just choose to cut corners. In fact, if you have a website in development or in place, and basic password security hasn't been implemented, you need to do a top-to-bottom review of your security model and implementation, because no doubt there are other unaddressed vulnerabilities.

If your company is subject by law or contract to implement certain security practices (such as for businesses in the financial industry, or any business that processes and/or stores customer credit cards), you most probably will be required to implement these practices on your internal systems, and the same thinking applies as described in the previous paragraph.

If you think you may need assistance from a certified security expert to review your company's web application or internal system's security posture, contact J.D. Fox Micro.

OK, so what about your accounts on other systems? If a site doesn't enforce password complexity and expiration, this doesn't mean you can't implement this on your own, by creating a complex password, and then changing it yourself every so often. Many major sites, with millions of users, have complexity requirements, but do not enforce expiration, as this will, unfortunately, generate calls to their technical support for the less technically-inclined users, which costs them quite a bit of money.

Some of the other practices related to your account security on other companies' websites may be completely opaque to you. For example, a site might have complexity requirements, but, due to a total dereliction of responsibility in the development process, the passwords are stored on their site completely unencrypted. Whenever this file is accessed by an unauthorized individual or criminal enterprise, passwords for all the accounts are instantly exposed and accounts completely compromised, regardless of password complexity. This speaks to the inherent risks of storing sensitive company data in the cloud, which is beyond the scope of this article.