0

I have a Private Key that is regularly used to decode incoming files during off-business hours as part of an automated process.

Currently, it is stored in the application code itself, and only ever used for this process - but this is probably not a good idea, even though our application is internal-facing only.

Where should we store our private key so that it cannot be abused, but can still be used regularly to decode incoming documents?

Improve this question
1
  • If it's internal-facing, you're probably already doing it the best possible way. You could add a thin layer of obfuscation to the key, just to thwart casual abusers. Determined folks will be able to get at the key no matter how you attempt to protect it, so hopefully you don't have any of those people in your staff.
    – Robert Harvey
    Commented Aug 20, 2015 at 15:12

1 Answer 1

Reset to default
1

A best practice about private keys is that they should be time-limited and regularly updated. So there should be a way to synchronize the new public key to the senders. This suggests that the private key should be in the configuration or in a file argument.

Security is all about trust, so the exact answer depends on which colleagues you trust, how the senders will trust the new public keys, who can see the password that protects the private key. Who administers the machine where this application runs?

Improve this answer

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