Score:0

Server

Best practice for storing personal information on AWS that we shouldn't be able to see

ze234we23

5/15/24, 9:40 AM

We store customer information that we shouldn't have access to, and don't want to inconvenience users by making them lose information if they forget their passwords, is there a good way to solve this problem, so that the devs who have access to our AWS can't read customer data, and so the customers can reset their passwords, without losing access to their data?

1 + 5

security

amazon-s3

amazon-web-services

amazon-kms

HBruijn

5/15/24, 11:10 AM

When technology doesn't provide a solution (access controls and/or encryption of data at rest) the approach is typically that you tell and train your staff to be discrete, do not look intentionally and don't blab when they do get to see something. Enforce with stick and carrot

joeqwerty

5/15/24, 12:04 PM

They might temporarily lose access to their information if they forget their password, but you should implement some type of password recovery/reset process/mechanism. You (or anyone else) should never have access to their passwords. Additionally, you should implement secure data and password storage practices, of which there are numerous guides and information about.

John Mahowald

5/15/24, 12:59 PM

Does there exist an entity other than your organization that should see and work with this data, or is this a case of giving users the option to trust as few other people with their data as possible?

ze234we23

5/15/24, 1:50 PM

@joeqwerty the issue is, how do you create a password recovery process that can give you access to data that you have encrypted so that you can't see it? If the user forgets their password, and you have encrypted the data with some password/password-derived token, I can't think of a way to get that encrypted data back without storing the encryption key, making the whole exercise useless

ze234we23

5/15/24, 1:53 PM

@JohnMahowald No, the customer data contains personal details that we shouldn't have access to. It seems that to create a convenient way to recover that information if the user password is forgotten, there needs to be some compromise that would make it possible for a malicious dev actor to access it if they wish. So far I am considering using AWS KMS for encryption, which should create a log if permissions are altered/keys are accessed by the AWS dev users.

Score:0

Server

symcbean

5/15/24, 2:33 PM

From your description of the problem you already seem to have considered using (a derivation of?) the user's password as an encryption key. Hence loss of the password means loss of the encryption key means loss of access to the data. It also means that only a single user can access a specific dataset.

If, however, you assign a random key for encrypting the data then you can create multiple copies of this encrypted with DIFFERENT user keys. i.e. user access looks like

PLAINTEXT = DECRYPT( CIPHERTEXT, DECRYPT ( KEY_DATA[USER], USER_PASSWORD))

The problem this leaves is how you restore access - at some point, someone or something needs to know both the user's new password (or the derived equivalent used to encrypt the data key) and an alternate key. Further it opens a door to a denial of service type attack since the process should also revoke access using the forgotten key. How you minimize the risks arising is an operational consideration.

+ 3

ze234we23

5/16/24, 2:00 PM

I see, I am assuming this wouldn't meet something like GDPR though, perhaps at that point it is more down the lines of legal advice

symcbean

5/16/24, 3:49 PM

If your customer are paying for a service and there is a possibility of them losing access to their data by their own actions then you already need to get the contract sown up securely to CYA. Maybe you just give them the option to create the additional keys and store them themselves / optionally restrict the capabilities of the additional accounts to only provide the password reset facility.

John Mahowald

5/21/24, 2:40 AM

If a goal of this exercise was compliance with privacy regulations such as GDPR, that detail really should be in your question. Edit your question, which right now has lots of "how" but not "why" it matters to your organization.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Best practice for storing personal information on AWS that we shouldn't be able to see

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.