Fra: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
On 24/08/2015 09:16, James Starkey wrote: >> >> No problem other than this requires that database account credentials >> be on the client disk and therefor theoretically available to an attacker. >> >> There is no way to make any of this easy. > I think it's clear that when you mix: > - A possible attacker has physical access to the server I can protect the server from physical access (locked in a room with keycard access). It is the client computer that's my problem. > - An open source product Why is open source a problem? Obscurity isn't security. > I think people should understand that they cannot put their own software with > the database on a customer and avoid him to stole database data and objects > in this situation. It's not our customer that is the problem. It is his customers = patients. In our case the patient is sitting in the dental chair next to the client computer. If the client computer holds all keys, every kind of protection (database encryption) is reduced to keeping the client password secret. The dentist has to (by our law) log out every time he leaves the computer and log in when he comes back. This can happen with the patient sitting in the chair. I'm not looking for the perfect solution. It doesn't exists. I'm looking for something that cannot be broken too easy. As I understand Jim's idea, the flow is like this: "Client password ---> Client-vault (on the server) ---> Server->vault (on the server) ---> Master Encryption key (database key)" If you have 50 clients, you have 50 ways to access the master encryption key (database encryption key). If you steal the client-vaults, server-vault and the database, there would be 50 persons with a password that can decrypt the database. Jim's idea puts the database security in the hands of the company staff instead of the server admin. It is easier to keep a secret with 1 person then it is with 50. It is easier to sue one person over 50 for stealing data. Jim's idea MAY be flawless - people are not! /Brian Vraamark ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
