Re: Credit Card DB Encryption Methodology
I'm rather surprised that I so seldom see someone suggestion using one's own public key to encrypt the data, and your private key to decrypt the data - are people just not using PGP and the like? -- Never apply a Star Trek solution to a Babylon 5 problem. Larry W. Virden mailto:[EMAIL PROTECTED] URL: http://www.purl.org/NET/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
On Tue, 08 May 2001 06:09:49 -0400 (EDT), Larry W. Virden [EMAIL PROTECTED] wrote: I'm rather surprised that I so seldom see someone suggestion using one's own public key to encrypt the data, and your private key to decrypt the data - are people just not using PGP and the like? We do exactly that on a subscription site. The client logs into his admin interface every day (thru SSL of course) and if there are subscriptions due to be processed, he pastes in his private key (which is meant to be stored offline on a floppy or something but I doubt he bothers) and the due subscriptions are batch processed. We rolled our own solution using RSA (public domain) because PGP was so goddamn expensive. cfplug The tag is available on our website if anyone is interested - http://developer.perthweb.com.au! /cfplug. This could work for refunds if you aren't expecting them to be too often - I think that you'd want a real live human to be looking over them anyway, just in case some hacker has found some hole in your system you didn't think of. It wouldn't work for storing a credit card for future purchases by the user, but then again I wouldn't want to trust a site that was doing that anyway, just personally. Maybe this industry has just made me cynical and jaded, who knows... K. __ Kay Smoljak - ColdFusion Developer - PerthWeb Pty Ltd Internet Solutions for your business! Level 9/105 St George's Tc - Perth - Western Australia Ph: (08) 9226 1366 Fax: (08) 9226 1375 Mobile : 0419 949 007 Visit Perth online! : www.perthweb.com.au Tools for developers: http://developer.perthweb.com.au -- cfx_pwimageproc: image processing tool -- cfx_pwcardcrypt: credit card validation and encryption Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
Another option would be to use an asymmetric encryption method alongside the process you described before. For this you use a public key stored on the server, but to decrypt the credit card number the operator needs to type in a private key. As this key is not stored on the server there is no security risk. You would then of course have to store the numbers twice, one encrypted with the user password, and one encrypted with the public/private key pair. - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Saturday, May 05, 2001 2:14 AM Subject: Re: Credit Card DB Encryption Methodology Ok, I've been thinking about this. And in the case of returns or credits, I think we could this: On the website as the customer requests a return, they must enter their password. I store this encrypted with the RMA number (or some other associated id) as the key. Once the return is processed, the server uses the RMA number to decrypt the password to decrypt the CC info and process the credit... Now I've comprised the security of those users with pending returns, but that would be a small percentage of users at any given time. And if I'm going to use an easily available key to encrypt the password temporarily, it's almost not even worth the bother... Still thinking. OR, I would have to request the customer to login to the website and check if their return has been received, then enter their password when prompted in order to receive the credit. Another issue is that I'm locked to doing ONLY real-time processing. If the cc processing gateway is down, I can't take orders... So what are you doing in those cases, do you have to contact the customer? Curious... I thought the reason most people kept card numbers around was for handling credits, delayed charges, and other problems (or possibly because of record-keeping requirements of their bank), or because they're doing the credit card charges manually (or at least with some human intervention) rather than in real time. It doesn't seem like your solution would work in that situation. Correct, that wouldn't work here, because we don't have an unecrypted version of the user's password available. Keith C. Ivey [EMAIL PROTECTED] Webmaster, EEI Communications Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
Sounds very secure, of course you might add that the database in question should never be on a web server. The database should only be accessible from behind a firewall which permits only the web server's ip to access the database server. jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 3:52 PM Subject: Credit Card DB Encryption Methodology Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
Yes, but that's a physical architecture issue. I'm just trying to address the software side. I'm surprised there haven't been more comments on this, seems to have been a pretty hot topic. Also, I've realized no site I've been to seems to store cc info this way (because I'm not prompted for my password) so I wonder what other schemes they are using Sounds very secure, of course you might add that the database in question should never be on a web server. The database should only be accessible from behind a firewall which permits only the web server's ip to access the database server. jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 3:52 PM Subject: Credit Card DB Encryption Methodology Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
I just use encrypt/base64 to encrypt cards as sop. Here is my snippet, the key I choose randomly for each site. cfset secret_word_encrypted= ToBase64(encrypt(#string2beEncrypted#,#key#)) cfset secret_word_decrypted= decrypt(tostring(tobinary(#secret_word_encrypted#)),#key#) jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, May 04, 2001 11:43 AM Subject: Re: Credit Card DB Encryption Methodology Yes, but that's a physical architecture issue. I'm just trying to address the software side. I'm surprised there haven't been more comments on this, seems to have been a pretty hot topic. Also, I've realized no site I've been to seems to store cc info this way (because I'm not prompted for my password) so I wonder what other schemes they are using Sounds very secure, of course you might add that the database in question should never be on a web server. The database should only be accessible from behind a firewall which permits only the web server's ip to access the database server. jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 3:52 PM Subject: Credit Card DB Encryption Methodology Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
That's what I'm doing, but the problem with that is that you have to store the key, unencrypted, somewhere on the server. And one key decrypts your whole slew of credit cards. This way, there's one key for each credit card and it's not store unencrypted on the server... I just use encrypt/base64 to encrypt cards as sop. Here is my snippet, the key I choose randomly for each site. cfset secret_word_encrypted= ToBase64(encrypt(#string2beEncrypted#,#key#)) cfset secret_word_decrypted= decrypt(tostring(tobinary(#secret_word_encrypted#)),#key#) jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, May 04, 2001 11:43 AM Subject: Re: Credit Card DB Encryption Methodology Yes, but that's a physical architecture issue. I'm just trying to address the software side. I'm surprised there haven't been more comments on this, seems to have been a pretty hot topic. Also, I've realized no site I've been to seems to store cc info this way (because I'm not prompted for my password) so I wonder what other schemes they are using Sounds very secure, of course you might add that the database in question should never be on a web server. The database should only be accessible from behind a firewall which permits only the web server's ip to access the database server. jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 3:52 PM Subject: Credit Card DB Encryption Methodology Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
Yes, I agree your method is much more secure, just harder to snippetize ;-) jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, May 04, 2001 4:25 PM Subject: Re: Credit Card DB Encryption Methodology That's what I'm doing, but the problem with that is that you have to store the key, unencrypted, somewhere on the server. And one key decrypts your whole slew of credit cards. This way, there's one key for each credit card and it's not store unencrypted on the server... I just use encrypt/base64 to encrypt cards as sop. Here is my snippet, the key I choose randomly for each site. cfset secret_word_encrypted= ToBase64(encrypt(#string2beEncrypted#,#key#)) cfset secret_word_decrypted= decrypt(tostring(tobinary(#secret_word_encrypted#)),#key#) jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, May 04, 2001 11:43 AM Subject: Re: Credit Card DB Encryption Methodology Yes, but that's a physical architecture issue. I'm just trying to address the software side. I'm surprised there haven't been more comments on this, seems to have been a pretty hot topic. Also, I've realized no site I've been to seems to store cc info this way (because I'm not prompted for my password) so I wonder what other schemes they are using Sounds very secure, of course you might add that the database in question should never be on a web server. The database should only be accessible from behind a firewall which permits only the web server's ip to access the database server. jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 3:52 PM Subject: Credit Card DB Encryption Methodology Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
I'm writing a CF_ManageCC tag as part of my development, so whenever I need to do anything with a card, I just call the tag. I'll post it to the gallery when I'm done. Yes, I agree your method is much more secure, just harder to snippetize ;-) jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, May 04, 2001 4:25 PM Subject: Re: Credit Card DB Encryption Methodology That's what I'm doing, but the problem with that is that you have to store the key, unencrypted, somewhere on the server. And one key decrypts your whole slew of credit cards. This way, there's one key for each credit card and it's not store unencrypted on the server... I just use encrypt/base64 to encrypt cards as sop. Here is my snippet, the key I choose randomly for each site. cfset secret_word_encrypted= ToBase64(encrypt(#string2beEncrypted#,#key#)) cfset secret_word_decrypted= decrypt(tostring(tobinary(#secret_word_encrypted#)),#key#) jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, May 04, 2001 11:43 AM Subject: Re: Credit Card DB Encryption Methodology Yes, but that's a physical architecture issue. I'm just trying to address the software side. I'm surprised there haven't been more comments on this, seems to have been a pretty hot topic. Also, I've realized no site I've been to seems to store cc info this way (because I'm not prompted for my password) so I wonder what other schemes they are using Sounds very secure, of course you might add that the database in question should never be on a web server. The database should only be accessible from behind a firewall which permits only the web server's ip to access the database server. jon - Original Message - From: Tony Schreiber [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Thursday, May 03, 2001 3:52 PM Subject: Credit Card DB Encryption Methodology Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
On 3 May 2001, at 15:52, Tony Schreiber wrote: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. That's fine as long as the only reason you're storing the credit card number is to prevent having to ask the customer for it again the next order. But if that was the only reason for keeping the number, it seems hardly worth storing it in the first place -- just forget it as soon as you've charged the card. I thought the reason most people kept card numbers around was for handling credits, delayed charges, and other problems (or possibly because of record-keeping requirements of their bank), or because they're doing the credit card charges manually (or at least with some human intervention) rather than in real time. It doesn't seem like your solution would work in that situation. Keith C. Ivey [EMAIL PROTECTED] Webmaster, EEI Communications 66 Canal Center Plaza, Suite 200 Alexandria, VA 22314 Telephone: 703-683-0683 Fax: 703-683-4915 Web Site: http://www.eeicommunications.com ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. That's fine as long as the only reason you're storing the credit card number is to prevent having to ask the customer for it again the next order. But if that was the only reason for keeping the number, it seems hardly worth storing it in the first place -- just forget it as soon as you've charged the card. That's correct. Part of the goal for this project is to have customers ordering via WAP and we need to make that as easy as possible. I thought the reason most people kept card numbers around was for handling credits, delayed charges, and other problems (or possibly because of record-keeping requirements of their bank), or because they're doing the credit card charges manually (or at least with some human intervention) rather than in real time. It doesn't seem like your solution would work in that situation. Correct, that wouldn't work here, because we don't have an unecrypted version of the user's password available. Keith C. Ivey [EMAIL PROTECTED] Webmaster, EEI Communications Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
So what are you doing in those cases, do you have to contact the customer? Curious... By the way, I think you've done a great job of dealing with CC encryption. Good approach. Even though the major on-line vendor site that we've written doesn't do credit card processing, we still prompt for the password before the order is placed. Yeah, its a small pain for the customer, but it is a whole lot more secure Especially in this application where it is mostly college students, who may easily log in, walk away from a public terminal, and forget to logout. -Bill www.brainbox.tv snip I thought the reason most people kept card numbers around was for handling credits, delayed charges, and other problems (or possibly because of record-keeping requirements of their bank), or because they're doing the credit card charges manually (or at least with some human intervention) rather than in real time. It doesn't seem like your solution would work in that situation. Correct, that wouldn't work here, because we don't have an unecrypted version of the user's password available. Keith C. Ivey [EMAIL PROTECTED] Webmaster, EEI Communications Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Credit Card DB Encryption Methodology
Ok, I've been thinking about this. And in the case of returns or credits, I think we could this: On the website as the customer requests a return, they must enter their password. I store this encrypted with the RMA number (or some other associated id) as the key. Once the return is processed, the server uses the RMA number to decrypt the password to decrypt the CC info and process the credit... Now I've comprised the security of those users with pending returns, but that would be a small percentage of users at any given time. And if I'm going to use an easily available key to encrypt the password temporarily, it's almost not even worth the bother... Still thinking. OR, I would have to request the customer to login to the website and check if their return has been received, then enter their password when prompted in order to receive the credit. Another issue is that I'm locked to doing ONLY real-time processing. If the cc processing gateway is down, I can't take orders... So what are you doing in those cases, do you have to contact the customer? Curious... I thought the reason most people kept card numbers around was for handling credits, delayed charges, and other problems (or possibly because of record-keeping requirements of their bank), or because they're doing the credit card charges manually (or at least with some human intervention) rather than in real time. It doesn't seem like your solution would work in that situation. Correct, that wouldn't work here, because we don't have an unecrypted version of the user's password available. Keith C. Ivey [EMAIL PROTECTED] Webmaster, EEI Communications Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Credit Card DB Encryption Methodology
Ok, I've been reading the last few threads on this and pondering the best way to approach this scenario (storing CC in DB) and I've come up with the following idea: 1) The User's password is stored as a one-way HASH. 2) The Credit Card info (list of cc number,exp date and verification number) is stored as an ENCRYPTED string with the User's raw password as the key. Interface-wise, this requires that: a) the user type in their password when Adding or Updating a credit card record in the db (so it can be encrypted) b) the user type in their password when finalizing an order (so the cc info can be decrypted to be processed) c) When a user changes their password, all cc records in the database must be updated using the old and new passwords But this way, neither the users password, the encryption key nor the cc info is stored unencrypted anywhere on the server. Comments? Tony Schreiber, Senior Partner Man and Machine, Limited mailto:[EMAIL PROTECTED] http://www.technocraft.com http://www.simplemessageboard.com ___Free Forum Software for Cold Fusion http://www.is300.net ___The Enthusiast's Home of the Lexus IS300 http://www.digitacamera.com __DigitA Camera Scripts and Tips http://www.linklabexchange.com _Miata Link ECU Data Exchange ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
