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?
5
-
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– HBruijnMay 15 at 11:10
-
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.– joeqwertyMay 15 at 12:04
-
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?– John MahowaldMay 15 at 12:59
-
@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– ze234we23May 15 at 13:50
-
@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.– ze234we23May 15 at 13:53
Add a comment
|
1 Answer
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.
-
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 May 16 at 14:00
-
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.– symcbeanMay 16 at 15:49
-
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. May 21 at 2:40