On Sun, Sep 27, 2009 at 11:42 AM, Steven D'Aprano < st...@remove-this-cybersource.com.au> wrote:
> On Sun, 27 Sep 2009 16:11:52 +0200, Stef Mientki wrote: > > > hello, > > > > I've a Python desktop application, running under Widows, that stores the > > data in a central SQLite database. > > > > Depending on the user login on the system, some of the data from the > > database is allowed and other data is forbidden. > > > > I can read the current logged in user. The authorization for each user > > is stored encrypted in the database. The program is delivered as pyc > > files, but from what I read, these can easily be reversed engineered. > > What does that have to do with anything? You're not storing the user's > password in the source code are you? > > > > There is even an encrypted version of SQLite (not freeware), but as long > > as test the authorization in Python, it doesn't seem to be a good > > protection. > > What exactly are you doing to authenticate the user? > > > > So at first thought, a better way might be the following process: - > > encrypt the whole database > > What is your threat model? What are you trying to protect against? > > If your threat model is that desktop users will sneak into the server > room while the boss is away, boot the server in single-user mode, and > then use a disk utility to inspect the raw bytes on disk to read the data > in the database (or that the government will swoop in and seize your > computer and do the same), then encrypting the entire database may be a > good idea. > > (But if your threat model is the government, then what are you going to > do when they arrest you and demand you hand over the encryption keys?) > http://en.wikipedia.org/wiki/Deniable_encryption cool stuff. Geremy Condra
-- http://mail.python.org/mailman/listinfo/python-list
