Feature discussion: Access restriction for gnucash files by password

[Tommy Trussell]

On Wed, Jun 26, 2013 at 4:00 PM, Geert Janssens
<janssens-geert at telenet.be>wrote:

> On Wednesday 26 June 2013 22:45:24 Christian Stimming wrote:
> > Am Dienstag, 25. Juni 2013, 14:20:33 schrieb John Ralls:
> > > I suppose that this isn't too harmful so long as it's clear that it
> > > conveys a false sense of security and that simply having separate
> > > userids is a better solution.
> > >
> > > Note that the MySql and Postgresql backends do provide for
> > > authentication, but we defeat it by storing the userid and
> > > password. In those cases we should  pop up the authentication
> > > dialog rather than storing the credentials rather than using a KVP
> > > parameter on the book.
> >
> > Where do we store the passwords? Just in the full URL? That means if
> > there is no password the connection just doesn't open. We don't have
> > an extra password dialog if the SQL server responds but asks for a
> > password, correct?
>
> If I remember correctly, I implemented this as follows:
> - if the user enters a password in the file open/save as dialog, it's used
> - if no password is entered, a password request dialog pops up before
> attempting a connection
> - when a keychain is available, the password is stored in there
> automatically. This part may
> need some refinement.
>
>
I know this goes beyond the measures you have described, but doesn't the
zip compression library include support for a password? What if (when using
compressed xml) GnuCash included the password when compressing and
uncompressing the file?

I realize this wouldn't do anything about securing the log files or
sanitizing the data in RAM or any of the other places a truly secure
program would do AND it seems possible different zip libraries on different
platforms might implement the password in subtly different ways. HOWEVER
this would further "protect" the data file from casual inspection, and
might be a "free" feature provided by the zip library.