I am considering encryption options for a new Sybase project (internal facing only, sitting in our intranet) for a client that has a security policy that requires all sensitive data to use DB encryption, and be only available to a trusted few. I am thinking that Sybase encryption is the wrong strategy because a) dba's can get in easily, and b) if and when we migrate to SQL Server or Oracle I don't want to deal with different encryption strategies.

Therefore I'm thinking of maintaining a single table of sensitive data, and to encrypt that column (symmetric encryption) in my Java code before storing it in the DB.

Now, the encrypted fields better not have their encryption key changed, ever, except in a very controlled environment, which for me effectively means never. So it's going to be a permanent password.

The question is, where to keep it. If it's in a properties file, any developer with access to our Git repo could see it.

We could hard code it in the source code, but good lawd, that's a bad practice.

We could generate it in source, like the 10th Fibonacci or 3!+8! that would be hard to locate, but it's still rather exposed.

We could have the sa's maintain it in the environment, but then where do they file it for future reference?

So many poor choices. Are there any good ones?

  • Read about Amazon Key management system
    – H4X
    May 20, 2016 at 21:37

2 Answers 2


Well if you're really really really serious about the security of your keys then there's only one answer.


Encrypt your data at rest using a symmetric algorithm and encrypt the keys used for the symmetric algorithm using asymmetric keys, the private key for which is stored in the HSM.

HSMs are carefully and purposefully designed so that once on them, keys cannot be exported from them. You send a command to the HSM asking it to "do something" with your key (e.g. encrypt, sign, decrypt), but the key never, ever leaves the HSM in any readable format whether printed on console or exported to a file.

If you can't justify the cost of an HSM because your data is not valuable enough or you simply can't get the budget, then the "next best" option is probably going to be a hosted "cloud HSM".

Sure there are risks involved with a third-party hosting your HSM, but those risks are probably lower than you trying to be clever (and failing at) obfuscating your keys and trying to "hide" them yourself just because you don't want to pay for your own HSM.


Your problem is less about places to put things, and more about whom to trust. No matter what, the password is going to be stored somewhere that someone has access to. You have to trust that person or persons.

The most logical choice is to limit access to just the environment where the code runs. That means a limited set of system-admins. These people have root access anyway, and if they REALLY wanted the data, they'd figure out a way to get it.

Now, you ALSO need to store the password somewhere if "secret location" goes bust. One option is simply some form of cold storage, put in a safe deposit box at the local bank. Banks are good at keeping things secure and only giving access to the correct authorized persons you keep on file with them.

  • 1
    It seems to me that whatever security solution you put in place, there is always a weak link at the end of the chain of trust. The trick is to limit that to a select few, and that is really my goal May 20, 2016 at 20:53
  • Right. All security has weakness, and none is perfect. You could also think about trying to split the secret into multiple parts, and have 2 or more people required to reveal it. You may be limited by the underlying OS, however, which generally doesn't have these two-party rules in place. May 20, 2016 at 21:01
  • Well, at some point the application needs to access that key so the big question is where to store it so the application can see it but not anyone else May 24, 2016 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .