Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.swapon.de!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: Sun, 12 Oct 2014 17:45:56 +0200 Lines: 88 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Hn8j4sFLdvulcQY5giCaQwmSY21HkoKOvRV5UPZR58tqWrV6IE Cancel-Lock: sha1:LnPeFcLUs6RSy74qHMhpolpEKGY= 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:14336 On 12/10/14 17:17, bill wrote: > On 10/12/2014 9:52 AM, J.O. Aho wrote: >> On 12/10/14 14:15, bill wrote: >>> On 10/11/2014 12:38 PM, J.O. Aho wrote: >>>> >>>> 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. >>> >>> Would you be so kind as to expand on this theme ? >> >> Assumption based on your earlier descriptions: >> - Decryption/encryption is done in the web application layer >> - Password for decrypt/encrypt is valid for a 3 hour session >> >> You need to store the session somewhere, >> using the session() which is used by php it will by default store >> the session data on disk. As it's on disk, it's easy to just open >> the session file and read the password from it and the third >> party has full access to the data. >> >> Even if you manage to delete or keep the session data out of >> reach for the 3rd party, it's simple to write a brute force >> script which can try to figure out the password trying dictionary >> words and random characters, as there will be no mechanism to >> prevent unlimited tries. [figure out a string] >> >> >> Using encryption keys which are handled by the database, you have >> something that is more difficult to generate, a valid key and the >> database may lock the user which tries more than X times with the >> wrong key. > > I understand that. Changing databases in a reasonably short amount of > time would be a problem. I didn't use a database abstraction layer so > that would be a major rewrite. Maybe for the next version (due in 2020). Waiting that long to fix a shortcoming is a bit long, even if it take some time for you to rewrite the database section of your project, it will be worth it and can make it easier to expand at a later stage with new functionality. I would strongly suggest postgresql as a replacement for mysql, as it does support encryption with pgp keys, sure I don't expect that switching database will go without issues, it hardly does. http://www.postgresql.org/docs/9.3/static/pgcrypto.html Sure, if you have money, go with InterSystems database, but they will charge by how many users will use the system. We did look at it as a replacement for Sybase, but the cost for us would have been too high, but had served our PCI DSS requirements. > Although it seems paradoxical, would keeping the key in a cookie on the > client machine be more secure? No, for then it's up to grabs for anyone who can access the client machine, anything on the client side should ALWAYS be considered as insecure and untrustworthy. > (assuming the cookie is overwritten at > timeout or logoff) It would involve a lot of transmitting the key to the > server, but this is over a physically secure LAN or hardware VPN. Don't matter, it's still insecure and untrustworthy, even if you use SSL on the intranet web server, but I do recommend usage of SSL even in an internal network, as not only outsiders may be keen on mischief, many times you have someone internally who is the bad guy or assisting someone outside. IMHO there is no good way to solve it than using database level encryption of the data. > The thought of that makes me shudder, but..... > It would address the issue of physical theft of the server. Yes, but that you need to address too, regarding something for it feels too unlikely, will become your Achilles heel. -- //Aho