On Mon, Jan 17, 2011 at 11:46:11AM +0100, Jensen Somers wrote: > I am migrating from a binary data format. But it's hard to maintain and > add new features. Most of the operations I need to perform on the data > is list, sort and analyze, which is why I'm interested into using a > database as a back-end solution. > Once a recording session is completed the data should be locked and not > modified anymore. > I have no problem with a user knowing I use PostgreSQL, but if there's > no way I can block him out of the database and prevent him from > manipulating the data in any way PostgreSQL is, unfortunately, no > longer an option. If the user has control of the data, then the user can modify it. If your current binary data file is on the user's machine, there is effectively no way for you to prevent the user from modifying the data in some way. The same is true here. What you can do, of course, is encrypt the data on the way in, and put checksums on the data (both on each row and on a series) to detect that data has been altered. Of course, the entire series could be replaced. Since you say no interaction with an outside system is possible, the encryption keys are going to have to be available in the application too, so I wouldn't put too much faith in that. You need to figure out how valuable the data is, how much it would be worth to the user to be able to alter the data, and then make your data more secure than that. Hard guarantees about the safety of data that is in the hands of a potential attacker are simply not possible. (If you don't believe me, consider the failures of the various security arrangements on smart cards, SIMs for mobile phones, and so on. If the user has everything it needs available locally, then it is always possible for the user to get control. It's just a question of whether it's worth doing. There are alternatives; for instance, you could have a "lazy" replication system to some other system -- one that perhaps only captures changes to metadata rather than the actual data, so that user data isn't actually shipped to you, or something. It is also possible to subvert this sort of system, but it's more work & therefore raises the cost of such a system. (In this kind of system, to be secure, each piece of metadata needs to include a reference to the previous one in the chain. It's hard to yank one piece out without replacing everything that comes after it, so such an attack would be easier to detect. Not an impossible attack, just harder.) A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
