Hiding sensitive data
A few ideas for hiding sensitive user data, presented by their promoters
Peter's idea
Assumptions:
- Any attacker can get his hand on the code and the database.
- We have to trust some people completely.
- We want to use a minimum of space and power on encryption/decryption.
- We want admins to be able to access encrypted data if and when needed.
Consequences of above:
- one table with data encrypted as needed, instead of two (minimizing space)
- DB records should be encrypted individually (otherwise: decrypt one
decrypt all)
- Encryption key cannot be stored in full on server (Attacker has
access to both)
- One encryption key is not an option (decrypt one = decrypt all)
Possible parts of solutions:
- Individual keys must be used to encrypt individual records. This
could be users passwords, however this gives two problems: 1) for people with openid logins there is no password and 2) this means admins wouldn't be able to have access as they don't know the password. Solution: a) generate a random string as password for users with openid logins and b) don't use the users passwords but the hashes of passwords.
- the above solution solves two problems but obviously introduces
another: using the hashes of passwords means using data stored in the db, which the attacker has access to. Solution: for every record, generate a unique key consisting of password hash + master key.
- to avoid reintroducing the problem of the stored master key, this
can't be placed as a file or part of the code. Furthermore, if we're really interested in security, we need to change the master key from time to time. This obviously introduces more problems: 1) key musn't be stored and 2) key has to be changeable. Solutions: a) have admins input the key as a passphrase or password. This avoids storing the key anywhere. b) this is a lot harder. The obvious solution is ofcourse to re-encrypt the DB from time to time, but this will take a long time and use a lot of resources. A hack would be to keep the same master key, but obtain it in different ways ... that will ultimately remain a hack, though, but it can be done and is better than storing a key somewhere.
- this approach leaves one major problem: access by users to their own
data. Since they obviously don't have the master key, they won't be able to see their own details. I'm still looking for solutions to this one ;)
Thomas' idea
...
Felix' new idea, incorporating ideas by Philipp
passswords
- passwords are stored with mysql PASSWORD function (implicitly a double used SHA-1 hash)
hiding of sensitive user data
All of the following is said only in regard to people, who want some or all of their data being hidden and therefore encrypted/decrypted.
- A new user registers for BW; an individual-related salt (random string, 8 bytes) is written to the database; her data is written to the database as plain text
- While first loging in as a new (now approved) member, the password combined with the salt is the basis for calculating a SHA-1 hash value; this value is used to encrypt all of her data; the decrypted data is written to the database; additionally the data is written to the database encrypted by a public key
- A non-admin member logs in; the afore mentioned hash value is written to the session environment of the logged in member
- An admin member logs in; no confidential data is written to the session environment; in case of access to encrypted data or read/write of her own profile, she's asked for her password; the password plus the salt from the members table is the basis for calculating a SHA-1 hash value (the method to determine the hash is the same for admins and non-admins)
- An admin needs to access data of a member or an admin needs to access her own data; she has to provide her password (in every single case, i. e. request); the password plus the salt from the members table is the basis for calculating a SHA-1 hash value (the method to determine the hash is the same for admins and non-admins); the hash is used to decrypt a private key (which is never transmitted to anybody); the private key is used to decrypt the data
- Members lost her password and asks for new one; the admin user has to log in at a special page, to hand over his password and by this to trigger the decryption of the profile of the affected members; until the next login of the member, her data is not encrypted
advantages
- performance (symmetric encryption and hashing for normal operations, asymmetric encryption for special operations - that's fast)
- the private key is transfered to anybody and can be changed transparently once in a while
- the password is safe, even when the hash is robbed
- in case the member moves, she can easily update her data
- it is possible to change encryption strategies frequently, even to change the whole software design - independently on how many members we have
- it is possible to decrypt user data in case the member lost her password
disadvantages
- if a memory dump is accomplished or the session is burgled, it is possible to read the data of the affected member (only non-admins)
- in case of password loss, admin access is needed and the sensitive data is temporarily stored as plain text
- complicate design
Felix' old idea
passswords
- passwords are stored with mysql PASSWORD function (implicitly a double used SHA-1 hash)
hiding of sensitive user data
- a new user registers for BW; a salt (random string, 8 bytes) is written to a new column in the members table
- a member logs in; her password plus the salt from the members table is the basis for calculating a SHA-1 hash value; the hash value is written to the session environment of the logged in member
- the hash is used for (symmetric) en-/decryption of all of her data (cypher, initialization vector and so forth have to be denounced by me still...)
- a master key for decryption is saved in the file system and (transparently) accessed by those members, who are administrators of the site (by this means e. g. the signup team is able to accept/reject new members); the master key is never part of the session environment of a user
advantages
- simplicity
- performance (symmetric encryption and hashing is fast)
- the password is safe, even when the hash is robbed
- it is possible to find a better solution for the master password
- it is possible to change encryption strategies frequently, even to change the whole software design after a while - independently on how many members we have
- it is possible to decrypt user data in case the member lost her password
disadvantages
- if a memory dump is accomplished or the session is burgled, it is possible to read the data of the affected member
- the master password is readable by system administrators and allows to decrypt all sensible data
- the master password is readable by a hacker, who breaks into the system (got shell access or could upload PHP file or or or) and allows her to decrypt all data
remarks
I don't know of any shop system, which encrypts data of registered users. (I've been working on some of the biggest shop systems in Europe, with user data worth several million Euros.) We shouldn't overestimate the desirability of our data, until we have some (10000...?!) members.
Additionally I think it would be much more important for security
... to shape policies for the ways people access our servers;
... to be very strict with the numbers of users, who have access to our servers, especially shell accounts;
... to introduce authoritative working processes.
On the other hand I'd like to respect the wish of some fellow BeVolunteers? to see their personal data been not only secure, but encrypted in a professional way.
See also…
- /modules/security/lib/enc.lib.php and /modules/security/lib/encdb.lib.php
