NYCPHP Meetup

[Kenneth Downs]

csnyder wrote:

>On 8/4/06, Aaron Fischer <agfische at email.smith.edu> wrote:
>  
>
>>In my case I am thinking about encrypting (and decrypting) the user's
>>social security number.
>>
>>Where to store the key is a similar problem as where to store the
>>username/password credentials for DB access, correct?
>>
>>I'm in a shared hosting environment so I've got that working against me
>>as well.
>>
>>-Aaron
>>    
>>
>
>Since you can't keep the webserver out of the database, the encryption
>scheme is there to keep it out of the data itself.
>  
>
But that would only be an issue if you are using the "chocolate 
defense", hard on the outside, soft on the inside.

This is not an issue when using the Spartan defense, where the 
resistance gets stiffer the closer you get to the sensitive areas.  When 
this approach is used, being able to connect to the database is 
meaningless unless you can connect as a priveleged user.  Granting 
priveleged access to certain tables on a user-by-user basis is the most 
secure you can make the data.  The code then takes user credentials and 
connects as that user, instead of connecting as a superuser.

By contrast, letting the code connect as a superuser and letting the 
code arbitrate when to grant access to what to whom is by structure 
closer to 'chocolate' than to 'sparta', so it has to be discarded in 
cases where security is even marginally important.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060804/64dcdd3c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 186 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20060804/64dcdd3c/attachment.vcf>