The Problem With Passwords (again, still)

Passw0rds!  The bane of most user and sys-admins lives.  I started talking about passwords earlier in the year, with the theme of 'the password's dead...long live the password'.  Obviously, the password isn't dead and is very much alive.  The story generally unfolds something like this:

  1. The infosec team, create a corporate password policy that requires a password to contain something like the following: to have a minimum length, include a number, an upper case character and also a special character, perhaps have a minimum age and be historically unique
  2. A sys-admin or developer, creates a function within an app/system/website to check the newly created passwords for complexity, in line with corporate password policy
  3. A user is created within a system / registers on a site
  4. A user is prompted to enter a new password for themselves, which must match the above policy
  5. If the policy is too complex, the user's initial password selection will generally be bounced for being too insecure
  6. The user iterates their password, adding numbers or additional characters until the password is accepted
  7. User convenience and satisfaction is probably reduced due to having to remember a large password
  8. The sys-admin believes the system is now relatively secure from hackers guessing passwords as everyone has a complex password

The Sys-admin is the Problem?

Obviously this is a fairly simplified view, but what will also probably happen is that the end user will either write the password down (massive security no-no and probably well enough publicised to not be a serious large scale issue?) or have a small pool of re-usable passwords that meet the complex criteria.  By this, I simply mean every 90 days when the password needs changing, will result in a digit being added to an existing password for example. 

Now, the other side of the password management piece, is the assumption that the passwords are themselves stored securely on disk.  Are the passwords hashed instead of encrypted?  Is a well known algorithm and management process being used?  What physical and logical access is in place to access the hashes?  Is the database or directory they're stored in securely backed up and so on.

Whilst there's been a few cases recently where the underlying password hashes have been stolen, the underlying security argument is that even if hashes get into the wild, a complex password will still take some time cracking, either using brute force or a dictionary attack.

So the User is the Problem?....A Password Vault to the Rescue?

So the weak entry point is the user right?  They can't be relied upon to create and keep secret, good quality complex passwords.  Possibly true for most non-IT end users.  In comes many of the browser and desktop based password vaults.  They can create the password for you.  Simples!  The browser based vaults simply check the form to see if it contains a password field, prompt the user to use the inbuilt random generator, and voilĂ , a long, pseudo random, complex passphrase is created.  The vault will store the password for the user, so the user doesn't even need to know what it is.  Excellent.  No issues around passwords being written down, forgotten or being incremented and reused.  Every time a user hits a particular URL, the vault will pass through the password and the user is authenticated.  Easy.

Hmm.  So now, all the passwords in one place.  So have now we just moved to the admins worst case 101 problem, a single point of failure?  Now comes into question how the vault is managed.  I don't know of any major breaches of the big on line browser based vaults - but please comment if you know otherwise.  If the vault is hacked, all your passwords, no matter how complex are out in the open.  So the assumption again, is that 1) the vault wont be hacked and 2) even if it is and your passwords are exposed, because they'll be so long and complex, cracking them will be too computationally expensive.

Keys to the Castle

So assuming how the vault is managed wont be a problem, how does the user access the vault to use the stored passwords?  Ah!  A username and password (see flow above!).  So, the user needs to create a master password - the key to the castle.  So whilst on one hand, we replace one problem we create another.  The issue with having a password-vault-password hacked is going to be more costly than any of the single systems using the vault.  That's obvious.  So what next?  We can introduce dual-factor authentication to add an extra level of security.  This could require tokens, one-time-passwords via mobiles or grid-based-authentication, using unique randomized pads.  The use of dual-factors goes to show that passwords on their own don't provide the level of protection required for some unique systems.

When it comes to creating passwords though, the complexity rules will certainly provide a basic level of protection.  If you have to create a password manually, try mixing the languages and keyboard layouts you use.  For example, on many desktop operating systems, you can simply add in language maps for other worldly languages, setting up a hot key to switch between English and the other 2 or 3 selected languages.  When entering a password, try mixing a few languages together.  Whilst this isn't always going to help, it can certainly help slow down dictionary attacks....

It can look pretty cool too right?