Advise on library for Django model field encryption-at-rest

[pshiu]

We received an inquiry about a choosing a library for encrypting Django model fields at rest.

This issue is to perform this research.

Research

Task

Symmetric encryption in DB of stored OAuth client secrets a Django service uses to contact external services.

Recommendation

Use django-fernet-fields-v2.

Threat vector

• Attack scenario: access to DB but not web server.
  • (If web server pwned, attacker has decryption key.)
  • Non-network attack vectors are probably better treated with DB, not field-level encryption.
• Attack scenario: insider threat.
  • Needs to be paired with ACLs.

Context

• Fernet spec: Spec.md

Alternatives

django-fernet-fields

• [funny] Looks like djfernet may have plagerized django-fernet-fields' docs?
• Docs
• Well-used: 65k downloads/month [compare]
• Abandoned - see: edx/upgrades issue
• Recommendation is djfernet.

djfernet

• Docs
• Uses cryptography library; docs: Fernet (symmetric encryption) — Cryptography 42.0.0.dev1 documentation
• Uses AES-128-CBC [docs], but with PKCS7 padding [cf. recommendations]
• Pro/cons: What is Fernet and when should you use it?
• If using, don’t forget to use FERNET_KEYS. [docs]

pynacl

• Gold standard for encryption libraries & crypto, but no integration with Django.
• There’s a package available django-nacl-fields but nowhere nearly as used as djfernet [stats].

django-aesfield

• Less used: 3k downloads/month vs. 13.3k downloads/month for djfernet [compare: one, two]
• Depends on EnTeQuAk/m2secret, which uses AES-256-CBC [code] and PKCS7 padding [code]
  • …but uses cryptography.hazmat[code]

django-fernet-fields-v2 (:star: Recommendation)

• [surprise] There’s a v2?!
• Much more popular than djfernet: 44k downloads/month vs 13k downloads/month [compare: one, two]
• Already used by edx-enterprise: [GitHub]
• Uses same docs as django-fernet-fields (see project README)

django-fernet-encrypted-fields

• Not as popular as django-fernet-fields-v2 at 3k downloads/month [compare]

AWS Secrets Manager

• Very neat, could use APIs/SDKs, but…
• How costly is the infra setup?
• How to generalize infrastructure? Not everyone uses AWS.

Implementation considerations

• Consider ACL for who is allowed to CRUD the keys.
• Consider defining FERNET_KEYS by default as an empty list.
  • This will default the encryption key to Django’s SECRET_KEY, which is non-ideal. Might be worth a comment.
• Consider adding one-time conversion of existing columns in a custom migration.
• Consider setting Django RunPython()'s reverse_code attribute so the migration is reversible.

Deployment considerations

• Set FERNET_KEYS to a string generated with generate_key() [docs].
  • Not strictly necessary due to HKDF, but easy enough & will cover far-fetched brute force.

[pshiu]

Added research to issue description. Submitting for review.

[feanil]

This looks good to me, I agree with the recommendation. Eventually this can be an ADR to https://github.com/openedx/open-edx-proposals/pull/518

[jmbowman]

Arbi-BOM already started switching things to django-fernet-fields-v2 in order to facilitate the Django 4.2 upgrade: https://github.com/edx/upgrades/issues/215 .

[pshiu]

Next steps:

• [ ] @pshiu create PR with edits to OEP & new ADR to https://github.com/openedx/open-edx-proposals/pull/518

Example of how to make an ADR to an OEP: [example]

Where to add summary of decision in OEP: [GitHub]