3 ms·
What kind of data you usually manually encrypt? Except tokens and api keys I have never went further. Encrypting anything else would make the app much less effi
by h1fra 3y ago
What kind of data you usually manually encrypt? Except tokens and api keys I have never went further. Encrypting anything else would make the app much less efficient imo
- cowl 3y agoIt depends on use case but for example in EU a lot of PII needs to be encrypted for the medical/pharmaceutical Services. Of course health data needs to be encrypted as well as financial data etc.
- speedgoose 3y agoI encrypted healthcare data at a previous job. It was indeed making the app much less efficient. Each health institute had their private keys. I considered to have keypairs per user, but it would have been a bit too much work but more neat. The indexes were a challenge. I was using some argon2d key derivation algorithm to hash the values to use in some indexes. For example if you want to get all the records with the value "toto" in a field, you derive toto (with some common salt), and then you can look in the index all the documents that have the same derived value. It did leaks some information and some values couldn't be indexed like this because that would leak too much. So sometimes, we had to fetch all the documents from the database and filter on the application level. We also sometimes didn't encrypt the datetimes so we could do efficient queries on specific time ranges. To be honest, I did that mostly for fun. I know that some people are content with the managed encryption from their favourite cloud provider.
- definitelyauser 3y agoHealth data primarily. You aim to encrypt the fields you can, without hampering usability too much. Anything you need to be able to search for (name, ssn) to find patients, or filter on for reports, is generally plaintext. More sensitive things such as "that patient has aids" you'll have to decide if you want to encrypt it, or do a massive select from the DB anytime you need statistics on it. (Or better yet, encrypt it, but store an anonymized tracker elsewhere. But this is less useful for cureable diseases)
- h1fra 3y agooh I forgot about that indeed. I guess the proposed solution in the article would not even be useful since a filtering on a encrypted boolean would not work and there is no way to "hide" this value. Is it okay if everything is plaintext but the name? In that case you have a row of sensitive data without anything to link to the actual patient if it leaks.
- e12e 3y agoSometimes the fact that someone is a patient is sensitive. Eg an abortion clinic.
- paulddraper 3y ago* API keys * Health data * Financial data
- e12e 3y agoUnion membership status Ethnicity Sexual orientation Political party affiliation
- paulddraper 3y agoUsually not. AFAIK no special security risks or regulatory requirements/penalties like for the other data.
- e12e 3y agohttps://gdpr-info.eu/art-9-gdpr/ https://gdpr-info.eu/art-9-gdpr/ > Art. 9 GDPR Processing of special categories of personal data > Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited.
- speedgoose 3y agoIt’s not very much related to encryption.
- e12e 3y agoWhat is considered: "special categories of personal data" is related to how such data is handled. Encryption is one tool for protecting data - it's not immediately obvious that encryption is always a useful tool.