Patreon data breach – Cryptography may not be enough
The crowdfunding site Patreon has become the latest high profile victim of a data breach.
Although the hackers seem to have gotten away with more than just client records!
Patreon first acknowledged the breach at the end of September (Patreon Security notice here). This notice reveals how hackers were able to gain names, emails, posts and some addresses (both shipping and billing) that were added before 2014. Encrypted information such as passwords, social security numbers and tax information was also taken, fortunately no credit card info was.
So far this is all pretty standard and not really blog worthy – the loss of database records and encrypted passwords happens every day (if you follow our twitter you will be up to date with this). We all know that with enough time and computing power, encryption could be broken (an old story but it shows how Encryption can be broken). Patreon were diligent and used the powerful hashing function called ‘bcrypt’. This means such decryption will take more time. However according to an Ars Technica Report, the hacked data also includes source code. With this source code the hackers may be able to find coding errors to get around such encryption – such as exposing the encryption key. If this were to happen then all of the encrypted details, such as the tax information, passwords and social security numbers will be viewable in plaintext. This sort of oversight could be disastrous, losing client data is bad enough but with the source code, carefully implemented security measures can be interrogated and potentially subverted.
We certainly hope the encryption key is not held within that source code – or that encryption is for nothing.
This points to a key security issue – we cannot rely on just one form of security. Encryption itself when implemented properly is great but an attacker will not try to break down a door if a window is open. If encryption can be bypassed by a poorly stored key or by implementing it improperly your data is still at risk. This is another reason why code reviews and vulnerability assessments are essential.