backend encryption / security

Thu May 8 10:12:49 EDT 2014

I don't have a strong opinion on whether encryption would be useful or 
not. Uservoice does show it as a highly requested feature though.

So I will just add another way of looking at it - the gnucash internals 
one.

Let me start from a very rough mid-term to long-term roadmap for 
GnuCash:

1. convert the engine code into c++. The goal here is to get a clean 
object oriented core that makes it feasible to work with object 
persistence.

2. Use a strong object persistence model for all user data.

Object persistence is a fancy word for making sure your changes aren't 
lost. Our current system loads everything into memory and writes changes 
back to a file upon save (xml) or directly per change (sql backends). In 
both cases the main data to work on is completely in memory.

A major goal for GnuCash is to get rid completely of this model. The 
most realistic way to do this is to drop the xml file format completely 
in favour of database backed data stores. Xml will probably remain as 
import/export format though but internally GnuCash will always work 
directly with a database for all the user data.

So the question you should answer for yourself is if you are willing to 
spend the effort of introducing encryption for xml files if that format 
will eventually become obsolete.

Elements that will influence the answer are
- the effort it would take to add the encryption support
- how long the xml backend will still be there. Unfortunately there is 
no hard timing for that yet. If strong object persistence makes it into 
2.8 xml will become secondary in roughly 3-4 years otherwise more likely 
6-8.

And it may still be useful to be able to encrypt export files in xml 
although that less likely to be useful.

These are just meant as data points to help you estimate if the effort 
is worth it.

Geert

On Wednesday 07 May 2014 17:06:13 Michalis Kamprianis wrote:
> 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.h
> > tml
> > 
> > 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel