Storing Data Securely using PHP

Question

I have a requirement to securely store some data that can be retrieved by authorised users on a website. It's not credit cards, but equally it's data that you wouldn't want someone getting their hands on.

The only user that will retrieve the data is the one who posted it.

So, I'm thinking of putting something together like the following:

• Everything is run over SSL
• To login, a user will enter their username and password, and also have to upload a 'key' file - users will be recommended to only keep one copy of the key file on a thumb drive or similar
• The user's key will not be physically stored on the server. When the user provides their key to login it will be stored in memory
• All stored data will be encrypted using MCRYPT_RIJNDAEL_256, and the key used to encrypt will be part of the key file they must upload (ie the one not stored on the server)
• While the user's key is being kept in memory, this will also be encrypted using MCRYPT_RIJNDAEL_256 using a key that changes on a daily basis
• We will generate a new 32-byte IV when data is retrieved, so we should get different results for two separate retrievals
• The user can regenerate their key whenever they require, at which point all stored data is re-encrypted with their new key
• The user can set a timeout on the in memory storage of their key - requiring them to re-provide it (for example), every 30 minutes.
• The user can also set an inactive timeout on the in memory storage, so say they don't perform an action for (for example) 5 minutes, it will also expire the key
• The box itself will be locked down to only expose port 80, and port 22 to a single IP (our office IP)

My question is:

Am I thinking along the right lines? Is the above solution going to be secure, or am I missing some attack vector that is going to make getting the data easy?

As far as I can tell, an attacker would need physical access to the machine (or would need to be on our office network), and even if this was the case, they could only retrieve data for users logged in at that moment (since they are the only keys that would be stored)? Are my assumptions correct?

Is there any way of removing the requirement to store the user's key in memory while they are logged in (short of asking them to re-supply their key on every request)? I don't think there is, but I'm hoping it's something I've not thought of.

Thanks!

Answer 1

This sounds a little paranoid on a local network but here are a few other things to consider. These are some things that I've run into myself.

1. Is the box and physical access to the box locked down and monitored (secure room, secure rack, cameras)? Patch cables can link this thing to the internet if it's in the same rack as a switch that goes "online." Also someone can bring in a wireless router and connect it to the network (hide it under the desk) that way you can't tell it's broadcasting. USB routers are also available for connection sharing. Check Mac Addresses.

2. If you're asking for keys you probably want to hash the key against a second phrase (user provided possibly like a two-step password) and a hidden phrase that only you know so if anyone ran a cycler on this thing they couldn't get anywhere. Also if they catch a couple of packets you don't want them to try and decipher the dump. If you're hashing when someone provides a different key and the hash fails then you know they aren't the person you think they are.

3. It is possible to break SSL if you catch the initial handshake where the keys are exchanged (high-end routers at banks do this so they can speed up transfers) so anything transmitted over the connection can be tapped with something like Wireshark. If there is access to the hardware layer?

4. Anything captured can be collected on the machine if there is access to a usb port (so the ports need to be locked down on the physical machine). If you're having them provide a thumbdrive then this needs to be checked as well (root kits, key loggers, etc). Maybe a checksum on the application on the thumbdrive that runs. Also the machine needs to be checked for other usb thumb drives physically (maybe on the back of the machine) where someone might install a keylogger and wait.

5. If they have access to the CD-rom on the machine can they reboot the machine and user something like knoppix? There would be no digital paper trail.

6. In the browser you probably want to make it keep no history.

7. All web pages need to expire immediately.

8. You might make it install a clean VM everytime someone connects to the machine.

9. Use a different default web port.

10. Since it's in the datacenter you'll want to make sure that the box itself looks for specific connections in order to work properly (sort of like a stay-alive authentication). That way someone has to physically intervene if the box has a man-in-the-middle attempt in order for the box to come back online.

11. Make sure the box isn't blindly trusting the local network if it has its own firewall or local network at the server farm (in the same rack). Some of my past clients hosted in the "secure" cages at a "nuclear ready" facility to find out other people had patched into their gigabit switch behind their enterprise level firewall and on the same subnet as their secure servers. They were broadcasting using my clients connection and not trying to get into my client's box, although they did manage to infect one of my client's mail servers (Microsoft) with code red. My client's antivirus/antispam firewall (a Fortinet) blocked all of the outbound virii, worms, and unsolicited mail (I was paged by the firewall about the new mac address seeking an IP). Luckily we weren't using DHCP and none of the servers in the local network communicated back and forth so when the other box started a port scan it found the exchange box because of the outbound traffic.

12. For the best security, you'll want to make sure that the rack itself is in its own cage or physically locked in (standalone). It's a little more expensive but if the data is that mission critical it could be bad if there is a breach. Most of the server farms trust authenticated people who gain access to the cages are on the up-and-up, so they don't normally put cameras inside the cages that contain 30-40 racks if you happen to host in the general population at a major server farm. Also most server farms have a couple of "guards" or people who monitor the cameras and logins and a few techs on-hand depending on what's hosted there.

13. Make the firewall on the box itself only accept connections from a couple of your own specific static IPs, as well as any applications on the box should also do verifications as well. If you're using a firewall only allow trusted VPN connections to access anything other than the needed resources (web applications, databases, etc).

Hope this helps.

Answer 2

If only the user uploading need to be able to read the content, maybe a public-key cryptography can be useful?

This way you would not really have to care about having a key in memory or being scared of someone sniffing the data. The client would encrypt the files with his public key from anywhere he might be in the world. Only when someone has access to his private key (which is not required at the encryption moment) will you be able to decrypt that data.

GPG is a great tool for something like this and there exists a lot of graphical user interfaces for it.

If the server is some kind of backup, just make sure you store a copy of the private key somewhere safe. That could be on an external medium without any kind of internet access.