Why history may be bad for you

Search, and you shall find loads of people doing password analysis on the Internet. There's been several high profile attacks against websites, resulting in the compromise and public disclosure of user IDs and password hashes (or worse; passwords in clear-text). I've read many of these, and there are several issues not being addressed or even mentioned in the analysis performed even by people such as Bruce Schneier (whom i really respect, don't get me wrong!).

First of all; there's no way we or anybody can or will verify whether the compromised accounts were actually being used by real people for any practical purpose, or if the accounts were created for fun or testing purposes.

Second we don't know how old the accounts were, neither do we know when, or if the passwords were ever changed. Initial passwords set by helpdesk personnel at least tends to be the same across many users; see my old article  "Experiences with password policies"

At least I'll confess that I've created many accounts on various services just for testing (password "test" or similar), or for purposes that didn't represent any kind of value to me whatsoever. If anybody else have done the same, i can easily understand that the accounts were easy to compromise, and the general statistics shows us that the most common passwords are nowhere near what we would usually consider "strong" passwords.

Many people i've talked to makes lot of assumptions on how people create and maintain their very own password patterns. Many of them are wrong, something i'll get back to in later blog postings here. Here's something that i find interesting: most, if not all recommendations on setting up password policies includes advise on using a password history function, in order to prevent users from re-using their XX last passwords. Not a bad idea, you'll say. I tend to agree on that one, but there's a few quirks here.

Several years ago i asked a former colleague for a little scripting help. I told him that i had lots of historical data on user accounts and passwords/hashes, along with date/time information for last logon and password last set. What i asked him to do was to script something that would check if a user had the same password consecutively even when the password last set date/time had been updated. These data had been collected from Microsoft Windows domains over really long periods of time. He asked me about the purpose of this, and i replied to him "Well, i'm looking for people that changes their password 13 times every time their password expire, and then go back to using the same password as they always do. They do this in order to circumvent the password history = 13 parameter setting, along with the parameter allowing a user to change their password immediately after the previous change". He blushed, and bursted out "yeah, well, at least I'll admit to doing that. I just can't remember all my passwords otherwise". The weirdest thing; i honestly didn't know he did that before i asked him for help, randomly selected between thousands of employees.

First advisory: this is not a guide on how to make your life easier at work when it comes to passwords (sorry!), this is a word of advice for security managers before writing and implementing their new password policy. It can easily be circumvented if you don't expand the time frame between each consecutive user initiated password change. Auditors may become blinded by this, passwords remain the same, while auditors (and others) only sees periodic password changes by all users.

What I've done for many years now (close to 9 years actually) is to dump not only the current password hashes, but also the stored historical hashes for user accounts from Windows domains. Although i don't get date/time data for every historical hash value, i can still easily see password patterns and changes in these. For my research this has had an enormous value in seeing "the bigger picture" of password risk to any organization over time.

Here's the simple quiz: tell me what the next password will be in this chain:
password1
password2
?????????

password3, right? Not necessarily. 1+1=2, 2+2=4 etc, giving us password4 as the next in the chain. Not your ordinary password pattern, i must admit, but here's the deal:

If somebody manages to compromise the current password hashes of most (or all) of an organizations accounts, they have a rather high probability of being to break in even after every account has been forced to change their password at the exact same time. However, if they manage to get hold of not only your current password hash, but the last 24 password hashes as well? I'll say changes are way much higher. In fact, I'll suggest that you will never EVER be able to get the intruders out again. Of course, unless you set up a new domain, new naming schemes, brand new password policy and replaces all employees with new ones. Rather impossible, i guess.

Many actions can be taken to reduce the risk here,and I would really like to hear your opinions on this; twitter.com/thorsheim, or make a comment here on my blog. Good night everybody, and sweet dreams.