On Tuesday 25 June 2013 14:20:33 John Ralls wrote: > On Jun 25, 2013, at 1:30 PM, Christian Stimming <christ...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
