Perfect Password Paragraphs

Over the last few months at least in the streams of information I typically consume, direct issues: Security Now topic of Password Haystacks, xkcs’s comic, Coding Horror, and indirect: Scott Hanselman one and two. Have all commented on the issue around passwords and strength and the need for better passwords.

In this post I am putting forward a novel approach: which as an homage to GRC’s Perfect Paper Passwords and accordingly have titled my approach:

When high entropy 16, 32, 64 or even 128 character passwords are just not secure enough!

Let’s jump right in with a sample, here I’ve mocked up the very familiar facebook interface with a nice large textbox to put in your Perfect Password Paragraphs™.

Perfect Password Paragraphs facebook log in modified

Disclaimer: if you’ve gotten this far and haven’t begun to appreciate the humour I’m so sorry, please don’t send me hate mail.


  • A big text area where with probable difficulty you have to type 100+ words to authenticate.
  • Typographical errors are ok as long as they are consistent for you.
  • A flow of sentences following a theme/style just needs to sound like the individual attempting to gain access.
  • “Sound Like” is a trademark (patent indefinitely pending) of Josevski Research Corp, is the flux capacitor grade specialty of this authentication system.

Comparison metrics:

  • Writing style
  • Choice of punctuation, frequency of commas, periods, ect.
  • Grammar choice.
  • spelling (American vs British English).
  • Consistency of spelling errors.
  • Choice of tense (present, past, and future)

Future Features based on demand:

  • International support.
  • 1337 sp34k.
  • Baby talk.
  • Obscure localised slang.
  • Pig Latin.
  • iOS, Windows Phone 7 and Android Support.

Alpha product coming online in 6-8 weeks 😉

Taking a concept way too far, password similarity prevention.

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.

  1. Categories of all but current password are stored.
  2. User is on ‘active’ password, category unknown.
  3. User has selected (or is required) to update password.
  4. User enters existing password.
  5. Category is determined.
  6. User enters new password.
  7. Category also is determined.
  8. These 2 temporary categories are compared with the last N stored categories.
  9. If there are no category collisions – password is updated.
  10. Old password category can now be stored as that password is no longer active.
  11. 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

Realistic Summary

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.