It’s tempting to give up on passwords entirely. Assuming your users’ passwords are always compromised is certainly a sensible starting point. Ensuring that high-value, high-risk assets are protected by more than just a password is no longer just strongly recommended, it’s essential.

Despite this, regular initiatives to shore up password strength are unlikely to be wasted time. Maybe your finance app is well protected but you allow users remote access to a password-protected web-based email portal. If so, don’t underestimate the value of an email account to an attacker. Even a low privileged employee’s account is a great place to learn more about a company and launch a plausible social engineering attack.

Similarly, authenticated staff-only apps are rarely tested as well as the public ones. Once an attacker has a foot in the door, privilege escalation is often trivial. That low-value, password-protected web app could be used as the entry point for a larger, more serious compromise.

The starting point

It isn’t a password policy, nor is it user education. As one of the most visible, user-impacting aspects of information security, passwords are something everyone has an opinion on. The starting point is to don your hard hat, get your facts right and set aside a good chunk of time to handle the inevitable debate. Don’t expect people to thank you either – you’re not going to be very popular for a while.

Hopefully you’ve already got a base password policy for your organisation so it’s probably wise to review it. If you don’t have a policy, prepare one.

This is where the contention starts. Understand that commonly-argued points regarding length, complexity, forced changes, etc. do generally have some merit. The tricky part is balancing them.

The balancing act

Sure, enforcing very long passwords will cause people to write them down but allowing 3 letter passwords will clearly make them easily guessable.

Likewise, users hate forced changes but never expiring corporate passwords is a risky approach unless you are very confident they will never be compromised. Be it a phishing attack, a simple mistake (can you honestly say you’ve never typed your password into the wrong window) or an attacker sniffing the network for weak hashes, there are lots of ways for passwords to end up in the wrong hands. For more in this area, Bruce Schneier’s advice is a good read.

Complexity controls (requiring numbers, punctuation, mIxEd cAsE, etc) are another perennial discussion point. They have problems, as famously highlighted on xkcd. Humans are also great at gaming them. I guarantee that given any realistic complexity policy you’ll easily be able to create a weak password which passes. But without complexity controls how do you protect against a trivial dictionary attack? You’ll need to weigh up the risk versus reward for your organisation.

Testing passwords

Although controversial, a solid way of cutting through the debate and assessing which passwords are weak in the real-world is to test them with a controlled attack on the hashes. But make sure you have appropriate authorisation to do this! Performing the test safely and securely can be tricky so it might be a good idea to include it as part of a pentest from a trusted firm. As an added precaution, as soon as the list is generated take steps to keep the cracked password list separate from the associated usernames.

The great thing about this approach is that it will likely use the same common tools and techniques that an actual attacker would employ. Theoretically debating strategies for improving password entropy is one thing but the reality is an attack will likely involve one of a few known tools. If one of those tools, out-the-box, employs a strategy that trivially cracks a password hash then it’s unequivocally and demonstrably weak.

It’s worth noting that given enough time you’ll crack every password, limiting the time spent on an attack ensures you’ll get most value from the result by focusing on worst cases. Telling someone with a password of “A<F0l4V9Ylk%JPaFsazI’fB3OeGpcniLa;Ts0bN#0RKwFfbyquq8yZE0” that they need to change it isn’t going to help anyone!

After conducting this exercise, you’ll likely spot some clear recurring problems with passwords which will really help you with a policy tailored towards your organisation. Every organisation is different so it’s important to do this yourself.

That said, an almost guaranteed finding is that password length is the most important factor. If you enforce one thing, it should be this.

Just as important as the actual policy are the associated guidelines. Include links to sensible strategies like Graham’s, below, and provide some examples of bad passwords based on known user behaviour (obviously anonymously and only after they’ve been changed).

Responsibility is important to highlight in the guidelines. Everyone should understand it’s up to them to make sure they choose a good password. Just because a system allows a password doesn’t mean it’s secure!

This may seem obvious but, particularly on systems with strong complexity controls, a common response to a cracked password is: “How can my password be weak, the computer let me choose it?”!

Armed with clear guidelines and an intelligently deployed policy, you’ll probably want to communicate it to everyone using easily cracked passwords. It’s not the time for naming and shaming so use the BCC field and make sure the email carefully explains the test, which account was tested and the next steps to fix it. Obviously including the cracked password, tempting as it may be, is not a good idea. All this will generate some controversy – great!

Getting people thinking and talking about this stuff is half the battle.

About the author

6 comments on “Practical IT: Passwords 101 for businesses”

The trouble with the xkcd cartoon is that there is an assumption of a guessing rate of 1000/sec. That’s a huge assumption. The guessing rate could be much faster reducing the recover time from hundreds of years to a few hours.

A lot of passwords are just stored using SHA or MD5 hashes. These are designed to be fast and aren’t suitable for storing passwords by themselves but widely used in this way. If you capture the database storing passwords hashed in one of these ways you can run attacks at incredible speeds. Salting makes no difference. A decent modern PC with top of the line, off-the-shelf GPU will get you up to billions of hashes a second. The bottom line is that if you are storing anything worth protecting 44bits of entropy is only one step up from pathetic unless the password is being stored using something like PBKDF2 with a decent amount of iterations.

Passwords
The big problem with passwords is there are to many passwords and the SAVE PASSWORD causes problems. A system will run grate until the password has to be used after mounts and nobody is sure what it is, unless it is written down some where and there is the problem where it is written down has to have a password and so on.
Some WANS require password to be changed every so often and this runs into problems unto it self. I see where the experts say use a sentence and take the 1st two letters some capital some numbers and periods this is great for one password but some change and it gets very confusing for every body with a number of passwords.
And the password goes back to SPOT

I’d rather suggest checking the password against a list of known bad passwords instead of creating fixed rules on length/characters used. This check can easily be done at the time the user wants to set the password for his account. The list of bad passwords can be generated based on the tools/wordlists typically used by attackers. If we check the password against a list of 1 million bad passwords, an attacker will typically need 1 million tries to crack one single password. This should be secure enough for most applications given that the password hashes are well protected and there is some kind of rate limiting for failed login tries. If you need even more security, you should probably switch to two-factor authentication anyway.

It is just annoying the fact that we are still living in a password world. Almost everything is still only password protected. But ultimately the fact is passwords (strong or not) do not replace the need for other effective security control. As was stated passwords are useless, outdated, and a security risk. That same organization understood that only real solution is the need to add additional layers of authentication for access and transaction verification without unreasonable complexity and this will of help to their customers if they implement some form of a two-step or two-factor authentication were you can telesign into your account and have the security knowing you are protected if your password were to be stolen. This should be a prerequisite to any system that wants to promote itself as being secure. With this if they were to try to use the “stolen” password and don’t have your phone nor are on the computer, smartphone or tablet you have designated trusted, they would not be able to enter the account.