I’m hooked on a very entertaining podcast called Security Now, I’ve been listening for a few months now if you’re looking to expand your podcast library, I encourage you to check it out. With security in mind there’s a small undertaking at work to strengthen the login and password aspects of the web application. This got me thinking about how far you could actually take securing a login process, I’m sure with a brain storming session of security aware developers a lot of wild ideas could be hatched, so I thought I would explore one that came to me.
In an ideal world we would all have perfect memory and an extremely strong randomly generated password would be easily remembered, but that’s not the case.
Users are already encouraged to change their passwords regularly, and often (at least in the corporate world) systems track N-number of your previous passwords and prevent them from being selected again. But this password history checking is done in a very secure fashion of having only the password hashes stored.
So how about we take that concept much further…
When a user changes their password and submits it for processing, the system determines if this password has “been seen before”.
If so the user is presented with such a message:
Invalid password choice.
Your newly entered password is similar in theme one of your last 10 passwords.
Please select a new and different concept for your new password.
The simplest examples as to what would triggers this are:
- One of your previous passwords was the name of a female. Please don’t select another female name.
- One of your previous passwords was the name of a fruit. Please don’t select another fruit.
- One of your previous passwords was a type of vehicle. Please don’t select another vehicle.
Leaking Information Concern
At this point, we’re crossing a line and storing data that leaks information about the users previous passwords. In this approach only previously used categories would be stored and associated with the user, and of course the hashed values of the previous passwords. So it does raise the question if this additional data about passwords, approach breaches the current level of acceptable “salt and hash” rules for passwords.
Over-coming the leak
I believe the ‘leak danger’ is mitigated by never storing the current passwords ‘category’. This can be achieved by the approach of requiring a user to enter their current password when changing to a new password. So only in the process of a new password being ‘approved’ is the system aware of the ‘previous’ passwords category, and then the fact that it’s a ‘previous’ password can’t it’s ‘category’ be safely stored.
This workflow would work in such a way.
- Categories of all but current password are stored.
- User is on ‘active’ password, category unknown.
- User has selected (or is required) to update password.
- User enters existing password.
- Category is determined.
- User enters new password.
- Category also is determined.
- These 2 temporary categories are compared with the last N stored categories.
- If there are no category collisions – password is updated.
- Old password category can now be stored as that password is no longer active.
- Newest password category is discared (i.e. not persisted).
Another concerning factor that would be attempting to categories a password that failed to match a category, and if this would be considered a breach of the users trust in supplying new passwords. As such a task may not easily be handled by an algorithm and would require humans selecting categories for unmatched plain text passwords. Again this need not be in an exact loop directly traceable to a specific password, but just as seed data for new future categories.
Implementation ideas for deciphering and categorising the previous password:
- Common letter to number replacements would be simple pattern match and replace.
- i.e.: ’1′ for ‘i’, ’3′ for ‘e’, ’4′ for ‘h’, etc
- Making use of a dictionary for simple word matching.
- Another dictionary of names of people.
- Categorisation of the dictionary words, into a large set of common categories.
Going even further to reference human resources style data stored on the individual, but could go in the direction of breaching information leakage concerns.
- Please ensure not to use names of family members as we have access to that information.
- We detected your spouse and children are “Jane, Sam, and Amy” your password contains a variation of their names, and is not acceptable.
With such wide reaching password checks to prevent the user from selecting anything even remotely guessable, would force the user to select from
– Something like the GRC equivalent strong password (high entropy)
– Or chaining random words
If this was implemented with they way users currently choose passwords, it would just be a major source of frustration, along with a probable fear of information leakage of older passwords. So this was just an exercise in walking through a idea on password security. If you have either negative or positive comments on this idea I welcome you to share them.