|Subject||Re: [firebird-support] Re: Undocumented internal encrypt/decrypt in FB|
>> (In other words, if I store my database in TrueCryptthen
>> volume, all that an attacker has to do is to run my application and
>> copy the GDB file from the mounted volume; that would not bepossible with
>> native encryption).It is different in that with my proposal, this kind of attack does not work.
>Yes they could, but how is this any different to what you are proposing?
>NTFS (despite the reputation of MS file systems) has arguably strongerSee my description of the attack - I don't even need to know that any
>ACLS than most *nix file systems). As an Administrator user, I can NOT
>read a file that is encrypted with the key of another user unless my
>Key was added to the file also.
encryption is in place because I work through Firebird server, to which the
encryption is completely transparent (otherwise it couldn't be used at all -
that's the disadvantage of external application).
>> Or someone who has administrative privileges (=everyone who hasphysical
>> access to the machine) and knows that it is enough to replace thesecurity
>> database with his custom one.I could, but then I could take ownership of that one file (security
>You could also NTFS encrypt the Firebird folder to avoid that.
database) - I don't care that it will make its content unreadable because I
will overwrite it with new data anyway.
>Alexandre is right, it is trivial to compile a custom embedded dllI realize my suggestion is not perfect. If necessary, the attacker can
>that outputs the connection string used, so your security is defeated
>quite easily. I have also written a proof of concept code called
>gbak.exe that outputs the parameters it was called with to demonstrate
>a man-in-the-middle attack. It was about 5 lines of code and took 5
>minutes from start to finish.
simply debug my application until he finds the key. The point here is not to
make it impossible to access the data, but to make it difficult enough that
it's not worth the bother. I could obfuscate my code. I could modify the
client library to be compiled into my application rather than into
standalone library. I could do many things, depending on the level of
difficulty I want to achieve. I would have choice. Right now, I don't have
anything - Firebird developers decided that since PERFECT security is not
possible, it makes no sense to attempt ANY security.
Curiously, they didn't follow the same reasoning with protection from
damage - they did create backup tools (even though backup media can fail,
too) and they did create GFIX (even though it is conceivable that a certain
kind of corruption will cause GFIX to actually increase the damage).