Suggestion Encrypted Attribute/Express Values option

Permalink
Now I know I can encrypt something with Sodium and store the value in an attribute without problem (or at least I expect I should be able to) but when a user registers and you ask for e.g. firstname, lastname lin the registration page you have no control, seemingly, over not storing those values as plaintext in the DB.

Not so much an issue for John Smith but if you had a name like Humpadoo Swashbuckler you'd likely be the only one in the country and so that would be personally identifiable information and as such should be encrypted for best practice. Likewise for Express data. Possibly also the user's email address, too, should not be stored plaintext?

It would seem very useful to have an attribute option of 'Encrypted yes/no' along with other properties like placeholder, etc. This obviously also implies being able to select a sitewide encryption method, even if just for this type of data. With PHP 7.2 Sodium is built-in by default.

Currently I tend to use a separate DB of encrypted assets but it's easy to see how encrypted attributes would be extremely useful and also enhance C5's utility in various industries. In my case this need has arisen from apps being sold into the medical/patient sector where privacy is paramount.

surefyre
 
A3020 replied on at Permalink Reply
A3020
This has major implications for SQL searches and column length (and possibly type). Do you have any experience how to tackle those issues?
surefyre replied on at Permalink Reply
surefyre
Beyond fetching all encrypted records and decrypting in memory to search, no. I should imagine you'd have to forego searchability for encryption. I've never found an answer to searching encrypted data.

I suppose you could have a sandboxed, encrypted silo of some sort that you API into with search terms and then the silo (continaing protected in-memory decrypted data somehow) would return you IDs of resources matching your search that you could cherrypick from a DB and then decrypt a small subset of data you knew matched your criteria but that's well beyond the scope of simply encrypting data so that it's largely safe if ever 'lost' or copied, not to mention beyond the scope of what would be built-in to C5 as a feature.

For some searchability what I tend to do is duplicate some encrypted object values that are anonymous, e.g. IDs of other DB data like country, email preferences, into DB columns so at least they can be searched on and are meaningless without the encrypted data itself for identification purposes. I tend to write whole profile records as encrypted data structures into BLOBS, so this helps with narrowing subsets down with minimum overhead.