Feature discussion: Access restriction for gnucash files by password

[Geert Janssens]

On Tuesday 25 June 2013 14:20:33 John Ralls wrote:
> On Jun 25, 2013, at 1:30 PM, Christian Stimming <christian at cstimming.de> wrote:
> > I'd like to discuss a possible implementation for the following
> > feature request:
> > 
> > Allow the database to be secured by way of a password (Bug 700803)
> > http://gnucash.uservoice.com/suggestions/1547269
> > 
> > The aim is not actual security in the sense of encryption, but just
> > to prevent casual access. As described in the uservoice comments:
> > One example use case is that multiple people share the same PC and
> > user account, but only some of those people should be able to look
> > into the gnucash file when they open the gnucash program.
> > 
> > Traditionally, we immediately refused any request regarding this
> > topic, stating that we (=gnucash) don't want to start dealing with
> > security and encryption, because other people who are encryption
> > specialists will do a far better job in implementing those topics.
> > Hence, we refused any feature going into that direction, as stated
> > in the FAQ:
> > http://wiki.gnucash.org/wiki/FAQ#Q:_.22Can_you_please_add_a_password
> > _feature.3F.22 The wiki contains a wrapper shell script that runs
> > gpg on the gnucash file before and after gnucash editing because of
> > this answer.
> > 
> > However, I think the above feature request can very well be dealt
> > with inside gnucash, even without raising the need of special
> > encryption know-how. Instead, I'd like to take the uservoice
> > request literally and propose to add an "access restriction
> > password" feature, but without any actual encryption of the data
> > file. To do this would just require a comparison of an entered
> > password with a stored one. The simplest implementation of this
> > would be to add a password string or better a hash of the password
> > as a kvp value of the book into the gnucash file. On loading a
> > gnucash book that contains this kvp value, the password dialog is
> > presented, and the loading will continue only if the password is
> > given. Which would work for both XML and SQL backend.
> > 
> > The description of this feature must be chosen carefully so that it
> > is clear that the data is not encrypted, only the access in this
> > instance of gnucash is restricted. I.e. the wording in the user
> > dialogs must make it clear that opening the gnucash file with other
> > programs (text editor) can easily make the data accessible again.
> > 
> > However, even a simple implementation as described here would
> > probably be enough to solve the program with "casual access", when
> > multiple people can see the gnucash icon on the desktop and
> > clicking on it should not immediately give access to the full
> > financial data. I believe this is some valid use case for which the
> > implementation is an improvement, even without providing any hard
> > encryption. For people who have a need for strong encryption and
> > security, the existing advice ("use an encrypted file system") or
> > the gpg workaround are still completely valid and useful.
> > 
> > What do you think?
> 
> I think users shouldn't share userids. ;-)
> 
> 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.
I'm ok with this as well.

> 
> 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.
Agreed. For MySql and Postgresql this issue can be fixed by only optionally storing the 
password. Adding a "Save password" checkbox in the proper open and save dialogs could 
be sufficient.
> 
> Regards,
> John Ralls
> 
> 
Geert