1

I'm aware of multiple ways to store an encryption key, some very bad, such as in your codebase or elsewhere on the same server, and others much better such as where the encryption/decryption is done away from your application or is bound to specific hardware (e.g. with a H.S.M.).

It strikes me that whatever method is used, if an attacker gains access to your codebase, they can simple write a script that would decrypt and export the database.

Obviously, keeping them out of your server is very important, but am I missing something obvious in the scope of what's mentioned above?

  • they can use the HSM/SmartCard to decrypt things, but they cannot access the key inside the HSM. There is no API to access it – Neil McGuigan Jan 25 at 1:56
4

It strikes me that whatever method is used, if an attacker gains access to your codebase, they can simple write a script that would decrypt and export the database.

Preventive controls - like securing the encryption key with an HSM - attempt to prevent that from happening. But as you say, if someone is deep enough into your application, they can leverage the existing decryption methods to access the data. Preventive controls are often imperfect.

Which is where Detective controls come into play. Your application should log decryptions, and those logs should go to a SIEM that can report upon anomalous usage. If someone starts dumping all your records out, you should catch them.

No single control is perfect. Layering different controls leads to greater security.

  • That's very interesting, thanks. So, tracking activity is essential as it not only helps to identify a breach, but can also be used to trigger some kind of block or mitigation should an attacker find their way in and start dumping the db, thereby hopefully limiting the amount of damage done. – Marc Jan 27 at 12:18
1

When your software is user-facing, then a common technique is to give a password to the user they need to enter when launching the application. You use that password to derive the encryption keys for any other secrets. The password itself is stored nowhere except the head of the user. That means an attacker will need user interaction to obtain the encrypted secrets.

This concept is often used by password managers.

But it is of course not a solution for anything which is supposed to run unattended.

  • What about information that isn't unique to any particular user? For example, a system administrator might need to see the encrypted data for all users. – Marc Jan 24 at 15:30
  • @Marc Such scenarios can ofen be handled by having multiple copies of the secret, each one encrypted with the key of a different user. – Philipp Jan 24 at 15:32
  • OK, so you mean having one key to encrypt all the data, but each user has their own encrypted version of that key that is decrypted with their password? – Marc Jan 24 at 15:43
  • @Philipp Or it means an attacker can try and brute force the password. – Swashbuckler Jan 24 at 17:16
  • 1
    @Marc Yes, that's what I mean. – Philipp Jan 24 at 17:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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