sqlite3 database encrytion for Django.
agaje...@atompower.com
Malcolm MacKinnon
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/18ffcee8-3ff1-4202-9143-cd446bc424cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Antonis Christofides
Hi,
That's interesting. May I ask why you want to do this?
Regards,
A.
Antonis Christofides http://djangodeployment.com
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
Tim Chase
would it suffice to have an encrypted partition and put your database
on that partition? I configure my FreeBSD servers to be ZFS-on-GELI so
in the event the power goes out or the machine is rebooted, the
contents are unavailable until I enter the password on the console.
-tkc
Melvyn Sopacua
Unfortunately, that doesn't prevent theft at runtime, which is the primary case for encrypting "documents". I used to do something like this with svn passwords, using a file-backed mdconfig store and geli.
--
Melvyn Sopacua
Antonis Christofides
Unfortunately, that doesn't prevent theft at runtime, which is the primary case for encrypting "documents". I used to do something like this with svn passwords, using a file-backed mdconfig store and geli.
But during runtime, Django has access to the unencrypted database (otherwise it wouldn't be able to work). So any attacker who has managed to compromise Django will have access to the database. Could you describe a use case where the encryption would actually prevent someone from reading the database?
Antonis Christofides http://djangodeployment.com
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3670040.JhOgCCftKx%40devstation.
Melvyn Sopacua
On Monday 08 May 2017 17:35:59 Antonis Christofides wrote:
> > Unfortunately, that doesn't prevent theft at runtime, which is the
> > primary case for encrypting "documents". I used to do something
> > like this with svn passwords, using a file-backed mdconfig store
> > and geli.
>
> But during runtime, Django has access to the unencrypted database
> (otherwise it wouldn't be able to work). So any attacker who has
> managed to compromise Django
You assume Django is compromised. I don't. Could be the webserver. Could be some other application that exposes the file.
Another use case for encrypting the sqlite database is that it doesn't have authentication, so you cannot pass on login credentials to the database like you do with a "real" database system. This is one way for embedded systems to personalize devices without having to manage another server component.
With IoT security being under a microscope these days, I can see the potential. And from experience, Django runs fine on a Raspberry Pi and is an easy way to provide a user interface that is accessible from anywhere.
--
Melvyn Sopacua
Antonis Christofides
Assume Django is running as user 'django' and the db is "db.sqlite3".
If you "chown django db.sqlite3" and "chmod 600 db.sqlite3", only user django can access it.
What would you gain by encrypting it?
Antonis Christofides http://djangodeployment.com
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/27229024.NH8PPNG8h5%40devstation.
Melvyn Sopacua
On Monday 08 May 2017 18:29:35 Antonis Christofides wrote:
> Assume Django is running as user 'django' and the db is "db.sqlite3".
>
> If you "chown django db.sqlite3" and "chmod 600 db.sqlite3", only user
> django can access it.
>
> What would you gain by encrypting it?
Three things:
1) If the file gets deleted, Django does not recreate it with that mode. Solvable by using a dedicated directory instead of the above.
2) root can't do anything with it nor can daemons that are compromised before switching to unprivileged user.
3) Additional layer in case martians invade earth and other things that should not happen. Not uncommon in high-security environments to defend against the unknown. See for example the requirements FIPS-140 places on access to cryptographic keys, even though we all put them in a directory mode 500 owned by root.
But I feel we're going off-topic now.
--
Melvyn Sopacua
Tim Chase
> > What would you gain by encrypting it?
>
> Three things:
> 1) If the file gets deleted, Django does not recreate it with that
> mode. Solvable by using a dedicated directory instead of the above.
deleting your database, the permissions upon recreation would be the
least of my worries. ;-)
> 2) root can't do anything with it nor can daemons that are
> compromised before switching to unprivileged user.
$ su -
Password:
root@laptop:~# sqlite3 test.db
SQLite version 3.8.7.1 2014-10-29 13:59:56
Enter ".help" for usage hints.
sqlite> create table example (id int);
sqlite> insert into example values (42);
sqlite> select * from example;
42
sqlite>
root@laptop:~# chown tim:tim test.db
root@laptop:~# chmod 600 test.db
root@laptop:~# ls -lsF test.db
4 -rw------- 1 tim tim 2048 May 8 12:33 test.db
root@laptop:~# sqlite3 test.db
SQLite version 3.8.7.1 2014-10-29 13:59:56
Enter ".help" for usage hints.
sqlite> select * from example;
42
sqlite> delete from example;
sqlite>
and root seems (unsurprisingly) able to do anything desired with the
database.
> 3) Additional layer in case martians invade earth and other things
> that should not happen. Not uncommon in high-security environments
> to defend against the unknown. See for example the requirements
available to the Django process to be able to decrypt the values.
Theoretically, one could load the keys off a removable device into a
single Django process, then unmount/remove the external device. But
if you have Django processes spinning up with load increase, you'd
have to have the keys available to them.
Otherwise, as a recent "whoops, I deleted my source code, so I
salvaged it from the process that was currently running that code"
article[1] suggests, one can also attach to a running process that
would grant access to the decrypting keys in memory, even if the
theoretical external device has been removed.
Security is hard. :-)
> But I feel we're going off-topic now.
-tkc
[1] https://gist.github.com/simonw/8aa492e59265c1a021f5c5618f9e6b12
Antonis Christofides
> database.
encrypted. But, again, the question is whether root would have access to the
encryption keys. If the django user has access to the encryption keys, root also
does.
What I'm getting at is that the benefits of encrypting the database are
questionable. Maybe there is some edge case in which it would be useful. I am no
security specialist, but the thing is, unless you are a security specialist and
really know what you are doing, encrypting your database would probably not
achieve much, or it might even make things worse.
Antonis Christofides
http://djangodeployment.com
Melvyn Sopacua
On Tuesday 09 May 2017 09:24:08 Antonis Christofides wrote:
> > and root seems (unsurprisingly) able to do anything desired with the
> > database.
>
> He meant that root wouldn't be able to read the database if the
> database was encrypted. But, again, the question is whether root
> would have access to the encryption keys. If the django user has
> access to the encryption keys, root also does.
Defending against a targetted attack is extremely hard. It's also a minute percentage of the attacks out there. A site may never see one as it's simply not worth the effort.
By putting the encryption keys on a networked resource, you defend against exploits that make everything they can see world-readable (which will go unnoticed far more then it should and can have great pay outs). Or for example a compromised ftp daemon that can now hand you the file it normally wouldn't.
The vast majority of security attacks are wide scans for known failures, which try to create as much yield as possible with the least ammount of detection. This is because it takes time to follow-up on the success of the hack.
For example, I've dealt with an exploit that infected all files with a redirect - but - only when viewed on a mobile device. Not because it wanted to infect mobile devices, but simply because it would go unnoticed much longer, especially by the people that work with it daily.
> What I'm getting at is that the benefits of encrypting the database
> are questionable.
That can be said about any encryption, as everything can be decrypted given enough time and resources - a fact that not enough people say out loud. The assumption is that at the time it is decrypted the information is no longer relevant.
> Maybe there is some edge case in which it would be
> useful.
It's useful for the majority of cases. Every hurdle - every deviation from the defaults or commonly used conventions helps against those wide-targgetted scanners. Just look at your webserver logs how many of those fail just because you didn't make phpMyAdmin available in one of the common aliases. And think how many succeed because they run vanilla Ubuntu and never actually made an effort to think about this stuff.
Now, there's even a totally different use case. Say, I want make answers to exams available, but only after the exam. Using time-lapse cryptography, I can make the answers only available after a certain time :).
Anyway - there's enough food for thought in here, so I'm out, unless the OP explains his use case and needs more help.
--
Melvyn Sopacua