Replying to myself. This being said, going for the application-level encryption
option would prevent you from using SQLite to do some useful things, such as
being able to do a substring search for text in encrypted fields, since
encrypted data is just a black box to it. Typically the application-level
solution is just encrypting a minimum number of fields, such as credit card
numbers or SINs or passwords etc, that wouldn't be searched except for a whole
value match. To use SQLite normally as if it weren't encrypted but with it
actually encrypted, you need the SEE or similar for that. -- Darren Duncan
On 2016-10-08 12:31 AM, Darren Duncan wrote:
So, if you don't want to pay the one-time fee for the SQLite Encryption
Extension et al to get database-level security, your only option really is to
encrypt individual fields at the application level that you want to protect, and
there are various free encryption libraries you can use for that, the specific
options depending on your choice of programming language. But using those has
nothing to do with SQLite specifically, so your answer wouldn't be found on this
SQLite forum, but rather forums for your programming language. -- Darren Duncan
On 2016-10-08 12:18 AM, Damien Sykes-Lindley wrote:
Hi Darren,
You are correct in that genealogy is generally public. However more often than
not the information you want to publish may very well differ from what is in
your private database. You may have private notes telling you what you need to
do. You may have anecdotes shared by many family members that may need to be
kept private, at least until the involved parties are deceased or otherwise
choose to divulge it publicly themselves.
Even more importantly I may choose to add an address-book style feature in there
so you can easily group and contact appropriate family members for whatever
reason (special occasions etc). Of course that will be private.
Password protecting it is also good on many levels - if the database is to be
used online then it is needless to say that authentication would be required for
various people to view it. Even if I decide to make it local only, there is the
possibility that anyone sharing the computer or network may peruse the database
when you don't want them to.
Kind regards,
Damien.
-----Original Message----- From: Darren Duncan
Sent: Saturday, October 08, 2016 6:54 AM
To: SQLite mailing list
Subject: Re: [sqlite] Protecting databases
On 2016-10-07 10:46 PM, Damien Sykes-Lindley wrote:
Hi there,
My name is Damien Lindley, and I am, among other things, an independent,
hobbiest programmer. I have been blind since birth and thus all my computer
work relies on screenreader software and keyboard.
I have only just come through the brink of scripting into compiled programming
and so I guess I am still a beginner in many respects. However I don’t work in
C or C++, so most of my programming, if using a library, relies on precompiled
static or dynamic libraries. Or of course libraries that are written or
converted specifically for the language I work in (FreeBASIC).
Recently, I decided I needed to create a piece of software that could manage
family trees, since there seems to be a lack of screenreader accessible
genealogy managers out there. I was advised the best way to do this is to use
a database engine. I was also informed that SQLite is always a good choice for
databases.
I must admit, I have never worked with databases before and so now I am in the
process of learning SQL. However looking at the programming API for SQLite I
cannot see any means of password protecting the database without either buying
a commercial extension to do this, or recompiling SQLite with the
authentication extension. Due to financial constraints and unfamiliarity with
compiling in C both of these are not an option for me. Also I need a secure
way to do this, as I think I read that the SQLite version simply uses a table
to store the user data, which of course can be read and accessed elsewhere.
Are there any other options available for doing this?
Any help appreciated.
Thanks.
Damien.
Damien,
Why do you need to password protect the database?
Genealogy information is generally of the public record variety so there is
nothing sensitive to protect. I am making genealogy software myself and so am
familiar with many of the relevant issues.
I would say please explain why you think you need password protection for this
project and then the real issue at hand can be addressed.
If yours is a network application and you don't want people on the open internet
from accessing the database, fair enough, but that's an application-level
solution; what you're asking for here is that people who have direct access to
the SQLite database file are blocked by a password, and this I question.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
