Example where personally identifiable information (PII) is not stored in the database

[dylandaviesnl]

I would love to add an epic stack example where PII data is not stored in the database.

At this moment, if there is data breach, it would not leak passwords, but it would leak emails and the name of the user, which is then linked to the notes of the user.

Of course, in this epic stack example, every note is publicly visible, but you could imagine lots of app examples where this is not the case.

I am building an application which stores medical information of the user, which is very private. Of course, it is not hard to make sure that users cannot view data of someone else. Or even that the admin would not be able to. But the real challenge lies in data breaches and insider threats. Also, many data protection regulations and best practices recommend not storing PII data unencrypted in the database.

I wonder if someone already did some prior art here, that I could look at, or if anyone here has ideas how to make the database better suited for this kind of applications.

How to avoid storing any PII data in the database?

• Register and login only with email. And hash both values before storing in the database.
• Email can not be used in the application, but still be used for resetting the password, as when the user wants to reset it, it has to provide an email, which can be checked against the hash.

Now the user can login and change its password, as normal, but any data linked to the user in the database can not be linked to an email anymore, because it is hashed.

For all other data, it needs to be encrypted, with a key, that is unknown to the database (for data breaches), or the application (for insider threats), but is available for the user somehow.

For mobile apps, I think you can just store the encryption key on the device. But for web apps, I don't know what the best practice is.

I thought about deriving an encryption key from the user password on login. And then save that encryption key on the session cookie. However, if the user forgets its password, the encrypted data can never be de-encrypted again.

Another approach, might be to generate an encryption key from the email on login. It might be good enough, as the encrypted data is only available if the user is logged in. And it can only be encrypted if you both know the email, and the way that this email is turned into an encryption key.

I feel that implementing this would be big step forward, but I'm not sure if it follows best practices.

Also there is still the scenario, where an insider threat, knows about the email of a particular user somehow, the key that is used to hash the email, and the way the encryption key is generated from that email. With that knowledge, this insider threat could gain access to all PII data.

[kentcdodds]

This would be a great example. I don't think this is as complicated as you are concerned about. There are industry standard practices around this sort of thing (here's what ChatGPT said about that).

A few things I'll call out about the Epic Stack in particular:

• Fly.io encrypts volumes by default, so if the volume was somehow accessed, the attacker would not be able to access the data. They would need login to the running box (so you'll want to have rigor over who has the ability to do this).
• We use bcrypt for passwords already (which handles salting for us automatically) and you could do the same thing for emails and avoid the issue you brought up with people knowing a user has an account and looking up the hash for their email. This is virtually impossible with a salt.

I definitely don't have the time to put together an example for this myself, but I welcome anyone else to try!