Practical IT: Passwords 101 for businesses

The human element is often referred to as the weakest link in a secure system. Time and time again studies have demonstrated that we are not good at choosing passwords, nor can we keep them secret.

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).

_{(Enjoy this video? Check out more on the SophosLabs YouTube channel.)}

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.

_{Login screen, password sign and system hacked images courtesy of Shutterstock.}