If you have been glancing at many news stories this year, you have
certainly seen the large number of data breaches that have occurred.
Even just today, we are seeing reports that Drupal.org suffered from a
breach (https://drupal.org/news/130529SecurityUpdate) that shows
unauthorized access to hashed passwords, usernames, and email addresses.
Note that this is not a vulnerability in the CMS product, but the
actual website for Drupal.org. Unfortunately, Drupal is just the latest
to report this issue.
In addition to Drupal, LivingSocial also suffered a huge breach
involving passwords. LinkedIn, Evernote, Yahoo, and Name.com have also
joined this elite club. In each of these cases, we have seen many
different formats for storing the passwords. Some are using plain text
(ouch), others are actually doing what has been recommended and using a
salted hash. Even with a salted hash, there are still some issues.
One, hashes are fast and some hashes are not as strong as others. Bad
choices can lead to an immediate failure in implementation and
Going into what format you should store your passwords in will be
saved for another post, and has been discusses heavily on the internet.
It is really outside the scope of this post, because in this
discussion, it is already too late for that. Here, I want to ask the
simple question of, “You have been breached, What do you do?”
Ok, Maybe it is not a simple question, or maybe it is. Most of the
sites that have seen these breaches are fairly quick to force password
resets by all of their users. The idea behind this is that the
credentials were stolen, but only the actual user should be able to
perform a password reset. The user performs the reset, they have new
credentials, and the information that the bad guy got (and everyone else
that downloads the stolen credentials) are no good. Or maybe not??
Wait.. you re-use passwords across multiple sites? Well, that makes it
more interesting. I guess you now need to reset a bunch of passwords.
Reseting passwords appears to be the standard. I haven’t seen
anyone attempt to do anything else, if you have please share. But
what else would work? You can’t just change the algorithm to make it
stronger.. the bad guy has the password. Changing the algorithm
doesn’t change that fact and they just log in using a stronger
algorithm. I guess that won’t work. Might be nice to have a mechanism
to upgrade everyone to a stronger algorithm as time goes on though.
So if resetting passwords in mass appears to work and is the
standard, do you have a way to do it? if you got breached today, what
would you need to do to reset everyone’s password, or at least force a
password reset on all users? There are a few options, and of course it
depends on how you actually manage user passwords.
If you have a password expiration field in the DB, you could just set
all passwords to have expired yesterday. Now everyone will be
presented with an expired password prompt. The problem with this
solution is if an expired password just requires the old password to set
the new password. It is possible the bad guy does this before the
actual user. Oops.
You could just null out or put in a 0 or some false value into all of
the password fields. This only works for encrypted or hashed
passwords.. not clear text. This could be done with a simple SQL Update
statement, just drop that needless WHERE clause
. When a user logs in, they will be unsuccessful because the encrypted password they submit will never match the
value you placed in the updated field. This forces them to use the forgot
You could also run a separate application that resets everyone password
like the previous method, it just doesn’t run a DB Update directly on
the server. Maybe you are a control freak as to what gets run against
the servers and control that access.
As you can see, there are many ways to do this, but have you really
given it any thought? Have you written out your plan that in the event
your site gets breached like these other sites, you will be able to
react intelligently and swiftly? Often times when we think of incidence
response, we think of stopping the attack, but we also have to think
about how we would protect our users from future attacks quickly.
These ideas are just a few examples of how you can go about this to
help provoke you and your team to think about how you would do this in
your situation. Every application is different and this scenario should
be in your IR plan. If you have other ways to handle this, please
share with everyone.
James Jardine is a Principal Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at firstname.lastname@example.org or visit the Secure Ideas – Professionally Evil site for services provided.