Feature discussion: Access restriction for gnucash files by password

[Christian Stimming]

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?

Regards,

Christian