Separating People from Passwords

Published: 23 October 2015

Andy Harris, Password Policies

By Andy Harris


Separating People from Passwords; More accountability creates a greater Deterrent

... and password policies may lead to much lower security ...

We've stated before, the message about using 'strong' passwords is getting through. According to the Verizon DBIR reports the instances of brute forcing are reducing year on year (3% in 2014 [i.e. reported in 2015]). As always if we fix one weakness the attackers shift their focus to the next.

Interestingly Clearswift brought this out in their recent article Seven Deadly Sins where points '2' and '5' were password related.

Right now we're seeing how rigorous passwords policies are creating the exact opposite of their intended outcome. This is due to two factors:

First, considering policy, humans need to remember passwords, so they are heavily biased towards patterns. A typical policy would state that a password needs to be more that 12 characters, contain upper and lowercase, some digits and a punctuation mark. Furthermore our policy states that the users need to change their passwords every 30 days.

Humans tend to follow instructions serially. The firstly they think of a long word, for example 'Manchester' that has upper and lower case and takes up 10 characters. 'ManchesterFC' would be a useful alternative taking up 12. For the digits, most users would start with the year, so 'ManchesterFC2015' works. For the puntuation character '.' followed by '!' are the most common choices, so we are at 'ManchesterFC2015.' After 30 days our user is faced with forced password change. Typically the user will choose 'ManchesterFC2015.10' where the last two digits are the current month.

Now we have a solid 18 character password, beyond the reach of the 14 character LM hash brute force, so all is good?, well no it isn't. Football clubs are very popular choices for passwords, 'Manchester','Liverpool','Chelsea','Arsenal','Tottenham' quickly covers the top five. Year, Month and '.' are commonly used. Therefore the combinations of all these are very easy to compute. However there are still too many to directly brute force.

This is where the second element comes in. If we were to take all the common combinations of the above we could set a users password and record the resulting hash. The hash is the result of passing the password through a complex one way algorithm. Now imagine that we've done this 131 billion times. If a hacker were to obtain a user's password hash they'd have a great chance of recovering the original password.

The whole situation worsens when the policy requires different passwords for different systems. This leads users to write them all down in something useful, like a spreadsheet stored on their desktop. Its no wonder that 86% of passwords are simply stolen.

It worth a moment to reflect on your password policy, how many of your users would have chosen one of those 131 billion passwords? Given this situation, it becomes difficult to prove the identity of who did what. This is of course amplified where several users are sharing a password to a particular device account.

So what's the solution

It's easy to say 'one cannot trust users with passwords', however the vast majority of your users will use online banking. You can be sure that where their own money is concerned they chose strong passwords. The banking systems do not ask for password changes every 30 days. Historically, banking systems have proven secure. Online banking authentications systems use a second factor of authentication. The key point here is that banking systems seek to prove identity. Identity is the real key to security. In the corporate world we really need to know who did what where and when.

Woman using Identity rather than Password

Osirium separates People from Device passwords (known as privileged account management). They can still keep their personal passwords, and identity can be enhanced by two factor. Profiles then map identities into specific roles on specific devices (by which we mean Devices, Applications, Systems). This means that your users can reach the systems that they need to, but they can get no further. Now users cannot use a connection to one system to jump to others.

This leads to real accountability, whereas before you could have a situation where a team of people would all use a shared passwords to systems, now you have identities having sessions on systems. This leads to knowing Who did What Where and When - and this means there's nowhere to hide e-wrongdoings.

Release Date: 
Friday, 23 October 2015
Article Type: 
Blog Post
Author: 
Andy Harris