Dalton Calford wrote: [...] > What it does mean, is that if someone tries to connect to a > database that is fully encrypted and their client does not > securely pass the decryption key to the server, the server > will just come back with an error about the database being > corrupt or some other agreed upon error message.
Well, Jim already mentioned encrypted links being necessary, but that's not the end of it. Once you no longer control the host on which encryption and decryption is performed, all bets are off. For example: The customer is running the server, yes? The server is compiled from Firebird open source, yes? The remote developer sometimes connects to do maintenance, yes? So the customer inserts a small debugging line into the code to write out the key used by the developer when they access the database remotely. Recompile and slip it in to start instead of the original Firebird server. Too easy. The application developer may add some obscurity to it all if they build their own Firebird server with a few changes to make it less easy for the customer to simply replace. I can tell a customer how to make their databases secure for themselves - and I don't need any encryption added to Firebird to do it. But I can't protect myself from my customer unless I keep control of the server. If redsoft have done it, I'd be interested to hear how. -- Geoff Worboys Telesis Computing Pty Ltd ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
