Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "J.O. Aho" Newsgroups: comp.lang.php Subject: Re: getting started with encryption Date: Sat, 11 Oct 2014 18:38:49 +0200 Lines: 45 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net DhJmygeBdGZzCgePjCc69QhLc6l08fF6w4Gn2hWDwbJ7YkTXk4 Cancel-Lock: sha1:1jnXZNAVBtdPCnwvCxOOkEGAENk= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: Xref: csiph.com comp.lang.php:14320 On 11/10/14 16:42, bill wrote: > On 10/11/2014 10:36 AM, Jerry Stuckle wrote: >> If you are in the United States and dealing with patient medical data of >> any kind, you need to understand and follow HIPAA. Having someone HIPAA >> certified is the best. Failure and result in six or seven figure fines. >> >> For instance, all patient data MUST be secured. This doesn't mean just >> encrypting it in the database; it means the data must also be secured >> from any break-in, including physical theft of the system itself. You >> can't, for instance, have the decryption password readable, even if it >> is in a script. You also have to restrict who physically has access to >> the information server. >> >> The Feds are cracking down on HIPAA compliance; it's good you are >> encrypting the data. Just make sure you do it right. >> >> J.O.'s suggestion of doing it at the database level is a good on. > We have addressed physical security and have good access controls, now > we are moving on to worst case stuff - if the server is stolen. Session data stored in persistent storage will give the unauthorized 3rd party all they may need to decrypt the database. A brute force attack will be a lot simpler when just need to figure out a string. > Decryption password will have to be entered at each user login and > disappears when the session ends or when the user is auto loged out > after 3 hours of inactivity. 3 hours inactivity is far too long. Having the encryption/decryption key in memory for that long time will just make it easy to get hold of it for unauthorized 3rp party access. If you haven't, I suggest you take a look at Cornucopia, https://www.owasp.org/index.php/OWASP_Cornucopia quite useful game to figure out what vulnerabilities you may have. This covers more than just the OWASP top 10. -- //Aho