BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Obligations for storing credit card numbers Goto page 1, 2, 3  Next          BorlandTalk.com Forum Index -> Delphi Non-Technical View previous topic :: View next topic   Author Message Stuartj Guest Posted: Wed May 24, 2006 1:14 am    Post subject: Obligations for storing credit card numbers Hi all, im currenlty havng discussion with collegues in regard to our oligation (legal and otherwise) to storing credit card numbers. Ive tried to do some searches to find out exactly how this kind of sensative data should be stored in a database, but havent been able to find anything that specifically outlines minimum requirements etc. We all agree that the information must be encrypted to some degree, but cant agree on the level of encryption. We need to be able to decrypt the information, so one-way encryption is no good. If anyone has experience in this area and could advice me of any particulars, it would be appreciated. Oh, we develop in AU, but our software is distributed internationally as well as locally. So any input is welcome as it will all be relevent. regards Stuart Back to top Stuartj Guest Posted: Wed May 24, 2006 2:14 am    Post subject: Re: Obligations for storing credit card numbers "Marc Rohloff [TeamB]" <"on request"> wrote in message news:byj37roczgii$.dlg (AT) dlg (DOT) marcrohloff.com... Quote: On Wed, 24 May 2006 11:05:59 +1000, Stuartj wrote: im currenlty havng discussion with collegues in regard to our oligation (legal and otherwise) to storing credit card numbers. Ive tried to do some searches to find out exactly how this kind of sensative data should be stored in a database, but havent been able to find anything that specifically outlines minimum requirements etc. We all agree that the information must be encrypted to some degree, but cant agree on the level of encryption. We need to be able to decrypt the information, so one-way encryption is no good. If anyone has experience in this area and could advice me of any particulars, it would be appreciated. Oh, we develop in AU, but our software is distributed internationally as well as locally. So any input is welcome as it will all be relevent. It is usually preferable not to store them at all. It should be sufficient just to store the reference number provided by the card agent. -- Marc Rohloff [TeamB] marc rohloff -at- myrealbox -dot- com Hi Marc, agreed but unfortunately this isnt/wasnt my call......So im just trying to make sure what we do store, is stored correctly. Stuart Back to top Marc Rohloff [TeamB] Guest Posted: Wed May 24, 2006 2:14 am    Post subject: Re: Obligations for storing credit card numbers On Wed, 24 May 2006 11:05:59 +1000, Stuartj wrote: Quote: im currenlty havng discussion with collegues in regard to our oligation (legal and otherwise) to storing credit card numbers. Ive tried to do some searches to find out exactly how this kind of sensative data should be stored in a database, but havent been able to find anything that specifically outlines minimum requirements etc. We all agree that the information must be encrypted to some degree, but cant agree on the level of encryption. We need to be able to decrypt the information, so one-way encryption is no good. If anyone has experience in this area and could advice me of any particulars, it would be appreciated. Oh, we develop in AU, but our software is distributed internationally as well as locally. So any input is welcome as it will all be relevent. It is usually preferable not to store them at all. It should be sufficient just to store the reference number provided by the card agent. -- Marc Rohloff [TeamB] marc rohloff -at- myrealbox -dot- com Back to top Marc Rohloff [TeamB] Guest Posted: Wed May 24, 2006 2:14 am    Post subject: Re: Obligations for storing credit card numbers On Wed, 24 May 2006 11:36:50 +1000, Stuartj wrote: Quote: "Marc Rohloff [TeamB]" <"on request"> wrote in message but unfortunately this isnt/wasnt my call......So im just trying to make sure what we do store, is stored correctly. Since you require a reversible encryption I would assume something like triple-DES or blowfish would be fine. The biggest issue you need to solve is how you are going to safeguard the key. However no matter what you use, since you are only encoding 16 characters and they are a limited set (0-9), a brute force attach would be relatively easy. I would suggest that you prefix your number with some sort of salt (random data) to make it more difficult. I am sure that Google would turn up quite a few solutions to this. -- Marc Rohloff [TeamB] marc rohloff -at- myrealbox -dot- com Back to top Stuartj Guest Posted: Wed May 24, 2006 3:14 am    Post subject: Re: Obligations for storing credit card numbers Quote: However no matter what you use, since you are only encoding 16 characters and they are a limited set (0-9), a brute force attach would be relatively easy. I would suggest that you prefix your number with some sort of salt (random data) to make it more difficult. I am sure that Google would turn up quite a few solutions to this. -- Marc Rohloff [TeamB] marc rohloff -at- myrealbox -dot- com Thanks Marc, this is the kinda of method ive proposed but have been shouted down as it increases the length of the original string representation, which would require a change to the field length in the database...a ridiculous argument for my money. But this is why i was trying to work out what if any legal requirements we must observe. thanks agian stuart Back to top Medbob Guest Posted: Wed May 24, 2006 3:14 am    Post subject: Re: Obligations for storing credit card numbers ToDo: 1. Find some way to get the DBAs off of the project..... Back to top Bob Dawson Guest Posted: Wed May 24, 2006 4:14 am    Post subject: Re: Obligations for storing credit card numbers "Stuartj" wrote Quote: tried to do some searches to find out exactly how this kind of sensative data should be stored in a database, but havent been able to find anything that specifically outlines minimum requirements etc. We all agree that the This is a pretty significant question of liability.The only advice you should accept on non-tech is to see a good lawyer that knows this issue. bobD Back to top Roger Lascelles Guest Posted: Wed May 24, 2006 4:14 am    Post subject: Re: Obligations for storing credit card numbers "Marc Rohloff [TeamB]" <"on request"> wrote in message news:bxqo7qq91746.dlg (AT) dlg (DOT) marcrohloff.com... Quote: On Wed, 24 May 2006 11:36:50 +1000, Stuartj wrote: Since you require a reversible encryption I would assume something like triple-DES or blowfish would be fine. The biggest issue you need to solve is how you are going to safeguard the key. I think the poster means he needs to decrypt the information, not just store a hash to prove a number is valid. That means he can use asymmetric encryption like RSA, if he likes - that way the decoding key could even be totally off the server. This whole thing leaves me cold - get a single key and you can decode the whole lot. You will want a CGI or ISAPI or server EXE, not something with potential loopholes like PHP. Roger Lascelles Back to top Chris Burrows Guest Posted: Wed May 24, 2006 5:14 am    Post subject: Re: Obligations for storing credit card numbers "Stuartj" <stuartjatcmshospdotcomdotau> wrote in message news:4473b154 (AT) newsgroups (DOT) borland.com... Quote: Hi all, im currenlty havng discussion with collegues in regard to our oligation (legal and otherwise) to storing credit card numbers. Oh, we develop in AU, but our software is distributed internationally as well as locally. So any input is welcome as it will all be relevent. Refer to the Payment Card Industry Data Security Standard (PCIDSS): http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf -- Chris Burrows CFB Software http://www.cfbsoftware.com Back to top Henrick Hellström [Stream Guest Posted: Wed May 24, 2006 7:14 am    Post subject: Re: Obligations for storing credit card numbers Chris Burrows wrote: Quote: Refer to the Payment Card Industry Data Security Standard (PCIDSS): http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf That is good advice (legal and otherwise), but I think the paragraph 3.4 misses the best option for storing credit card information, namely asymmetric encryption, such as RSA-OAEP using a RSA public key you store on the server. This means you can decrypt the information later, but only from somewhere where you got access to the corresponding private key, such as a back end management computer. Back to top TObject Guest Posted: Wed May 24, 2006 7:14 am    Post subject: Re: Obligations for storing credit card numbers As far as obligations go you can look at it this way: if somebody steals your customers' credit card numbers from you, as a merchant you will be responsible for 100% of fraudulent charges, plus investigation costs. So, basically, it is in merchants' best interests to make sure credit card information doesn't get into wrong hands. Back to top K. Sallee Guest Posted: Wed May 24, 2006 9:14 am    Post subject: Re: Obligations for storing credit card numbers Quote: storing credit card numbers. <quote> "Today, the requirement is to make all information unreadable wherever it is stored," Maxwell said. But this encryption requirement is causing so much trouble for merchants that credit card companies are having trouble dealing with requests for alternative measures, he said. In response, changes to PCI will let companies replace encryption with other types of security technology, such as additional firewalls and access controls. .... Retailers that don't comply may face penalties, including fines. </quote> http://news.com.com/Credit+card+security+rules+to+get+update/2100-1029_3-6072594.html?tag=nefd.top But, unless you have a very good reason to store CC numbers such as selling a subscription or other method that requires automatic renewal, I ask, why bother with the cost of management and its risks: https://secure.booklocker.com/secure.html Kevin Back to top Jim Cooper Guest Posted: Wed May 24, 2006 9:14 am    Post subject: Re: Obligations for storing credit card numbers Quote: Oh, we develop in AU, but our software is distributed internationally as well as locally. You may ned to take into account local laws, or at least allow for whoever buys your software to comply with local laws. In the UK there is the Data Protection Act, for example, which applies to any companies storing personal information. Cheers, Jim Cooper _____________________________________________ Jim Cooper jcooper (AT) tabdee (DOT) ltd.uk Skype : jim.cooper Tabdee Ltd http://www.tabdee.ltd.uk TurboSync - Connecting Delphi to your Palm _____________________________________________ Back to top Henrick Hellström [Stream Guest Posted: Wed May 24, 2006 10:14 am    Post subject: Re: Obligations for storing credit card numbers K. Sallee wrote: Quote: quote "Today, the requirement is to make all information unreadable wherever it is stored," Maxwell said. But this encryption requirement is causing so much trouble for merchants that credit card companies are having trouble dealing with requests for alternative measures, he said. In response, changes to PCI will let companies replace encryption with other types of security technology, such as additional firewalls and access controls. /quote I guess the credit card companies have discovered that 99% of the vendors who *do* apply encryption don't apply "proper key management". For instance, how many of you store the encryption key in an ASP or ASP.NET script on a website that has FrontPage Server Extensions installed? If the hacker is able to steal the encryption key together with the encrypted credit card numbers, the encryption obviously doesn't add any security anyway. Back to top Craig Stuntz [TeamB] Guest Posted: Wed May 24, 2006 1:14 pm    Post subject: Re: Obligations for storing credit card numbers TObject wrote: Quote: As far as obligations go you can look at it this way: if somebody steals your customers' credit card numbers from you, as a merchant you will be responsible for 100% of fraudulent charges, plus investigation costs. That's not how I read the fair credit billing act. Got a citation? -- Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz Everything You Need to Know About InterBase Character Sets: http://blogs.teamb.com/craigstuntz/articles/403.aspx Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi Non-Technical All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.