4 ms·
This doesn't seem to be the right way to handle keys for bulk data at rest, even assuming you were doing it to enforce patient approval. A password wouldn't be
by jfyi 3y ago
This doesn't seem to be the right way to handle keys for bulk data at rest, even assuming you were doing it to enforce patient approval.
A password wouldn't be appropriate for direct use as an encryption key. So I guess you could hash the password and use that for the key for data encryption and then hash it again and store the second hash for authentication. Salting appropriately of course.
That feels weird to me, I wouldn't trust I saw every angle on that. Regardless, it would drastically lower the entropy of the key space that way unless you have downright draconian password requirements.
How did you implement this in the POC you spoke of?
- specialist 3y agoI think I crossed some wires here, confusing encryption key with database (uuid) key. Let me try again. Very briefly, a proper password store must not use plaintext. Rather it must use ( password + salt ) * hash. Similarly, PII (name, MRN, etc) must also be salted and hashed. What Translucent Databases adds is showing how to cleverly use those hashed values for common use cases. Like how to use hashed MRNs as indexes (keys) to other data such as lab results. It takes some getting acquainted, but designing schemas will start being intuitive after a bit.
- jfyi 3y agoI am trying to figure out how hashes being used as indices and password storage has anything to do with the storage and encryption of bulk data at rest. Can you elaborate? Edit: I see you aren't actually encrypting it. So you are as the post said, just throwing away the keys (in a sense). You are talking about storing and indexing metadata.
- specialist 3y agoTranslucent Databases applies the design of a properly implemented password store to additional use cases. Such as hiding PII. Sensitive data (passwords, PII) is absolutely encrypted. I apologize for assuming everyone here knows how passwords should be stored. My reference to "hash" is shorthand for "secure one-way hash". Please refer to the Translucent Databases book for any further questions you may have.
- jfyi 3y agoI was also pointing out hashing is not encrypting. They are not the same thing. You don't "encrypt" passwords by hashing. This is probably why your wires were crossed. It's just terminology, I get what you are saying though. You can read here https://www.google.com/search?q=hashing+vs+encrypting https://www.google.com/search?q=hashing+vs+encrypting to further understand.