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
