On Fri, Apr 17, 2009 at 10:15 AM, דניאל דנון <danondaniel@xxxxxxxxx> wrote: > If its by a user-basis, something that can be a bit risky but possible - > You > can encrypt it, password is hashed on database, and the key to the other > data is the un-encrypted password.. > > On Fri, Apr 17, 2009 at 5:00 PM, Russell Jones <rjonesx@xxxxxxxxx> wrote: > > > We are looking at a project where we will potentially need to store > > sensetive information in a few fields of a MySQL table. Any > recommendations > > on where to look for best practices in doing this? for encrypting the > data, > > etc.? We will need to be able to decrypt the data as well, although this > > can > > probably be done locally, so hashing alone is not really an option. > > > > Russell Jones > > > > > > -- > Use ROT26 for best security > I do similiar stuff here and the approach is: 1. provded a salted hashed value for searching (if this is not required, you don't need this) 2. encrypt using the mcrypt functions (using the rijndael algorithm), we add a salt and ecnrypt each record with its record number as the key. (the advantage is that there is no common key for all records, just gonna make a hackers life tougher) Personally, I would prefer to situate all encrypted records in their own table with a structure like: record_id int auto number main_record_id (whatever your system has as a main record) field_name varchar(32) enc_value varchar(255) you could also add some tracking [last_access_time] int (unix timestamp) [last_access_id] varchar(32) if you want to store the data with the record -- Bastien Cat, the other other white meat
