On windows you can use DPAPI. I don't know if Linux (and other systems) has something similar (maybe Gnome-Keyring?).
On the server you need to create an account used exclusively by the Firebird Service. Firebird can then use CryptProtectData() and CryptUnprotectData() to encrypt the database key and store the encrypted data in files (maybe hex/base64 encoded in database.conf). Working with keys in memory can be protected with CryptProtectMemory() and CryptUnprotectMemory(). It prevents others from viewing the key when the process is paged out to the swapfile. One important thing to remember is that if someone reset (not change) user's (firebird service account) password you will be unable to decrypt your data Brian Vraamark -----Oprindelig meddelelse----- Fra: Jim Starkey [mailto:j...@jimstarkey.net] Sendt: 22. august 2015 17:36 Til: For discussion among Firebird Developers Emne: [Firebird-devel] Brainstorming Secure Unattended Start w/ Encrypted Files Problem: How to start server on encrypted database files with a human to supply a password. Idea: Assume SRP is being used for authentication and that all (or most or some) are using long, randomly generated passwords from a client-side vault (or equivalent). This means that it is safe to store account/salt/verifier triplets in an unencrypted file external to the database (if you want to get fussy, hash the accounts). The server starts up unabled to access the database file. In this state, the first SRP connection request is processed through the external verifier file. After a secure connection is established with the client, the server requests that the client send a hash of the client's password that is used to open a server-side client specific vault containing the generated password for the master vault that contains the database file encryption key. The verifier file would be recreated by the server whenever a verifier changed. The account specific server-side vaults would be recreated whenever an account password was changed. Changing the master password would be a real pain in the butt. The only way for an attacker to crack the system is with a stolen client password (not present anywhere on the server) or by breaking a server-side client or master vault, all of which can be substantially hardened with high pbkdf2 iteration counts. An attacker could also break the system by subverting a client, stealth the client password by hook or by crook, taking over the server, forcing a database server restart, and jumping in from the compromised client. But at that point, you are so hopelessly compromised that nothing is going to work. Jim Starkey ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel **************************************************************************** Denne mail er blevet scannet for virus af TDC Mailfilter. **************************************************************************** ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
