Two systems must share a secret for JWT signing. The secret has to be shared and stored. Are there tools and there guidance for doing this securely?
Asked
Active
Viewed 145 times
5
-
Applications may be secure or insecure. Additional tools can be helpful for various tasks, but a 'tool' will not protect you if the application insecure. – 700 Software Sep 02 '16 at 13:37
-
Then there are people telling us to not write our own crypto. Make up your minds. – bbsimonbb Sep 06 '16 at 12:51
-
*"Make up your minds."* I don't appreciate that comment. – 700 Software Sep 06 '16 at 13:11
-
A cryptographic *algorithm* is not a 'tool' as I was describing above. When I say tool, one example I am referring to would be an AntiVirus or IPS, which is advertised as something you can easily install to secure an existing system. Such tools are *"helpful for various tasks, ... will not protect you if the application insecure"*. Perhaps when you said "tool" you had something else in mind? – 700 Software Sep 06 '16 at 13:15
2 Answers
5
The first step is to ensure your application is secure, not just to protect the secret in question, but also the application as a whole. If your application is perfectly secure, then there will be no possible exploit, and the secret is safe. Unfortunately, we are not perfect and it is likely that there is some vulnerability lurking in the application that has yet to be discovered.
The following points will help you reduce the impact, should a vulnerability be found and exploited in your application:
Store important secrets outside of the database, -or- you could store the encrypted secret, with its decryption key outside the database.
One of the most common exploits exploits is to gain access to data via SQL Injection. If the secret, or the key that encrypts the secret is stored in a file outside the database you have eliminated that attack vector.
Use the strictest possible Filesystem Permissions possible on the file. It is best if the only user account which can access that file be the application in question.
Other applications can run on separate user accounts so that if those applications are compromised then your secret will still be safe.
Physical or VM separation is even better. The point again is that you do not want exploit of unrelated applications to compromise a secret that is only used by the application in question.
One inexpensive way to achieve physical separation would be with a small computer on the network such as Raspberry Pi or HSM, with a single dedicated purpose. Since your particular secret is itself a cryptographic key, you could outsource the cryptographic operation physically. That device could have only very simple software running on it so you know there is no way to extract the cryptographic key without physically removing the storage media.
In this quote, substitute "deficiencies" for "vulnerabilities" and it still holds true:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” ― C.A.R. Hoare.
I'm not familiar with the operation of your service, but if it is accessed via Username and Password, then you could use user-defined passwords to derive keys to decrypt the secret as needed. I've outlined how that would work here: How can we serve sensitive encrypted data without storing the key? Should I use user-defined passwords for keys? However, that solution will not work for an autonomous system, because the user's password and session key would not be available.
700 Software
- 13,807
- 3
- 52
- 82
1
It depends greatly on the value of what these keys protect.
For very valuable systems, then you'd typically invest in a networked HSM.
For system having a lower value, you can use a key management system (for instance, Vault).
For system with little value, you can use two copies (each properly protected) of the shared secret.
Stephane
- 18,557
- 3
- 61
- 70