Sign up ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

I want to plan for the terrible nightmare of my database being stolen. I feel I am secure, and I am not holding much actual data, but... if it does get taken - what do we do, is there a standard way of drupalists to respond?

I am looking for specifics where obviously required, e.g. 'reset all passwords', but how?


share|improve this question

1 Answer 1

up vote 10 down vote accepted

In Drupal 7, while all passwords are hashed (SHA-2 with 64-bit words) and salted, if your user's passwords have low entropy, brute-force password attacks are feasible.

enter image description here

Image source: xkcd, explanation.

Also note that the cartoon above assumes that an attacker tries to brute-force passwords over the web. As pointed out by @Damon in a comment:

Readily available brute-force crackers check 200-500 million hashes per second on a single commodity PC, not 1000. That means a 44-bit password doesn't even last half a day, and a password as 99% of users will realistically have will last 1-2 seconds at most.

This means that if you experience a breech, you should force your users to reset their passwords, there's is the Force Password Change module that will invalidate all passwords and force users to set a new one.

There is also the Password Policy module that let you set a policy to force users to pick a password that is hard to crack by brute force (but it tends to enforce the type of policies the xkcd cartoon above lampoons, so I am not a big fan of it).

In addition to these modules, there is a recipe on to create a drush command to change passwords on accounts that are not actively used that may be used to invalidate passwords for stale accounts.

You may also condsider making your site less vulnerable to password cracking by adding Two-Factor-Authentication.

To guard against PHP injection, you may want to install the Paranoia module.

The Paranoia module attempts to identify all the places that a user can evaluate PHP via Drupal's web interface and then block those. It reduces the potential impact of an attacker gaining elevated permission on a Drupal site.

To monitor your site and detect unauthorized changes, you may want to install the MD5 Check module.

The MD5 Check generates a md5 checksum of all module files. If module is changed a critical security error is generated in watchdog log.

There may be other sensitive data in your database beside passwords (e.g. credit card numbers, medical records). If you're really worried about your database being stolen, you need to encrypt sensitive data stored in the database. The Encryption module helps you defend sensitive data by means of symmetric encryption.

The the Payment Card Industry AFQ provides guidelines for what you should do if your site stores sensitive data. It also links to guidelines for dealing with data breeches.

Depending upon your location, yoy may have to report a data breach to affected parties. In the EU/EEA, this is mandated by the Privacy Directive. In the US there are now over 38 states that have privacy law that mandates notification. See for more details.

Acknowledgements: Thanks to @Damon for pointing out that even 44 bits of entropy may not be good enough these days. Thanks to author of Cracking Drupal and Security Team member @greggles for bringing the Drush command to invalidate old passwords and the Parnoia module to my attention. Thanks to @Ben for making me aware of the PCI guidelines.

share|improve this answer
Plus 1 for the amusing comic :) – rooby May 17 '14 at 11:45
SHA-2 for hashing passwords? That strikes me as an exceedingly unfortunate choice of hashing algorithm for passwords. SHA-2 is great for things that you want to do fast and cheap (memory wise) such as encrypting SSL traffic. For password hashing you want the exact opposite: You want something that's slow, hard to implement efficiently in hardware and has a relatively large memory footprint. SHA-2 is horrible in that regard - it's trivial to create custom ASICs or even FPGAs that compute SHA2 extremely quickly, heck Intel and Co already include hw acceleration out of the box. – Voo May 17 '14 at 19:41
If you're storing credit card numbers in your database they really ought to be encrypted already to ensure that you're PCI compliant. – Ben May 17 '14 at 20:03
This is a great answer so I'll suggest an edit to add and as a way to change passwords. – greggles May 17 '14 at 21:58
Amusing as the xkcd cartoon is, reality has it that no single user has a 44-bit strong password, but even assuming they did, it wouldn't take hundreds of years to brute-force them. Readily available brute-force crackers check 200- 500s million hashes per second on a single commodity PC, not 1000. That means a 44-bit password doesn't even last half a day, and a password as 99% of users will realistically have will last 1-2 seconds at most. Bcrypt/scrypt exist for a reason. – Damon May 17 '14 at 23:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.