2

I'm looking to do file encryption for small amounts of text (8-100 characters for each item being encrypted). Here's what I have:

  • A secret passphrase and a salt.
  • I Use Rijndael to generate a key and iv when encrypting text.
  • I use the key+iv to encrypt the text.
  • I store the iv+encrypted text as the cipher.
  • I HMAC the result.

Now my question is regarding the passphrase. It's a requirement for PCI DSS to rotate the passphrase at least annually. I was wondering if it would be insecure to have the year part of the passphrase. So, if my "core" passphrase is "Orange Ballons", the passphrase I'd use is "Orange Balloons2013", "Orange Balloons2015", etc. based on a year relevant to the business for that data item.

Is this a potential security hole, or is it okay to do this? My inclination is not to do it, but it will make key management a lot simpler in my particular use case.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
ashic
  • 135
  • 3
  • 1
    http://security.stackexchange.com/a/2213/971, http://security.stackexchange.com/a/2209/971 – D.W. Jul 27 '15 at 21:32

2 Answers2

5

The first thing that comes to mind is that once someone knows one password, they know all past and future passwords, too.

The idea behind changing them yearly is to counter that problem if someone ends up cracking the passphrase, but it also provides at least a little protection against past employees who may have had access to those passphrases, too.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 2
    @ashic: I would add that you might give here a key advantage to an attackant. He might know your 2017 password (Orange Balloons2017) before you use it, and before you detect a past leak. You don't need to give that advance to any attackant. – dan Jul 27 '15 at 18:02
2

Yes, this is insecure. It might pass audit if nobody checks, but it is very insecure.

In any case, your method doesn't save you a whole lot, because you still have a key management nightmare of determining which year to use for which entries (unless you are basing it off of modified date, which is a bad idea).

You are going to need a more fully fledged system that tracks which keys are used for which entries. At that point you can use more complex keys at no additional cost.

You also have a key rotation issue to deal with, in that old entries use the old key, but need to be updated to the new key periodically.

It might be easier to store all entries in a shared database, where the database is encrypted, but individual entries are not. Then you only have one key to track. The downside of that would be if you need to segment which users can access which data.

Jason Coyne
  • 1,583
  • 2
  • 10
  • 10
  • Yes...kind of expected that...As for audits, practically anything passes these days :P – ashic Jul 27 '15 at 17:20
  • In any case, this doesn't save you a whole lot, because you still have a key management nightmare of determining which year to use for which entries (unless you are basing it off of modified date, which is a bad idea). You are going to need a more fully fledged system that tracks which keys are used for which entries. At that point you can use more complex keys at no additional cost. – Jason Coyne Jul 27 '15 at 17:25
  • In this case, there's some additional business info that can be used to get the year (not modified date). The key mgmt is an issue...either I rekey all data (pain), or I need to hold on to past keys for past data (pain). The former is likely more secure, but the latter is "acceptable" to PCI DSS. Then again, that's not saying much :D – ashic Jul 27 '15 at 17:28
  • Now you have +1 from me because you made a good effort. –  Jul 27 '15 at 18:33