The Password Reset Conundrum

By Kenneth Ray, Architect, Access and Data Protection & Sandra Carielli, Principal Product Manager, Access and Data Protection
Many of us have received an e-mail, either from a web portal we frequent, or from the IT department at our place of employment, telling us that we need to reset our password due to a security breach.   In the event of a smash and grab attack that compromises user passwords, having users reset their passwords is one of the first steps in remediation.  There’s no question that the old password is now gone, and should most definitely be changed.  The next question that comes to mind is how effective is that password change?  And how might that effectiveness change when that password change is required from a large number of users on a single system?

We all know that users have developed strategies for dealing with required password updates.  Some are more obvious than others.  The simplest example is with a simple increment / rotation of a given root: e.g.  P@ssw0rd1, P@ssw0rd2, P@ssw0rd3…  This works great, as it meets the complexity requirements at once, is easy to remember, and can be reset back to P@ssw0rd1 as soon as the history requirement is met, e.g. after P@ssw0rd9 for a history limit of 10.  Some users even use the same root for multiple websites as we’ve seen with the analysis of the Linked In published passwords. Such behaviors are clearly disadvantageous for the individual users, since knowledge of the cleartext password on one site is, unfortunately, likely to allow an attacker to predict that user’s password on another site, either because the password was reused in whole or the derived root was reused in whole. Interestingly enough it is _also_ disadvantageous for the website owner as well.  Here’s why.

Attackers steal more than the current passwords of the given users; they also lift the password histories, which in most systems are protected by hashing scheme no more advanced than the ones protecting the current passwords, and on some systems are kept in the clear.  In these last systems, the administrators believe that the tradeoff between potentially revealing the previous passwords to an attacker is worth the risk of being able to more effectively address users creating a rolling scheme as described above.  We should note that no matter how clever the algorithm for detecting a rolling scheme is, there will always be users who are more clever.  In most cases, a majority of users will be able to discover a way around the detection for the simple reason that it allows them to remember their passwords without the dreaded action of writing them down!

Once the attacker has this large store of current and historical password hashes, and after some quality time with hashcat (or the hash cracker of their choice), said hacker has little work before him before the pattern of a single user’s rotation can be discovered.  Given the example above, how long will it take the attacker to decide that the next guess of P@ssw0rd11 might be the next logical choice for a given user?  For any given user, there is clearly a non-zero likelihood that the search space can be reduced to find the user’s next password based on the history.  This doesn’t even account for other patterns that can be learned, such as how the user prefers to create passwords (e.g. simple words with character substitutions, pairs of words, the first letters of common sentences, favorite topics, etc.)  In other words, what does a password history say about how the given user chooses a password?  What does your password history say about how you will pick your next password?

Now assume you’re a great big newspaper with lots of editors and reporters – in the event of breach, what are the odds that all of your editors and all of your reporters will choose a new password that is significantly different from the old one?  Specifically one that is sufficiently different from the previous historical pattern so that none of those editors and none of those reporters are subject to vastly reduced search space attacks on their new password?  The same problem exists for corporate executives protecting an enterprise’s IP.  Is it reasonable to count on the new passwords being sufficiently secure?  For all users?  It is unlikely that sufficient number of them will choose a new password with no resemblance to the last one, such that the overall system can return to the same security protections that were in place before the breach.

Password resets are an important and required step after a password or any other significant breach of a system, and it is inarguable that changing all the passwords in a breached system provides a measurable and tangible improved security profile.  The unfortunate reality is that requiring a password change is not enough.  Clearly creating systems that provide protections in addition to, or instead of, passwords are a great way to mitigate this risk, especially if those systems can take only a minor or even negligible dependency on a password provided by the user.  And short of systems such as those, or even in addition to systems such as those, users must also be sufficiently educated on how their password histories enable attackers to predict their next passwords, so that they are aware of just what they lost when a password breach occurs and how they can protect themselves, their own personal accounts, and the corporate account to which they have been entrusted with privileged access.

Kenneth Ray is Director of Technology at RSA, focusing on Core Crypto Tools, SaaS Security Isolation and Compliance and Big Data Analytics based Identity and Access Management.  Before joining RSA, Kenneth spent 16 years developing and architecting Windows Kernel, core USB, Windows Security, BitLocker, Xbox and Xbox Live Security, Rights Management Services and the Anti-Piracy model for Windows Phone. 
 Sandy Carielli has ten years of experience in the security industry, as a product manager, consultant and engineer.  Currently, she leads product management for the Data Protection portfolio at RSA.