Determine utility of encrypted DB fields

[brassy-endomorph]

We need a threat model to determine whether row-level security like following makes sense

hushline/app.py

Lines 223 to 229 in 2c89aa6

	@property
	def email(self):
	return decrypt_field(self._email)
	@email.setter
	def email(self, value):
	self._email = encrypt_field(value)

My general suspicion is that the model we come up with will not have a meaningful increase in security by this feature and it only adds complexity. We likely want to significantly harden the database and server against exfiltration before we add this in. The app is the only thing interacting with the DB, and RCE is most likely to happen in the app itself (which has access to the decryption keys).

Blocked by #265

[glenn-sorrentino]

Closing, as this encryption hasn't caused any issues, and we want to encrypt everything. A ticket for hardening the server against exfil should be created if this is a priority, but at-rest encryption is something I want to keep and use as broadly as possible.

[brassy-endomorph]

If you want DB encryption (beyond the drive's FDE), then we likely want to encrypt the whole database. I think this needs to remain open. "Hasn't caused problems yet" isn't sufficient reason to keep this, and the main threat of exfil will be the application process / user itself being compromised in which case it can just read the entire database, env vars, and config itself.

[rmlibre]

Encrypting the whole database is a good idea. It's also a good idea to encrypt fields that hold secrets. That way they don't linger around in RAM for longer than needed. Regardless of the practicality of attacks, it's best practice to wipe secrets & key material from memory ASAP.