| Subject | Re: Re : [Firebird-Architect] Database Password |
|---|---|
| Author | Alexandre Benson Smith |
| Post date | 2008-10-14T20:23:22Z |
Jiri Cincura wrote:
AFAIK the problem is the key management, and the fact that FB is Open
Source software and cannot rely on security by obscurity (no one could
rely on this by the way) and is easy to someone forge a engine to steal
password.
I think we should follow the same steps as others OS security projects
like TrueCrypt. TrueCrypt stores a "real key" inside the header of a
crypted volume, that key is used to decrypt the volume content, but to
get the "real key" one must know the key that decrypts the header, that
key is not stored anywhere besides the head of the volume creator. Each
database could have a distinct key.
What about if FB uses a similar approach ?
The benefit of having just the header encrypted with the user key and
the rest of the volume encrypted with a derived key (with some salt) is
that if the user needs to change the encryption key, just the header
needs to be re-encrypted and not the whole volume.
Please, you guys that have already discussed this in depth, could please
tell me what is the problem to ask for the "server encryption key" on
start-up ?
I don't think the key should be passed by the client, the client should
have no idea that the database is encrypted. It's a server task only.
Taking into account that the engine executable could be compromised, I
think that this is up to the server administrator to verify the FB
binaries before provide any password, comparing it to some signatures
stored in a safe place (a USB stick is enough to hold a tiny application
that compares to the expected SHA signatures). Any kind of built in
protection could be easily bypassed by someone with a custom FB build.
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
> On Tue, Oct 14, 2008 at 5:01 PM, marius popa <mapopa@...> wrote:I am not security specialist, so forgive me if I am talking bullshit...
>
>> I think the best is to keep the private key near database server
>> (firebird crypto folder)
>>
>
> I don't think this a good place for private key. ;)
>
AFAIK the problem is the key management, and the fact that FB is Open
Source software and cannot rely on security by obscurity (no one could
rely on this by the way) and is easy to someone forge a engine to steal
password.
I think we should follow the same steps as others OS security projects
like TrueCrypt. TrueCrypt stores a "real key" inside the header of a
crypted volume, that key is used to decrypt the volume content, but to
get the "real key" one must know the key that decrypts the header, that
key is not stored anywhere besides the head of the volume creator. Each
database could have a distinct key.
What about if FB uses a similar approach ?
The benefit of having just the header encrypted with the user key and
the rest of the volume encrypted with a derived key (with some salt) is
that if the user needs to change the encryption key, just the header
needs to be re-encrypted and not the whole volume.
Please, you guys that have already discussed this in depth, could please
tell me what is the problem to ask for the "server encryption key" on
start-up ?
I don't think the key should be passed by the client, the client should
have no idea that the database is encrypted. It's a server task only.
Taking into account that the engine executable could be compromised, I
think that this is up to the server administrator to verify the FB
binaries before provide any password, comparing it to some signatures
stored in a safe place (a USB stick is enough to hold a tiny application
that compares to the expected SHA signatures). Any kind of built in
protection could be easily bypassed by someone with a custom FB build.
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br