On Tue, Jun 26, 2012 at 2:17 PM, David wrote: > Any encryption/decryption you do on the hosting company side could end > up compromised, either by the webhost or somebody malicious. If the key > is ever sent by the client to the server then anybody with access to the > server theoretically has access to everything they need. Compromises at > the likes of LinkedIn and TechRadar recently show this isn't just pie in > the sky. > > Sensitive medical information simply shouldn't be on this sort of shared > hosting. The fact it's a "random paid webhost" doesn't inspire confidenc= e. > > A first step toward a better solution would be a secured dedicated > server (or VPS) with all communication being done over a properly > secured SSL session. A proper solution would build in a VPN from client > to server with all sensitive information transmitted over that tunnel. > > Yeah, this is why I'm considering using client-side AES256 encryption on all first/last names. The rest of the data is useless if the names are unknown. The only first/last name data leaving the client is encrypted first. Name data is already encrypted when it reaches the database server so no one can mess with it on the server's side. Even if I rent a VPS, someone will always have access to it on the hosting company's side, so there's no security there either. I guess it's impossible to ensure security if the host is untrusted since anyone with access to the host can inject a sniffer/rogue software which can steal encryption keys. The only way I can think of doing this is via client side encryption where anything leaving the client is encrypted first, so no plain data or keys or anything else that can be sniffed leaves the client without being encrypted locally first. --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .