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

Reply via email to