On Monday, August 24, 2015, Ray Cote <rgac...@appropriatesolutions.com> wrote:
> What about integrating with an external credentials store such as: > http://xordataexchange.github.io/crypt/? > Granted, it means FB is dependent on an external library application. > That's just a vault. Nothing hard or exotic about building a vault. If you have a standard compliant crypto library, it's less than a day's work. Too small to build an external dependency around. > > On Sat, Aug 22, 2015 at 11:36 AM, Jim Starkey <j...@jimstarkey.net > <javascript:_e(%7B%7D,'cvml','j...@jimstarkey.net');>> wrote: > >> 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 >> > > > > -- > Raymond Cote, President > voice: +1.603.924.6079 email: rgac...@appropriatesolutions.com skype: > ray.cote > > > -- Jim Starkey
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
