Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transparent field level encryption for Django with pgcrypto PostgreSQL extension

github.com

Post reply on HN
Print view View original

11–13 of 13 posts

Re: Transparent field level encryption for Django with pgcrypto PostgreSQL extension

#11

Post by thewataccount »

ttfkam wrote: post #2

I love pgcrypto and Postgres in general. In this case, I'm wondering why you'd perform such widespread encryption on a per-column basis. If there is that much to be encrypted, there's whole-disk encryption at rest. For network transport there's TLS. Many column-level encryptions/decryptions would seem to me to put an undo CPU load on the database instance(s) when that load could be spread horizontally more easily at…

These are django fields, so you would only use them for your "sensitive columns" like payment information, emails, other rarely used stuff.

I checked the readme and I might have missed it but this doesn't seem to be suggesting you replace every column with these, these are just helpers to make encrypting specific columns easier.

Because it's rarely used columns, or columns you'd need to wait for an external api anyway (email, sms, payment, etc) the performance impact should be minimal. You wouldn't need these fields to be indexed.

The attack surfaces this addresses is the compromise of postgres or it's host, or miss handled backups. Preferably you'd be using this on top of full-disk encryption.

EDIT: The use of PGP is weird to me though, why not AES?

Re: Transparent field level encryption for Django with pgcrypto PostgreSQL extension

#12

Post by melx »

VWWHFSfQ wrote: post #6

Looks old and doesn't support a recent version of Django

The company behind this project no longer exists.

I know as I worked there a decade ago :-)

It's OSS - send a PR for "recent version of Django", someone may even merge into upstream.

Re: Transparent field level encryption for Django with pgcrypto PostgreSQL extension

#13

Post by yowlingcat »

BiteCode_dev wrote: post #3
ttfkam wrote: post #2

I love pgcrypto and Postgres in general. In this case, I'm wondering why you'd perform such widespread encryption on a per-column basis. If there is that much to be encrypted, there's whole-disk encryption at rest. For network transport there's TLS. Many column-level encryptions/decryptions would seem to me to put an undo CPU load on the database instance(s) when that load could be spread horizontally more easily at…

So that people handling the servers are not tempted to look at them, so that backup don't contain them in clear text, so that export must explicitly chose to decrypt them or not, etc.

Great callouts. It's about ergonomics, making default actions more safe, and reducing unsafe surface area even if it can't be fully removed.
Post reply on HN