Monday, August 1, 2016

Do You Even Password?

As an industry it is time to admit to ourselves that we are terrible at providing a user experience that is simultaneously easy to use and secure.

This kind of nonsense needs to stop:
Your new password must have:
        maximum of x repeated characters
        minimum of y alphabetic character
        minimum of z upper case alphabetic character
        minimum of n non-alphabetic character
        minimum of p digit
        minimum of q special character
        minimum of r characters in length

First of all - this might at first sound like a simple question: Why is the program that I am using to set my password able to read my password?

Huh?  Because you typed the password into it?  No, that requires the program to store the password, not to read it.  The reading part is only necessary to perform analysis on the password in order to determine if it adheres to all of the rules and if not to be able to report back which are violated.

Without that analytical step the next action typically taken is to feed the stored password to a one-way cryptographic hashing algorithm which produces the output that it typically stored in a user directory.  How this works is that when someone tries to use the credential for authentication - they enter their password, which is hashed & the result is compared with the stored result.  In this way the original password is kept secret & never accessed by anything by the hashing routine. 

The analytical step however does read the password which introduces a new potential vulnerability if that verification code or the memory that it uses is co-opted.

So why are we doing this?

Users have tendencies to use overly simplistic & easy to remember (or intentionally easy to guess) passwords rather than invest the effort in to memorizing more complicated ones.  This weakens the effectiveness of the hash code scheme as a protective measure.  Thus these rules are put in place to force users to choose passwords that are more difficult to guess.

How do you break hash codes or make them less effective?

If your password is set to "secret" then the hashing algorithm will produce a particular result stored for your account.  If I also use "secret" as my credential then an identical hash code will be stored in my account.  If I know one password then I know them both. 

People have run common hashing routines using dictionaries as input to produce what are called "rainbow tables" that list the hash codes for every word in most common languages.  That makes it easy to look up the most commonly used passwords.

So what else could we could instead?

If the point of the rules is to produce passwords that don't exist in any rainbow tables - why not employ actual rainbow tables into the solution?

How would that look?  Rather than a long list of rules to adhere to instead provide a single admonishment: "Choose a difficult to guess password."  Then whatever they enter is immediately hashed.  Thereafter however the hashed value is then analyzed to see if it can be cracked with a rainbow table.  If so - then the user is informed of this & required to change their password.

The advantage of this approach is that as the tables grow over time & more hashcodes are cracked over time existing users will be warned and protected.  It doesn't have to stop merely at the login/setup process.

The downside is having to maintain, generate & augment local rainbow tables.

This is one idea.  Do you have a better one?  I'd love to hear about it.

No comments:

Post a Comment