3

I am designing a simple online patient management system that is running on shared hosting. According to national regulation sensitive data should be encrypted when used online, so I have encrypted all sensitive fields such as name, phone, address and blood type.

My problem is now how I should store the key? If the key is placed on the server, and the server is compromised, the data can easily be decrypted. After searching, I got the following solutions which I am still not sure if they are correct or not:

  1. Encrypting source code for all PHP files.
  2. Placing the key on another server and get it from the host through HTTPS connection using asymmetric encryption. The host gives the public key and the remote server gives the main key encrypted, then decrypt it and use it for encrypting patient data.

For these solutions we would face the same issue again on how to hide the keys.

I also looked at the question "Where to store a key for encryption?", but most of the points requires an administrator account which is not available on shared hosting.

Community
  • 1
Akam
  • 1,337
  • 3
  • 15
  • 24
  • 7
    I think a better question would be "Is it reasonable to assume I can protect PPHI using an arbitrary shared web hosting solution in such a manner as to satisfy applicable regulatory requirements?" I think the answer to that would be a resounding "No" which would render the question of where you store encryption keys moot. – Xander Aug 29 '13 at 19:40
  • Thanks @Xander for your note, so the answer is simply not, I can't guarantee the security on shared server. – Akam Aug 29 '13 at 22:46
  • 4
    Your typical shared hosting environment is 300 random users from 70 different countries, some of which are hostile to yours, and all of which can at least read your files. Encryption won't help you here since you have to have the decrypted data available to be worked with while the site is online. You can't possibly make anything secure enough in this environment. – Michael Hampton Aug 30 '13 at 02:08

2 Answers2

5

The only proper answer to this as Xander commented is that you can not expect proper security for sensitive data in a "Shared" environment. You are not the administrator of the server which means any security flaw or misconfiguration left open by "someone else" may result in your data being compromised. And commonly in such cases when the parties involved find anything which looks like an encryption key and some apparently encrypted files, the first thing tried is to decrypt and see whats inside.

So all in all it is best to get a host who can assure you HIPAA or PCI-DSS like data confidentiality or host the data in an environment which you or your organization has complete control over so you can secure it to acceptable levels yourself.

Fahad Yousuf
  • 251
  • 1
  • 4
  • 1
    This is a fine answer, but it misses the point of the question: this is a "Shared Host", which has a specific meaning in the commercial web hosting world. It means that all users have [at least] read-access to all other users' files. – Mark E. Haase Aug 30 '13 at 15:57
2

Co-sign with @Xander and @Michael Hampton.

Those source code encryption schemes all rely on... a private key. So that doesn't solve your problem, it just moves the problem somewhere else.

Obtaining the key from a separate server[1] has the same problem: you need to authenticate to that other server, and the authentication credentials must be stored somewhere on the shared host. So again, all you've done is moved the problem around a bit.

You could store the key in the database itself or in memory -- neither of which should be readable by other users on your shared host unless they exploit some vulnerability to escalate privileges[2]. In the case of in-memory storage, this would require you to connect to the application whenever it is restarted and provide the key remotely, which would require a secure connection.

I have no idea what the laws are like in your country [and IANAL], but from a purely ethical point of view, I would never host personal health information on an unaccredited shared hosting facility. You might be able to pull it off; you might even be able to comply with local laws and regulations, but it would still never be very safe.

You've also stumbled upon a much bigger problem in general: even the best encryption is only as strong as the safety of the private keys involved. Even in a dedicated hosting environment, a vulnerability in your application may enable an attacker to recover the key, and you are also vulnerable to anybody who has physical access to the server itself, such as any of the employees of your hosting provider.

Even if the key is perfectly secure, you still need to think about how your application handles the data after it's been decrypted. Do your access controls ensure that users only see information they are authorized to see? Do your security controls prevent or mitigate the risk of an attacker hijacking an authorized session and then using it for unauthorized purposes?

The answers to these questions depend, in part, on the legal requirements where are you are operating.

  1. Presumably the other server is not on a shared host, otherwise what benefit does this separation have? But if you have access to a non-shared host, why are you hosting your application on a shared host in the first place?
  2. Privilege escalation seems out of scope for the question you're asking.
Mark E. Haase
  • 1,912
  • 2
  • 15
  • 24