You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current docs include a usage example which suggests hashing the email field with SHA256 along with a fully encrypted (secure symmetric cipher) version of the field.
By including the SHA256 version of the data, the encryption is rendered virtually useless as the same data is now also stored in the data-base on a much weaker scheme. Storing sensitive data in this way is not secure due to the below reasons and should be removed from the docs:
SHA256 is a public algorithm (i.e. requires no key) so anyone can compute the hash of any email address. This would make brute force attacks to effectively decrypt email addresses encrypted in this way very simple
Deteministic encryption (where the same output ciphertext is generated for a give plaintext and key every time) is vulnerable to inference and chosen-plaintext attacks. Put simply, if an attacker learns the result of SHA256(foo@example.com) then they can use that knowledge to find any other records in the database that correlate with that email address
These weaknesses may be acceptable for a given application but I think the reader should be warned if you decide to include that example in the docs. And at the very least, SHA256 should be replaced by HMAC with a key known only to the application owner.
The text was updated successfully, but these errors were encountered:
The current docs include a usage example which suggests hashing the email field with SHA256 along with a fully encrypted (secure symmetric cipher) version of the field.
By including the SHA256 version of the data, the encryption is rendered virtually useless as the same data is now also stored in the data-base on a much weaker scheme. Storing sensitive data in this way is not secure due to the below reasons and should be removed from the docs:
SHA256(foo@example.com)
then they can use that knowledge to find any other records in the database that correlate with that email addressThese weaknesses may be acceptable for a given application but I think the reader should be warned if you decide to include that example in the docs. And at the very least, SHA256 should be replaced by HMAC with a key known only to the application owner.
The text was updated successfully, but these errors were encountered: