On Mon, Sep 22, 2008 at 10:52 AM, Nathan Rixham <nrixham@xxxxxxxxx> wrote: > emil@xxxxxxxxxxxx wrote: >> >> Hi, >> >> What methods do you guys use to keep a mysql table encryped, or well >> atleast a major part of it. Security is very important and I want to use a >> public and private key. Is GPG the only safe way? It's hell of an overhead >> using GPG on every col, even a very short string is easily 1000 characters >> when encrypted in gpg. >> >> Best Regards Emil >> > Personally my initial instinct is store everything on a secure non public > facing database server and don't worry about encrypting the tables; if > somebody can get in to your server and into the database then things need > looked at higher up the access chain. > > If it's a staffing thing then that's what permissions are for; and if it's > for storing things like credit card details; just don't - the major payment > gateways will do this for you so all you need to store is the transaction > id's and auth codes. > > regards > > nathan > Emil, Space won't be your only overhead. The time to encrypt/decrypt each value will add up as well. There are also other penalties: You would not be able to store data in the correct data types for numeric or date/time values (everything would become binary string data). Any optimizations for storage space, calculations or comparisons would be lost. You would have to decrypt the values and cast them to the correct type before they could be used in calculations or comparisons. Joins would become a lot more expensive because you either have to decrypt (and again, recast in many cases) the data before it can be used in joins, or else you will be joining on really long binary blocks. Indexes would become bloated and inefficient, if not useless altogether. Indexes on encrypted values will help locate a single row, but since encryption is intentionally "random" (putting aside previous discussions on the nature of random and computers), range-based queries cannot use them, and cause your query to resort to a very expensive full table scan. In fact, if you are handling the encryption in PHP, you would have to pull back the entire table and perform the scan/filtering in your code rather than letting the DBMS do the filtering for you. In that case, you may as well skip the database and just flat files. I tend to agree with Nathan here. Protect the server and use the minimal necessary permissions for you application to work. If you have specific values that you must store and that must be encrypted, encrypt only the data in those columns. If you're worried about someone reading the physical data files I would look at encrypted storage or a DBMS that offers encryption so it can handle these details internally. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
