>Hey Alvaro, I just called you but you weren't around. Anyway, I can >throw out some thoughts. Hi Dustin, thanks you caught me running from the house to the car, a cello on one hand, a bunch of music on another, heavy rain, my new motorola phone on my shirt pocket getting wet, and my wife asking why I had closed the truck of the car and why I was not holding the umbrella for her. As soon as I got into the car and things settled ( I told my wife I did not notice she was getting wet under the heavy rain ) I returned the phone call but you were gone; I left a message :-) Anyway, sorry I missed the call.
>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? Yes, I have done that before but on dedicated servers where administrator privileges to the database are available. >So if a salesperson logs in she gets access to the database, >but without her password there would be no way to decrypt 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. This is what I had planned. Then I figured I can have the manager login all the terminal as a daily routine. Also, I was thinking to have a common personal certificate installed on each machine. I will give that a try although I think I have already gone through this in the past without success. >2. All salespeople have their own password, and all of their passwords >can decrypt the database. I do not know how to write the encryption algorithm. I have no idea how to implement something that would yield the same crypted text with different keys nor I know of any function that will do this. I welcome any ideas. >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. Again, shared server. This is what should change but it is difficult to convince the company to shed the money required. >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 decrypt 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. This in combination with the secondary machine could work. I could use something like CURL with SSL and have a script on the machine behind the firewall that would only allow this IP. Having the script post the username and password and return the CC info; again all this over SSL. Getting a static IP and a dedicated machine with the database is not as bad as paying for dedicated services. If I get to do this however, why not two machines had have them host everything! On second thought, then comes the machine security which I could not handle and would add an extra expense. Imagine, from $15 a month to $200 a month or possibly more. I will see about this. So far I sent a letter already stating that I am not willing to have the information available to anyone other than the admin. This has already been done and the only problem I could have is the hijacking of the session. I do not know how to avoid this or how it is done for that matter so I cannot help this. All I can do is try to adhere to safe programming to the best of my abilities. Thank you very much for your help Dustin. I definitely like the idea of having the CC info on a secure machine using the crypted form of the password to access the database. Even if someone could hack the session they would still have to hack the machine hosting the information but that would no longer be my job :-) so I would let someone else worry about that. take care, Alvaro Zuniga ----- 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 >> >> _______________________________________________ General mailing list [email protected] http://brlug.net/mailman/listinfo/general_brlug.net
