Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypt secrets in DB #96

Open
vilda opened this issue May 26, 2015 · 7 comments
Open

Encrypt secrets in DB #96

vilda opened this issue May 26, 2015 · 7 comments

Comments

@vilda
Copy link

vilda commented May 26, 2015

A good practice is to encrypt or hash secret keys in DB. I would suggest to implement this. (Enhancement)

While for one-off keys one way hash functions such as scrypt/bcrypt are available, that's not the option for TOTP where the actual key value is needed. Simple encryption where the encryption key is not stored in DB suffice.

Encryption of secret keys is recommended by RFC 6238.

@Bouke
Copy link
Collaborator

Bouke commented May 29, 2015

The relevant part in the specification is the following:

We also RECOMMEND storing the keys securely in the validation system,
and, more specifically, encrypting them using tamper-resistant
hardware encryption and exposing them only when required: for
example, the key is decrypted when needed to verify an OTP value, and
re-encrypted immediately to limit exposure in the RAM to a short
period of time.

The key store MUST be in a secure area, to avoid, as much as
possible, direct attack on the validation system and secrets
database. Particularly, access to the key material should be limited
to programs and processes required by the validation system only.

Hardware encryption cannot be enforced by this package, but the encryption could be implemented.

@Bouke
Copy link
Collaborator

Bouke commented Jul 29, 2017

A possible package to perform the encryption would be: https://github.com/pyca/cryptography.

@wkschwartz
Copy link

Another possible package: https://github.com/defrex/django-encrypted-fields

@Bouke
Copy link
Collaborator

Bouke commented Aug 25, 2017

I've looked into this and the issue is that this package only stores the PhoneDevice, but not the other Devices, most notably the TOTPDevice. So while we could encrypt some of the fields, we still wouldn't cover all situations.

@wkschwartz
Copy link

Perhaps a more thorough solution would involve django_otp adopting database encryption in a way that this package could inherit?

@wkschwartz
Copy link

wkschwartz commented Aug 25, 2017

Incidentally, I should probably take back my recommendation of django-encrypted-fields: it's not Python 3 compatible: defrex/django-encrypted-fields#27

@blubber
Copy link

blubber commented Jan 4, 2018

Encryption doesn't really add any security in this case, unless you have a safe way to store the encryption keys.

One possible solution would be to somehow derive a key from the user's password (you can use Django's pbkdf2 implementation for this, but don't use the stored password hash!) However, looking at django-otp's code this is currently not possible and would be best done in their TOTPDevice implementation.

For now, a better solution is to use a secure store for the keys, something like Vault.

@Bouke Bouke removed the enhancement label Feb 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants