Concepts of a secure note sharing system

Question

I am trying to design a system that will allow for staff members in our small company to securely share sensitive customer information (text) and see them on a web page alongside less sensitive communications. I intend to use PHP because that's what I know best.

The main challenge is that the data needs to be stored on the server but it needs to be very time consuming to make useful if the server gets compromised.

My idea is as follows:

1. When a staff user is created, they choose a secure password and this is hashed using bcrypt(12) and stored in our database. The plain password is also used to create a 4096 bit RSA key pair using OpenSSL. Both keys are stored on the server.

2. When a secure note is created, it is encrypted with the public key of every staff member and each copy is stored in the database.

3. When a staff member logs in, their plain password is checked against the hash to see if they match. If they do, the plain password, client IP and user ID are serialised and symmetrically encrypted using mcrypt. The key used to encrypt the string is stored on the server's file system. The cypertext is then sent as a cookie to the client.

4. When a staff member accesses another page, the server decrypts the cookie and uses the plain password and the user's private key to decrypt any sensitive information in that request and sends the sensitive information to the user's browser.

The whole thing will be over HTTPS with secure ciphers.

I'm aware that this is probably very hard to make completely secure but I would like to know if anyone can spot any obvious flaws in this setup that can reasonably be improved. Generally, it would also be helpful to know how useful is a private key is without the associated secure password.

Answer 1

The general problem I see with your solution is that password operations are done on the server, (e.g. the users passwords are passed to the server for checking), however your threat model is to protect the data in the case of a server compromise.

If the server is compromised, they can just grab the users passwords as the client submits them for checking.

In order to implement the kind of solution you're talking about (i.e. one which is resistent to server compromise) you would need all the cryptographic operations to be done client-side, so that the server does not see things like passwords. It's worth noting that this kind of solution is quite difficult to implement in practice, as you need the clients to be able to operate without trusting the server at all (e.g. for code updates), otherwise an attacker who has compromised the server could do something like push a client update with a backdoor in it.

Answer 2

Your system is flawed in the first two steps because you're storing the keys with the encrypted data on the same system. If an attacker compromises the server they can just go find the keys and use the keys to decrypt the secret notes. It's difficult to accomplish what you want to do without the users all storing a private key for encryption on their device.

Because I can't comment on your original question some more information would be useful to make a strong recommendation. Do you need users to be able to access this system for any device? Is the system Internet facing? Roughly how many users will the system support?