backend encryption / security

Wed May 7 17:06:13 EDT 2014

Hi all,
thank you for the valuable feedback. 

Let me start by saying that programming is not something I'm current at - I haven't written anything longer than 10 lines, for more than 8 years so you get an idea. On the other hand, security (design, architecture, consulting) is what I'm really good at, and some of the comments that I read do not make much sense from a security perspective. 

I'll try to elaborate as much as I can without getting too technical - but I'm willing to do so if required.  

a) Why: for one, because users want it. It has 100 votes in uservoice, and I personally believe something like that should be standard in any financial application no matter what we think about other people's data sensitivity. 

b) Why not encrypted filesystem: There are several reasons, some of which are that encrypting a whole filesystem for a single file is an overkill, that one might use gnucash in his work pc not having the option to encrypt the filesystem, that one might use the portable version, again not having the option to encrypt the filesystem, that one might carry between systems the datafile on a usb, again without encryption, backing up the file on a usb, a tape, a cloud service and so on. 

c) password vs encryption: there is no way one can protect a text file with a password. Somebody can simply unzip the file and see the xml contents. if the "password protection" functionality is in there, it's completely useless. With encryption on the other hand, if we adjust the file load and save routines, to decrypt and encrypt respectively, we are done and the file is always protected. 

d) Ram access, side attacks, keyloggers etc. No, the proposed solution does not try to address these issues. But they are not addressed now either, and they are not addressed with an encrypted filesystem or any other 3rd party option that is currently discussed (such as gpg-ing the file and so on). The suggested solution is far much secure than these solutions regarding data-at-rest. 

e) implementing encryption should be left to encryption specialists: I totally agree, that's why I researched and suggest to use aescrypt code. it is there, cross platform widely used, based on standards, so it's much more better than anything I could (and I believe any gnucash developer not involved in secure programming) implement. In an essense, the suggestion is not to write encrypt/decrypt functions, but rather to use existing ones and integrate them. 

f) log files, backup files etc: as I said, I am not sure if I can pull it off due to my limited programming skills. I can tell you how it should be done though: The key should be provided by the user on loading a  file, be kept in program memory, and be used for any load/save function. That should take care of all relevant files in disk (the profile is a different thing). Actually, this is as secure as it can get wr to data at rest, because data is never written unencrypted - it's only on system memory. Now, taking the user's key and storing it somewhere in software memory, to be there for as long as the file is open, is something that I don't know how to do (yet).  

Having said all that, I'm not really dying to implement it!
I just thought it would be a nice addition that a user might choose to use or not - I definitely would. If you don't agree, no harm done, I'll drop it and move to the next target :) 

Kind regards
Michalis 

----- Original Message -----
From: Sumit Bhardwaj
Sent: 05/07/14 08:52 PM
To: Christian Stimming
Subject: Re: backend encryption / security
 Merging threads from Christian and Michael.

My summary from the thread is that:
Password protection feature seems to be something that would be useful to
have. Encryption is better left to specific tools. This would be easy to
explain to users. From Derek's email, it's a good idea to go ahead.

Thoughts/comments?

Thanks,
Sumit

On Wed, May 7, 2014 at 11:22 AM, Christian Stimming
<christian at cstimming.de>wrote:

> Hi Michalis,
>
> thanks a lot for your offer for help, and thanks for explaining your idea.
>
> Contrary to what some other developers replied, the feature is indeed
> welcomed
> by at least part of the developers and surely by many users. I've discussed
> this previously, see (as you have probably seen already)
> http://gnucash.uservoice.com/suggestions/1547269
> and the thread following of
> https://lists.gnucash.org/pipermail/gnucash-devel/2013-June/035754.html
>
> From the user's point of view, having the possibility for an access
> protection
> password does make some sense and to my understanding this particular user-
> level feature would also be welcomed for inside gnucash.
>
> The picture may be different, though, when talking about an integrated
> encryption feature in gnucash. I, for one, would welcome that feature as
> well,
> so to provide some more access protection against "casual" access by
> someone
> unauthorized (e.g. shared user account as explained in the uservoice
> comments). It remains an open question on how to explain the limits of this
> feature clearly enough to the user. I.e., facts such as encrypting the data
> file doesn't make the log files disappear and so on. If you can explain how
> your solution solves the user feature request of casual access protection,
> but
> without tricking users into a too self-confident feeling of security, I
> think
> this is a worthwhile feature.
>
> Best Regards,
>
> Christian
>
>
> Am Dienstag, 6. Mai 2014, 18:40:03 schrieb Michalis Kamprianis:
> > Hi,
> > I can see in uservoice, and I think frequently asked in lists, the
> request
> > for encryption or password protection of the datafile.
> >
> > Regarding database backends, I believe that database encryption should be
> > used if required, (although I understand that dbi may not be up to the
> > task).
> >
> > Nevertheless, for xml backend, I think that I could try to implement an
> AES
> > based encryption (on saving) and decryption (on opening), based on code
> > from aescrypt. Aescrypt is available for unix, windows, mac, so the
> > implementation should probably be portable across platforms. The code is
> > some gpl and some freeware. Of course such a solution only protects data
> at
> > rest (i.e. when data is read in memory it is not protected. Log files are
> > not protected. User configuration files are not protected - at least
> > initially, and so on) so it's not transforming gnucash to the most secure
> > accounting software out there, but solves the problem with datafile
> > misplacement or unwanted access.
> >
> > The thing is, (a) I don't know if you're interested and / or agree in
> > implementing something like that, and (b) although I will probably manage
> > to code the open and save routines, I'm not sure I will not get stuck
> > somewhere, in which case it will either remain as an unfinished project,
> or
> > I will need some help from somebody more experienced.
> >
> > Your thoughts?
> >
> > Regards
> > Michalis
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel 