|pypi| |actions| |codecov| |downloads| |maintainability| |black|
django-crypto-fields
--------------------
+-------------------------+----------------+---------------+----------+-----------+
| Version | Python | Django | DB | Cache |
+=========================+================+===============+==========+===========+
| < 0.3.7 | 3.8, 3.9, 3.10 | 3.2, 4.0, 4.1 | mysql | N/A |
+-------------------------+----------------+---------------+----------+-----------+
| 0.3.8 - 0.3.9 | 3.11+ | 4.2+ | mysql | N/A |
+-------------------------+----------------+---------------+----------+-----------+
| 0.4.0 - 0.4.1 | 3.11+ | 4.2+ | mysql | cache |
| | | | | framework |
+-------------------------+----------------+---------------+----------+-----------+
| 0.4.2+ | 3.11+ | 4.2+ | mysql | cache |
| | | | postgres | framework |
+-------------------------+----------------+---------------+----------+-----------+
* Uses ``pycryptodomex``
Add encrypted field classes to your Django models where ``unique=True`` and ``unique_together`` attributes work as expected.
For example:
.. code-block:: python
from django.db import models
from django_crypto_fields.fields import EncryptedTextField, FirstnameField, IdentityField
class PatientModel (models.Model):
first_name = FirstnameField(
verbose_name="First Name")
identity = IdentityField(
verbose_name="Identity",
unique=True)
comment = EncryptedTextField(
max_length=500)
Installation
============
add to INSTALLED_APPS:
.. code-block:: python
INSTALLED_APPS = (
...
'django_crypto_fields.apps.AppConfig',
...
)
Add DJANGO_CRYPTO_FIELDS_KEY_PATH to the folder in settings:
.. code-block:: python
# folder where the encryption keys are stored
# Do not set for tests
DJANGO_CRYPTO_FIELDS_KEY_PATH = '/etc/myproject/django_crypto_fields')
Add KEY_PREFIX (optional, the default is "user"):
.. code-block:: python
# optional filename prefix for encryption keys files:
KEY_PREFIX = 'bhp066'
Run ``migrate`` to create the ``django_crypto_fields.crypt`` table:
.. code-block:: python
python manage.py migrate django_crypto_fields
Encryption keys
===============
Take care of the encryption keys!
In your tests you can set ``settings.DEBUG = True`` and ``settings.AUTO_CREATE_KEYS = True`` so that keys are generated for your tests. Encryption keys will not automatically generate on a production system (``DEBUG=False``) unless ``settings.AUTO_CREATE_KEYS = True``.
By default assumes your test module is ``runtests.py``. You can changes this by setting ``settings.DJANGO_CRYPTO_FIELDS_TEST_MODULE``.
When are encryption keys loaded?
================================
The encryption keys are loaded as a side effect of accessing the ``keys`` module.
The keys module is imported in this apps AppConfig just before ``import_models``.
During runtime the encryption keys are stored in the ``encryption_keys`` global.
See module ``apps.py``, module ``keys.py`` and ``fields.BaseField`` constructor.
History
=======
``django-crypto-fields`` has been used in our audited research projects that use our "Edc" for data collection and management. Data collected in our Edc are considered "source documents". ``django-crypto-field`` adds field level encryption for sensitive field values such as names, identifiers, dob, etc (PII). Authorized study personnel accessing the data through the application can see PII. Downstream data management staff and statisticians accessing the database directly cannot.
Features
========
* All values are stored as a pair of hash (``hashlib.pbkdf2_hmac``) and secret (``rsa`` or ``aes``);
* A model using a ``django-crypto-fields`` field class stores the hash only;
* A separate table relates the hash to it's secret and is referenced internally by the field class;
Advantages
==========
- Automatically creates encryption key sets (RSA, AES and salt) and stores them in the ``KEY_PATH`` folder;
- Supports unique constraints and compound constraints that including encrypted fields. The hash is stored in the model's db_table and not the secret. The ``unique=True`` and ``unique_together`` attributes work as expected;
- The dataset is de-identified at rest. This has many advantages but helps us work well with our analysis team. The data analysis team do not need to see PII. They just want a de-identified dataset. A de-identified dataset is one where PII fields are encrypted and others not. With the RSA keys removed, the dataset is effectively de-identified;
- Datasets from other systems with shared PII values, such as identity numbers, can be prepared for meta-analysis using the same keys and algorithms;
- The dataset can be permanently obscured by dropping the ``Crypt`` table from the DB (it has all the secrets);
- By default field classes exist for two sets of keys. You can customize ``KEY_FILENAMES`` to create as many sets as needed. With multiple sets of keys you have more control over who gets to see what.
Disadvantages
=============
- Limited support for lookup types. The "query value" is the hash not the decrypted secret, so Django lookups like ``['startswith', 'istartswith', 'endswith', 'iendswith', 'contains', 'icontains', 'iexact']`` are not supported.
- Hashing with a secret may be considered less secure than just a "secret". You decide what your requirements are. For systems that collect PII in fields classes from ``django-crypto-fields``, we take all the basic security precautions: OS and application-level password protection, Full-Drive encryption, physical security and so on.
Other encrypted field modules are available if you just want to use encrypted field classes in Django models and do not need unique constraints nor plan to join tables on encrypted fields for analysis.
Contribute
==========
- Issue Tracker: github.com/erikvw/django-crypto-fields/issues
- Source Code: github.com/erikvw/django-crypto-fields
.. |pypi| image:: https://img.shields.io/pypi/v/django-crypto-fields.svg
:target: https://pypi.python.org/pypi/django-crypto-fields
.. |actions| image:: https://github.com/erikvw/django-crypto-fields/actions/workflows/build.yml/badge.svg
:target: https://github.com/erikvw/django-crypto-fields/actions/workflows/build.yml
.. |codecov| image:: https://codecov.io/gh/erikvw/django-crypto-fields/branch/develop/graph/badge.svg
:target: https://codecov.io/gh/erikvw/django-crypto-fields
.. |downloads| image:: https://pepy.tech/badge/django-crypto-fields
:target: https://pepy.tech/project/django-crypto-fields
.. |maintainability| image:: https://api.codeclimate.com/v1/badges/34293a3ec19da8d7fb16/maintainability
:target: https://codeclimate.com/github/erikvw/django-crypto-fields/maintainability
:alt: Maintainability
.. |black| image:: https://img.shields.io/badge/code%20style-black-000000.svg
:target: https://github.com/ambv/black
:alt: Code Style
Raw data
{
"_id": null,
"home_page": "http://github.com/erikvw/django-crypto-fields",
"name": "django-crypto-fields",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.11",
"maintainer_email": null,
"keywords": "django Edc fields encryption security",
"author": "Erik van Widenfelt",
"author_email": "ew2789@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/64/10/8a599631d12d7803bea4b023cd2916277a6b04c1adae2478c0aa3ebfab6f/django_crypto_fields-0.4.2.tar.gz",
"platform": null,
"description": "|pypi| |actions| |codecov| |downloads| |maintainability| |black|\n\ndjango-crypto-fields\n--------------------\n\n+-------------------------+----------------+---------------+----------+-----------+\n| Version | Python | Django | DB | Cache |\n+=========================+================+===============+==========+===========+\n| < 0.3.7 | 3.8, 3.9, 3.10 | 3.2, 4.0, 4.1 | mysql | N/A |\n+-------------------------+----------------+---------------+----------+-----------+\n| 0.3.8 - 0.3.9 | 3.11+ | 4.2+ | mysql | N/A |\n+-------------------------+----------------+---------------+----------+-----------+\n| 0.4.0 - 0.4.1 | 3.11+ | 4.2+ | mysql | cache |\n| | | | | framework |\n+-------------------------+----------------+---------------+----------+-----------+\n| 0.4.2+ | 3.11+ | 4.2+ | mysql | cache |\n| | | | postgres | framework |\n+-------------------------+----------------+---------------+----------+-----------+\n\n* Uses ``pycryptodomex``\n\nAdd encrypted field classes to your Django models where ``unique=True`` and ``unique_together`` attributes work as expected.\n\n\nFor example:\n\n.. code-block:: python\n\n\n\tfrom django.db import models\n\tfrom django_crypto_fields.fields import EncryptedTextField, FirstnameField, IdentityField\n\n\tclass PatientModel (models.Model):\n\n\t first_name = FirstnameField(\n\t verbose_name=\"First Name\")\n\n\t identity = IdentityField(\n\t verbose_name=\"Identity\",\n\t unique=True)\n\n\t comment = EncryptedTextField(\n\t max_length=500)\n\n\nInstallation\n============\n\nadd to INSTALLED_APPS:\n\n.. code-block:: python\n\n\tINSTALLED_APPS = (\n\t\t...\n\t 'django_crypto_fields.apps.AppConfig',\n\t ...\n\t)\n\nAdd DJANGO_CRYPTO_FIELDS_KEY_PATH to the folder in settings:\n\n.. code-block:: python\n\n # folder where the encryption keys are stored\n # Do not set for tests\n DJANGO_CRYPTO_FIELDS_KEY_PATH = '/etc/myproject/django_crypto_fields')\n\nAdd KEY_PREFIX (optional, the default is \"user\"):\n\n.. code-block:: python\n\n\t# optional filename prefix for encryption keys files:\n\tKEY_PREFIX = 'bhp066'\n\n\nRun ``migrate`` to create the ``django_crypto_fields.crypt`` table:\n\n.. code-block:: python\n\n python manage.py migrate django_crypto_fields\n\n\nEncryption keys\n===============\n\nTake care of the encryption keys!\n\nIn your tests you can set ``settings.DEBUG = True`` and ``settings.AUTO_CREATE_KEYS = True`` so that keys are generated for your tests. Encryption keys will not automatically generate on a production system (``DEBUG=False``) unless ``settings.AUTO_CREATE_KEYS = True``.\n\nBy default assumes your test module is ``runtests.py``. You can changes this by setting ``settings.DJANGO_CRYPTO_FIELDS_TEST_MODULE``.\n\nWhen are encryption keys loaded?\n================================\n\nThe encryption keys are loaded as a side effect of accessing the ``keys`` module.\nThe keys module is imported in this apps AppConfig just before ``import_models``.\nDuring runtime the encryption keys are stored in the ``encryption_keys`` global.\n\nSee module ``apps.py``, module ``keys.py`` and ``fields.BaseField`` constructor.\n\nHistory\n=======\n\n``django-crypto-fields`` has been used in our audited research projects that use our \"Edc\" for data collection and management. Data collected in our Edc are considered \"source documents\". ``django-crypto-field`` adds field level encryption for sensitive field values such as names, identifiers, dob, etc (PII). Authorized study personnel accessing the data through the application can see PII. Downstream data management staff and statisticians accessing the database directly cannot.\n\nFeatures\n========\n\n* All values are stored as a pair of hash (``hashlib.pbkdf2_hmac``) and secret (``rsa`` or ``aes``);\n* A model using a ``django-crypto-fields`` field class stores the hash only;\n* A separate table relates the hash to it's secret and is referenced internally by the field class;\n\nAdvantages\n==========\n\n- Automatically creates encryption key sets (RSA, AES and salt) and stores them in the ``KEY_PATH`` folder;\n- Supports unique constraints and compound constraints that including encrypted fields. The hash is stored in the model's db_table and not the secret. The ``unique=True`` and ``unique_together`` attributes work as expected;\n- The dataset is de-identified at rest. This has many advantages but helps us work well with our analysis team. The data analysis team do not need to see PII. They just want a de-identified dataset. A de-identified dataset is one where PII fields are encrypted and others not. With the RSA keys removed, the dataset is effectively de-identified;\n- Datasets from other systems with shared PII values, such as identity numbers, can be prepared for meta-analysis using the same keys and algorithms;\n- The dataset can be permanently obscured by dropping the ``Crypt`` table from the DB (it has all the secrets);\n- By default field classes exist for two sets of keys. You can customize ``KEY_FILENAMES`` to create as many sets as needed. With multiple sets of keys you have more control over who gets to see what.\n\nDisadvantages\n=============\n\n- Limited support for lookup types. The \"query value\" is the hash not the decrypted secret, so Django lookups like ``['startswith', 'istartswith', 'endswith', 'iendswith', 'contains', 'icontains', 'iexact']`` are not supported.\n- Hashing with a secret may be considered less secure than just a \"secret\". You decide what your requirements are. For systems that collect PII in fields classes from ``django-crypto-fields``, we take all the basic security precautions: OS and application-level password protection, Full-Drive encryption, physical security and so on.\n\nOther encrypted field modules are available if you just want to use encrypted field classes in Django models and do not need unique constraints nor plan to join tables on encrypted fields for analysis.\n\nContribute\n==========\n\n- Issue Tracker: github.com/erikvw/django-crypto-fields/issues\n- Source Code: github.com/erikvw/django-crypto-fields\n\n.. |pypi| image:: https://img.shields.io/pypi/v/django-crypto-fields.svg\n :target: https://pypi.python.org/pypi/django-crypto-fields\n\n.. |actions| image:: https://github.com/erikvw/django-crypto-fields/actions/workflows/build.yml/badge.svg\n :target: https://github.com/erikvw/django-crypto-fields/actions/workflows/build.yml\n\n.. |codecov| image:: https://codecov.io/gh/erikvw/django-crypto-fields/branch/develop/graph/badge.svg\n :target: https://codecov.io/gh/erikvw/django-crypto-fields\n\n.. |downloads| image:: https://pepy.tech/badge/django-crypto-fields\n :target: https://pepy.tech/project/django-crypto-fields\n\n.. |maintainability| image:: https://api.codeclimate.com/v1/badges/34293a3ec19da8d7fb16/maintainability\n :target: https://codeclimate.com/github/erikvw/django-crypto-fields/maintainability\n :alt: Maintainability\n\n.. |black| image:: https://img.shields.io/badge/code%20style-black-000000.svg\n :target: https://github.com/ambv/black\n :alt: Code Style\n\n",
"bugtrack_url": null,
"license": "GPL license, see LICENSE",
"summary": "Add encrypted field classes and more to your Django models.",
"version": "0.4.2",
"project_urls": {
"Homepage": "http://github.com/erikvw/django-crypto-fields"
},
"split_keywords": [
"django",
"edc",
"fields",
"encryption",
"security"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "f46b3283639dcc49554082b5839375302e5ff6d72c06ee8ae25d0cbc79056fbb",
"md5": "d27e8188f9490338025e72f80743314a",
"sha256": "99e6f728d47d79ef04f62f2f6743727958777a757c127f2bb64734f7585a7ddc"
},
"downloads": -1,
"filename": "django_crypto_fields-0.4.2-py3-none-any.whl",
"has_sig": false,
"md5_digest": "d27e8188f9490338025e72f80743314a",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.11",
"size": 63406,
"upload_time": "2024-08-15T15:15:17",
"upload_time_iso_8601": "2024-08-15T15:15:17.054742Z",
"url": "https://files.pythonhosted.org/packages/f4/6b/3283639dcc49554082b5839375302e5ff6d72c06ee8ae25d0cbc79056fbb/django_crypto_fields-0.4.2-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "64108a599631d12d7803bea4b023cd2916277a6b04c1adae2478c0aa3ebfab6f",
"md5": "ad9bb1607b0ca7231b0b2b54fa14b416",
"sha256": "95a2dcff6ce15c2efab24b209d31cb996445cbdfeb6029b60fcd089202c8e92a"
},
"downloads": -1,
"filename": "django_crypto_fields-0.4.2.tar.gz",
"has_sig": false,
"md5_digest": "ad9bb1607b0ca7231b0b2b54fa14b416",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.11",
"size": 48826,
"upload_time": "2024-08-15T15:15:18",
"upload_time_iso_8601": "2024-08-15T15:15:18.561880Z",
"url": "https://files.pythonhosted.org/packages/64/10/8a599631d12d7803bea4b023cd2916277a6b04c1adae2478c0aa3ebfab6f/django_crypto_fields-0.4.2.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-08-15 15:15:18",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "erikvw",
"github_project": "django-crypto-fields",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"lcname": "django-crypto-fields"
}
JSON
