Re: mysql and credit cards
On Wednesday 25 July 2001 17:53, Elvis wrote: You can always degrade the credit card. 1) verify AUTH ONLY (not capture) with your CC provider. (if you want to verify they have funds available and the CC is valid) 2) store the CC # in the database 3) ..do your order processing thing or whatever you need to have the CC for... 4) capture funds 5) degrade card value in the DB That seems to work well for non recurring credit card transactions (ie single purchases) One problem with this is that the CC number is still in the clear in the log files from step 2 above. If you have a full log for auditing purposes or debugging, an update log for backups, or a binary log for replication, the CC number will be in cleartext in that log. You need to do any encryption in your app to make this safer. That isn't perfect either. If someone gets root on your machine (assuming it is a Linux machine), then they'll be able to read the memory in which you application is running and might be able to see the CC number in that memory before it is encrypted. However, if you have that problem, this may be the least of your worries. Best, Kyle 'bot bait: mysql database query SQL -- Quicknet has just released the following new products: Internet SwitchBoard v5.5 and MicroTelco Gateway 2.0. We have also added a new low cost carrier, Blue Star Telecom to our award winning MicroTelco services. For more information visit: www.quicknet.net or www.microtelco.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
So sprach »Fletcher Sandbeck« am 2001-07-25 um 15:08:48 -0700 : I would counter that symmetric encryption is reasonably easy to implement and provides a modicum of security, so why not go ahead and do it. Just don't be fooled that a determined individual won't be able to defeat your encryption. If the goal is to provide protection in a use case like you just layed out, then yes, it's what I'd also recommend. But in this case, even MySQL's builtin ENCRYPT() function is good enough. No need to worry about highly complex/secure methods. It's rather security-through-obscurity then. Which is fine in certain use cases. PS: filter sql Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 3 days 17 hours 28 minutes - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
[fwd] Re: Re: mysql and credit cards (from: mysql@lists.mysql.com)
database,sql,query,table So sprach =BBPeter van Dijk=AB am 2001-07-25 um 23:59:48 +0200 : That is only true for a parallel cipher. A non-parallel cipher (like Yep, that's why I said symetrical encryption. Asymetrical enc.'s work like you explained. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 3 days 17 hours 34 minutes - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
[fwd] Re: mysql and credit cards (from: ASkwar@DigitalProjects.com)
So sprach »William R. Mussatto« am 2001-07-25 um 23:01:49 -0700 : But what happens when the customer returns the product? You no longer have the cC to do a chargeback Have him enter it again. Explain that this is done to increase the security and he may be fine. If not - well he's already unhappy so he may go. PS: PLEASE *NO* FULLQUOTES! No topquotes either. PPS: sql and such Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 3 days 17 hours 32 minutes - End forwarded message - Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 3 days 17 hours 35 minutes - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
So sprach »Alexander 'Digital Projects' Skwar« am 2001-07-26 um 18:48:15 +0200 : MySQL's builtin ENCRYPT() function is good enough. No need to worry Uhm, is ENCRYPT decryptable? Anyhow, I was rather thinking about ENCODE()/DECODE(). PS: filter sql Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 3 days 17 hours 40 minutes - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
mysql and credit cards
Greetings: I was wondering if anyone has any ideas about the best way to store credit cards in a database ... and I'm not referring that much to the field type, but rather encrytption techniques. Thanks. Alan Cox [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
Depending on the 'environment' (i.e. O/S you're using), the tools available might be different... But, using Linux (and I'm sure any other 'flavor' of Unix), my company used the latest 'libmcrypt' to encrypt the credit card numbers (as well as the user passwords) within a PHP function prior to storing it in the database. You have to hide the 'key' or 'salt' that you used in order to 'decrypt' it again (when using it to 'charge' transactions) pretty good (don't keep it on the same server as the database, in case someone gets their hands on a copy of your DB or a 'dump'). I have attached my simple 'webdoc' on how to install libmcrypt for use with Apache/PHP - Original Message - From: Alan Cox [EMAIL PROTECTED] To: mysql [EMAIL PROTECTED] Sent: Sunday, February 20, 2000 9:57 AM Subject: mysql and credit cards Greetings: I was wondering if anyone has any ideas about the best way to store credit cards in a database ... and I'm not referring that much to the field type, but rather encrytption techniques. Thanks. Alan Cox [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
So sprach »Alan Cox« am 2000-02-20 um 11:57:47 -0500 : Greetings: I was wondering if anyone has any ideas about the best way to store credit cards in a database ... and I'm not referring that much to the field type, but rather encrytption techniques. 'encryption'? Hmm, how about: none? If you don't need to reconstruct the cc#, md5 will be good. However, if you need to reconstruct it, nothing is safe. And that's quite simple: a) You need to get access to the MySQL server. Impossible to do from the outside if '--skip-networking' is used. b) So, only possible from the localhost. This means, there must have been a break in to the MySQL server. Once he's on the server, he can do anything he likes. He can also read the source code of your PHP/PERL pages. There the password will be stored, somewhere. Once the password has been found (which is nothing but a matter of time), your encryption is broken. BUT: If you're using something like C or any other compiled language and do not have the source code flying around and are sure that the password cannot be decrypted from the binary, any symetrical encryption will probably do. The last also applies, if you use a program to decrypt the cc# which is not stored on the same computer as the MySQL database. But then you need to worry about how to securly transfer the data from the MySQL database to the computer running the decryption program. So, overall, I'd say: Don't hassle with encryption: It's not worth it. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 2 days 17 hours 44 minutes - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
On Wed, Jul 25, 2001 at 07:12:17PM +0200, Alexander Skwar wrote: [snip] 'encryption'? Hmm, how about: none? If you don't need to reconstruct the cc#, md5 will be good. Indeed. That is however rarely the case with credit card numbers. However, if you need to reconstruct it, nothing is safe. And that's quite simple: a) You need to get access to the MySQL server. Impossible to do from the outside if '--skip-networking' is used. b) So, only possible from the localhost. This means, there must have been a break in to the MySQL server. Once he's on the server, he can do anything he likes. He can also read the source code of your PHP/PERL pages. There the password will be stored, somewhere. Once the password has been found (which is nothing but a matter of time), your encryption is broken. That is only true for a parallel cipher. A non-parallel cipher (like PGP) allows you to store just the public key on the server, and have the private key stored somewhere else save, on a way more secured box that actually handles the transactions. Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
On 7/25/01 at 7:12 PM, Alexander Skwar wrote: However, if you need to reconstruct it, nothing is safe. And that's quite simple: a) You need to get access to the MySQL server. Impossible to do from the outside if '--skip-networking' is used. b) So, only possible from the localhost. This means, there must have been a break in to the MySQL server. Once he's on the server, he can do anything he likes. He can also read the source code of your PHP/PERL pages. There the password will be stored, somewhere. Once the password has been found (which is nothing but a matter of time), your encryption is broken. I respectfully disagree with this assessment. Encrypting data in a database can be useful, even if the key is relatively easy to find. The situation you describe is one of a determined individual trying to gain access to credit card data. This is indeed the most difficult type of person to prevent gaining access to your data. If they are able to compromise your system then they will be able to decrypt the data in the database and get the credit card numbers. However, encryption prevents casual viewing of credit card data and prevents the discovery of credit card data if a secondary system is compromised. For casual viewing, you may have employees who have access to the database for the purpose of fulfilling orders or contacting customers. If credit card numbers are encrypted then the employees will have to take a positive step to steal credit card numbers. They won't be able to simply jot down numbers out of the data they have available. For example, if an individual gains the ability to execute SQL statements on your server, but doesn't have file access. If the credit card numbers are stored plain then they can gain access to them. If they are stored encrypted then the data is of no use without the key. So, overall, I'd say: Don't hassle with encryption: It's not worth it. I would counter that symmetric encryption is reasonably easy to implement and provides a modicum of security, so why not go ahead and do it. Just don't be fooled that a determined individual won't be able to defeat your encryption. It's rather like HTTPS encryption. It's a first step that prevents casual peeking at the data which is being transmitted between a client and the server. However, it does not prevent a determined individual from seeing the traffic. [fletcher] -- Fletcher Sandbeck [EMAIL PROTECTED] Lasso Product Specialist [EMAIL PROTECTED] Blue World Communications, Inc. http://www.blueworld.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
AND, you'd want to 'protect' the data from viewing if you've 'dumped' the database or backed it up to an 'insecure' media or location (to tape/disk)... Encrypting the data, with the 'key' or 'salt' located somewhere else, would allow you to 'transport' the tables containing the sensitive data (i.e. credit card info) with some sense of security... - Original Message - From: Fletcher Sandbeck [EMAIL PROTECTED] To: mysql [EMAIL PROTECTED] Sent: Wednesday, July 25, 2001 3:08 PM Subject: Re: mysql and credit cards On 7/25/01 at 7:12 PM, Alexander Skwar wrote: However, if you need to reconstruct it, nothing is safe. And that's quite simple: a) You need to get access to the MySQL server. Impossible to do from the outside if '--skip-networking' is used. b) So, only possible from the localhost. This means, there must have been a break in to the MySQL server. Once he's on the server, he can do anything he likes. He can also read the source code of your PHP/PERL pages. There the password will be stored, somewhere. Once the password has been found (which is nothing but a matter of time), your encryption is broken. I respectfully disagree with this assessment. Encrypting data in a database can be useful, even if the key is relatively easy to find. The situation you describe is one of a determined individual trying to gain access to credit card data. This is indeed the most difficult type of person to prevent gaining access to your data. If they are able to compromise your system then they will be able to decrypt the data in the database and get the credit card numbers. However, encryption prevents casual viewing of credit card data and prevents the discovery of credit card data if a secondary system is compromised. For casual viewing, you may have employees who have access to the database for the purpose of fulfilling orders or contacting customers. If credit card numbers are encrypted then the employees will have to take a positive step to steal credit card numbers. They won't be able to simply jot down numbers out of the data they have available. For example, if an individual gains the ability to execute SQL statements on your server, but doesn't have file access. If the credit card numbers are stored plain then they can gain access to them. If they are stored encrypted then the data is of no use without the key. So, overall, I'd say: Don't hassle with encryption: It's not worth it. I would counter that symmetric encryption is reasonably easy to implement and provides a modicum of security, so why not go ahead and do it. Just don't be fooled that a determined individual won't be able to defeat your encryption. It's rather like HTTPS encryption. It's a first step that prevents casual peeking at the data which is being transmitted between a client and the server. However, it does not prevent a determined individual from seeing the traffic. [fletcher] -- Fletcher Sandbeck [EMAIL PROTECTED] Lasso Product Specialist [EMAIL PROTECTED] Blue World Communications, Inc. http://www.blueworld.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
You can always degrade the credit card. 1) verify AUTH ONLY (not capture) with your CC provider. (if you want to verify they have funds available and the CC is valid) 2) store the CC # in the database 3) ..do your order processing thing or whatever you need to have the CC for... 4) capture funds 5) degrade card value in the DB That seems to work well for non recurring credit card transactions (ie single purchases) Bill Elvis Gibbs goEbusiness.com - putting e-motion in your business email - [EMAIL PROTECTED] work - 301-668-5090 cell - 301-748-6938 On Wed, 25 Jul 2001, Steve Brazill wrote: AND, you'd want to 'protect' the data from viewing if you've 'dumped' the database or backed it up to an 'insecure' media or location (to tape/disk)... Encrypting the data, with the 'key' or 'salt' located somewhere else, would allow you to 'transport' the tables containing the sensitive data (i.e. credit card info) with some sense of security... - Original Message - From: Fletcher Sandbeck [EMAIL PROTECTED] To: mysql [EMAIL PROTECTED] Sent: Wednesday, July 25, 2001 3:08 PM Subject: Re: mysql and credit cards On 7/25/01 at 7:12 PM, Alexander Skwar wrote: However, if you need to reconstruct it, nothing is safe. And that's quite simple: a) You need to get access to the MySQL server. Impossible to do from the outside if '--skip-networking' is used. b) So, only possible from the localhost. This means, there must have been a break in to the MySQL server. Once he's on the server, he can do anything he likes. He can also read the source code of your PHP/PERL pages. There the password will be stored, somewhere. Once the password has been found (which is nothing but a matter of time), your encryption is broken. I respectfully disagree with this assessment. Encrypting data in a database can be useful, even if the key is relatively easy to find. The situation you describe is one of a determined individual trying to gain access to credit card data. This is indeed the most difficult type of person to prevent gaining access to your data. If they are able to compromise your system then they will be able to decrypt the data in the database and get the credit card numbers. However, encryption prevents casual viewing of credit card data and prevents the discovery of credit card data if a secondary system is compromised. For casual viewing, you may have employees who have access to the database for the purpose of fulfilling orders or contacting customers. If credit card numbers are encrypted then the employees will have to take a positive step to steal credit card numbers. They won't be able to simply jot down numbers out of the data they have available. For example, if an individual gains the ability to execute SQL statements on your server, but doesn't have file access. If the credit card numbers are stored plain then they can gain access to them. If they are stored encrypted then the data is of no use without the key. So, overall, I'd say: Don't hassle with encryption: It's not worth it. I would counter that symmetric encryption is reasonably easy to implement and provides a modicum of security, so why not go ahead and do it. Just don't be fooled that a determined individual won't be able to defeat your encryption. It's rather like HTTPS encryption. It's a first step that prevents casual peeking at the data which is being transmitted between a client and the server. However, it does not prevent a determined individual from seeing the traffic. [fletcher] -- Fletcher Sandbeck [EMAIL PROTECTED] Lasso Product Specialist [EMAIL PROTECTED] Blue World Communications, Inc. http://www.blueworld.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql and credit cards
But what happens when the customer returns the product? You no longer have the cC to do a chargeback On Wed, 25 Jul 2001, Elvis wrote: Date: Wed, 25 Jul 2001 20:53:26 -0400 (EDT) From: Elvis [EMAIL PROTECTED] To: Steve Brazill [EMAIL PROTECTED] Cc: Fletcher Sandbeck [EMAIL PROTECTED], mysql [EMAIL PROTECTED] Subject: Re: mysql and credit cards You can always degrade the credit card. 1) verify AUTH ONLY (not capture) with your CC provider. (if you want to verify they have funds available and the CC is valid) 2) store the CC # in the database 3) ..do your order processing thing or whatever you need to have the CC for... 4) capture funds 5) degrade card value in the DB That seems to work well for non recurring credit card transactions (ie single purchases) Bill Elvis Gibbs goEbusiness.com - putting e-motion in your business email - [EMAIL PROTECTED] work - 301-668-5090 cell - 301-748-6938 On Wed, 25 Jul 2001, Steve Brazill wrote: AND, you'd want to 'protect' the data from viewing if you've 'dumped' the database or backed it up to an 'insecure' media or location (to tape/disk)... Encrypting the data, with the 'key' or 'salt' located somewhere else, would allow you to 'transport' the tables containing the sensitive data (i.e. credit card info) with some sense of security... - Original Message - From: Fletcher Sandbeck [EMAIL PROTECTED] To: mysql [EMAIL PROTECTED] Sent: Wednesday, July 25, 2001 3:08 PM Subject: Re: mysql and credit cards On 7/25/01 at 7:12 PM, Alexander Skwar wrote: However, if you need to reconstruct it, nothing is safe. And that's quite simple: a) You need to get access to the MySQL server. Impossible to do from the outside if '--skip-networking' is used. b) So, only possible from the localhost. This means, there must have been a break in to the MySQL server. Once he's on the server, he can do anything he likes. He can also read the source code of your PHP/PERL pages. There the password will be stored, somewhere. Once the password has been found (which is nothing but a matter of time), your encryption is broken. I respectfully disagree with this assessment. Encrypting data in a database can be useful, even if the key is relatively easy to find. The situation you describe is one of a determined individual trying to gain access to credit card data. This is indeed the most difficult type of person to prevent gaining access to your data. If they are able to compromise your system then they will be able to decrypt the data in the database and get the credit card numbers. However, encryption prevents casual viewing of credit card data and prevents the discovery of credit card data if a secondary system is compromised. For casual viewing, you may have employees who have access to the database for the purpose of fulfilling orders or contacting customers. If credit card numbers are encrypted then the employees will have to take a positive step to steal credit card numbers. They won't be able to simply jot down numbers out of the data they have available. For example, if an individual gains the ability to execute SQL statements on your server, but doesn't have file access. If the credit card numbers are stored plain then they can gain access to them. If they are stored encrypted then the data is of no use without the key. So, overall, I'd say: Don't hassle with encryption: It's not worth it. I would counter that symmetric encryption is reasonably easy to implement and provides a modicum of security, so why not go ahead and do it. Just don't be fooled that a determined individual won't be able to defeat your encryption. It's rather like HTTPS encryption. It's a first step that prevents casual peeking at the data which is being transmitted between a client and the server. However, it does not prevent a determined individual from seeing the traffic. [fletcher] -- Fletcher Sandbeck [EMAIL PROTECTED] Lasso Product Specialist [EMAIL PROTECTED] Blue World Communications, Inc. http://www.blueworld.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED
