The problem is that this would make the database entirely inaccessible unless you have access to the password. That creates quite a lot of friction in the user experience, the user would have to provide his password on every interaction (ie not just when logging in).
We're basically just discussing end-to-end encryption.
The real reason it's not done more often is that it makes things a lot of things way more complicated from a development perspective. Features like "allow users to send messages to each other" that would normally be really simple to implement suddenly require a whole public key infrastructure and logic to take into account edge cases like "What if the user got a new phone or changed their password and was offline when the message was sent?", or onerous threat models like "What if the server is controlled by an attacker when I sign-in?"
All of those problems are solvable, but "simply" is hardly the word I'd use to describe designing a secure end-to-end encrypted application. It's way, way more development effort than just "hash user passwords with bcrypt and don't allow access without the password", which is why it's rarely done unless E2E encryption is a major selling point of the application.
Yes, you could symmetrically encrypt the tiny portion of personal data that needs to be read solely by you without much added complexity.
However, with few exceptions (password managers, backups, personal notes, etc), the whole point of uploading data to an online service is to allow it to be shared with other people or services. Once that happens, you need all those complicated key management and security systems I just talked about. It's effectively end-to-end encryption.
Also, I'm not sure this is an actual breach. I think they accidentally published the data themselves, that's the vibe I'm getting from reading between the lines. It's like the code maybe missed checking a flag that would exclude private records from showing.
Private key cryptography would be better, maybe encrypt a private key with a password and store that along with the public?
We can't determine what their password is based on the hash alone, which is why we couldn't hash all the user data in the DB with their password and store that.
The idea behind crypto shredding is that you have a cryptographic key for each entity in your system and you use that key encrypt all fields for a given record. When it comes time to delete that data, you simply discard the key used to encrypt it. Assuming you've used reasonably good cryptography, this data is now effectively gone.
This is useful in cases where:
* You need to support the right to be forgotten (as defined in the CCPA[2] or GDPR[3]), since all you need to do to "delete" a user's data is to delete the key used to encrypt.
* The data you need to delete exists across multiple data stores/applications/environments and ensuring consistency for the deletion across all these places is difficult. For example: You may have DB backups, long-lived caches, or 3rd party services/vendors that may have copies of this data.
* You want to discard some, but not all, of a user's data. This is important in cases you're required by law to retain specific kinds of information even after a person has required it's deletion. For example, banking and finance companies are required to keep specific records about who they sent money to or performed services for.
1. https://en.wikipedia.org/wiki/Crypto-shredding
2. https://www.oag.ca.gov/privacy/ccpa
3. https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
That method wouldn't stop a determined 12 year old, let alone a competent attacker. Please use a properly engineered and implemented encryption instead of coming up with harebrained schemes.
Most systems will restore access for a user who forgot their password.