Feature discussion: Access restriction for gnucash files by password

[John Ralls]

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.

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.

Regards,
John Ralls