Hi Geoff,
You must have missed the part about the developer using a custom embedded
tool ie, not going through the server but touching the database directly.
Using custom embedded tools for such work is quite common and if the
developer leaves that tool in the clients control when they are not working
on the system, that is their own fault. You can only provide tools
assuming a base level of competence. If you don't provide the solution
with the understanding that the end user has to be smart enough to use it
properly, then you can extend that line of thinking to removing all cars
from the roads on the basis that some users may drive impaired.
If you are concerned about security, you would not connect to any element
in your software stack that you are not confident of. I take it to the
next level and do not run my servers on any form of microsoft product, but,
not everyone maintains databases that contain private customer
data.............
As for redsoft, the part of their software stack that I am referring to
happens to be the grant visible code. I also know they have encryption
implemented, but as I have not performed any security testing with their
product, I can not vouch for how it is implemented or works.
As I have stated in multiple posts - I am not looking for the
authentication/authorization/encryption layer to be complete, just a parser
change. In the same vein as "COMMENT ON" replaced "UPDATE RDB$.... SET
RDB$DESCRIPTION=..." .
best regards
That would mean that the de
On 4 September 2014 12:10, Geoff Worboys <ge...@telesiscomputing.com.au>
wrote:
> 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
>
------------------------------------------------------------------------------
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
