Hey Alvaro, I just called you but you weren't around. Anyway, I can throw out some thoughts.
You are in a pickle here. No matter what you do a key must exist somewhere to decrypt the database. If the key is on the server with the database, and that server is a web server, well, things aren't good. The best solution is to convince management that this is a bad idea. Unfortunately, you can't always do that, so let's assume you have to solve the technical problem rather than the management problem. Is there a way to connect a salesperson's password to the database password? So if a salesperson logs in she gets access to the database, but without her password there would be no way to decyrpt the database. That way you can at least restrict the avenues of attack to one of three things: 1. The attacker knows a salesperson's password. 2. The attacker is able to hijack a saleperson's session. 3. The attacker is able to read the server's memory or paging file. How would you implement this? 1. All salespeople have the same password. 2. All salespeople have their own password, and all of their passwords can decrypt the database. With the second option you may not need to directly decrypt the database with the saleperson's password. Rather, you may be able to unlock the "CC column key" with any of those passwords. Okay. So on the web server you have a table like so: user password-hash cc-col-encrypted-decryption-key ----------------------------------------------------------------- bob lskdjf34 sldkfj43 (= 'hello') phil k34f3 ss--34343f (= 'hello') sue 34fd3;4 sdj3434334 (= 'hello') So 'sue' logs in and her password decrypts sdj3434334 to 'hello', which is the key to decypt the CC column. This means there is no plaintext 'hello' on the server, ever, other than in memory and available to the PHP session. You would maintain a master salesperson password/decrypt-key database on a secured, internal server. When you updated 'hello' the secured server would recompute cc-col-encrypted-decryption-key and push the new values to the web server's local salesperson table. The solution, as such, is that the decryption key is never on disk. Unfortunately, you are still open to attacks if someone knows a good password for login, can hijack a session, or can read the server's memory. ----- Original Message ----- From: "Alvaro Zuniga" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, February 10, 2004 1:05 PM Subject: Re: [brlug-general] Securing Database information > Hi Dustin: > > Do customers ever need to see their credit card number? > Never > > Question: Is the credit card processing done on this computer as well? > Or on another computer? It's best to physically separate the credit card > database from the processing server. > The credit card processing is done in a different physical location. > However, the database has an encrypted version of the card. The > encryption is done at the application level and travels in its encrypted > form to the database. > > Do your sales or transaction people need to access this site, or can > they run on the processing server? > Unfortunately, they need access to this information to pull the > information from the database. Then this information is decrypted, once > again at the application level. > > This is the problem that I am facing now. The potential sales people > will need access to this information to enter and retrieve data. > > Answer these questions and we can start from there. > > Thank you for your Help Dustin. > > Alvaro Zuniga > > -- > Alvaro Zuniga > Information Techonology Professional > Zunitek Solutions > (337) 654 6515 > www.zunitek.com > > > _______________________________________________ > General mailing list > [email protected] > http://brlug.net/mailman/listinfo/general_brlug.net > >
