It does not matter that the file is in plain text it can only be protected by permissions and root can bypass those permissions. If the secret is stored on the server in any way which is readable by the application without human intervention, then its readable by at least root on the machine. (assuming you do not require an automated password reset) This is an elaborate yet effective system which focuses on limiting the amount of time a secret is stored, even in Memory. I've outline a way to derive decryption keys from user passwords and session tokens here. If the client can provide a portion of the secret, that would be the helpful. If your concern is hard drive theft, (leaving the rest of the machine behind) then you could have a boot-up script that queries some of the other hardware for unique identifiers, and derives an encryption key using a good Password-Based Key Derivation Function to decrypt the secret. There are very few cases where the secret can be encrypted itself in permanent storage. Raspberry Pi) There is some discussion of physical separation here. It at least has to be stored in Memory, but also permanent storage of some kind is necessary.īeyond of user separation we've discussed, it could be helpful to off-load secrets to a separate Hardware Security Module, or even a separate mini-computer. Now the question is, does the secret really need to be stored in plain?Īt the most basic level, yes, the secret must be stored somewhere for it to be usable. (SSH, other services on the machine) Make sure anything with the potential for root access is well secured.Īll of these considerations should help you to secure the secret itself. Using a separated user on network-exposed processes can help limit the scope or add difficulty to an attack.īreak-ins from other attack vectors could be an issue. OpenSSL running your HTTPS encryption, image processing, etc.) might be possible. There are other types of attacks on your application that you should secure against.Įxploits in C libraries (i.e. SQLi if properly configured does not grant filesystem access, but Path Traversal attacks could. You should consider potential attack vectors. Either have two daemons running with real-time communications, or have utility commands to operate on the secret, gaining the necessary privilege (user or group-based) via sudo. It may be helpful to use two users for this single application to isolate secret management from normal operation. (unless you are running some complex SELinux setup) Anything running root has full access anyway. As long as your secret file has permissions 600 or less it will be safe from other non- root users. Using a separate user to store the secret is a wise precaution, but storing files with root ownership is no better for secrecy than using another dedicated user for this. Your service should not run as root generally. I am basically looking to prevent the secret from being in plaintext on the disk, and without a human in the loop to bootstrap the encryption process, the best that can be done is to make it harder to get to the secret even if someone gets code execution.Ĭan anyone share any suggestions on how I can improve the current situation? Is keyctl something that is applicable here or is that normally just used to store kernel secrets? This way the secret file can be owned by root but then the password change scenario breaks unless I am running another daemon as root. The application could be started as root and then drop privileges to the application user. I am trying to think of ways to improve this situation since the password is in plaintext in a file. The application will run under a separate user account and the secret is currently in a file owned by that user. The application also allows the users to change the encryption password during runtime. I have an linux application that needs to read a secret to decrypt some data.
0 Comments
Leave a Reply. |