I recently had to revisit the estimates I provided in our white paper on brute forcing credit card hashes since new techniques were published that can speed the brute forcing up by at least a factor of 5 using off-the-shelf video cards.  Well, a month later I am having to revise the estimates again.  Nick Breese of New Zealand has published a paper at Kiwicon on using a PlayStation 3 to crack hashes.  His estimates are about 1.4 billion hashes per second for MD5.  Our proof of concept code running at about 2 million hashes per second seems kind of slow now.  Probably at least 2 billion hashes per second is feasible in the near future with readily available hardware and source code.

Storing credit cards using a simple single pass of a hash algorithm, even when salted, is fool-hardy.  It is just too easy to brute force the credit card numbers if the hashes are compromised.  Based on the potential value of the card numbers, there is more than enough financial incentive to buy a $500 PlayStation 3 and develop a little code.

When hashing credit card number, the hashing must be carefully designed to protect against brute forcing by using strongest available cryptographic hash functions, large salt values, and multiple iterations.

This past March, I published a white paper looking at how some applications hash credit card numbers and how vulnerable these hashes are to brute forcing.  I developed a proof of concept to roughly estimate the timings (about 2 million hashes per second).  Looking ahead, I estimated with additional optimization, multi-threading, and faster processors probably 50 million hashes per second is achievable.

Well, I was probably off by a factor of at least 5 on my future estimate.  Elcomsoft announced this week that it has filed a patent for a technique to use the "massively parallel processing" capabilities of the GPU on a video card to brute force passwords.  Others have also been doing research in this area.

A better estimate is at least 200 million hashes per second for a single pass of SHA-1 or MD-5 and I wouldn't be surprised if someone could achieve 500 million hashes per second in the near future.  This would allow someone to brute force all possible unsalted SHA-1 hashes in just 10 days rather than 3 years.  Adding intelligence with regards to brands and common issuing bank prefixes, most of the brute force times are reduced to minutes or seconds.  Storing plain-text digits (prefix and/or last 4) makes brute forcing a trivial exercise.

When hashing credit card number, the hashing must be carefully designed to protect against brute forcing by using strong cryptographic hash functions, large salt values, and multiple iterations.

Cryptographic hash functions seem to be an ideal method for protecting and securely storing credit card numbers in ecommerce and payment applications. A hash function generates a secure, one-way digital fingerprint that is irreversible and meets frequent business requirements for searching and matching of card numbers. However, due to the predictability of credit card numbers and common business requirements in processing credit cards, ecommerce and payment applications may implement such hashing of card numbers in an unsafe manner that allows an attacker to obtain a large percentage of card numbers by brute forcing compromised hashes in a matter of hours.

To provide more information on this issue, Integrigy has released a whitepaper that is an analysis of actual application practices for storing of credit card number hashes and a review of brute force attack methods against such hashes.  The impetus for this paper was identification of this issue during multiple application security assessments.

The bottom-line is that storing of credit card numbers by simply hashing only the card number is unacceptable and can be easily compromised by brute force methods. An attacker who is able to compromise the application or database can obtain many card numbers in a trivial amount of time –

• If only the hashed card number is available, it is actually practical to obtain all 14 and 15 digital card number hashes in less than thirteen days.
• If only the hashed card number is stored, an attacker can potentially obtain 30-70% of all card numbers within a matter of hours by intelligently focusing on the most popular card brands and issuing banks.

• If the Prefix 6 + Last 4 digits are known, all card numbers can be obtained in less than 2 hours.

Application developers can not rely on simple hashing methods and must build-in protections against such brute force attacks on compromised card numbers.

Whitepaper: Hashing Credit Card Numbers: Unsafe Application Practices

The recent OAUG "Automating Compliance Survey" (OAUG login required) showed 7% of the organizations surveyed responded as being compliant with the Payment Card Industry (PCI) Data Security Standard (DSS), while 19% were in the process of planning or implementing and 71% were either not planning or not sure about PCI compliance.  Having 71% of the organizations respond "not planning/not sure" seems a little high to me since all Oracle Applications implementations that "store, process, or transmit credit card data" must comply with Payment Card Industry (PCI) Data Security Standard 1.1 regardless of size or transaction volume.  This means 71% of the respondents either don't handle any credit cards in their Oracle Applications environments or there were a lot of "not sure" responses.

Let me step back first and provide a brief background of PCI compliance.  The PCI Data Security Standard (DSS) 1.1 is a set of stringent security requirements for networks, network devices, servers, and applications.  The standard details specific requirements in terms of security configuration and policies and all the requirements are mandatory.  PCI DSS is focused on securely handling credit card data, but also has a significant emphasis on general IT security.  Even if you are not required to have annual on-site audits, perform quarterly scans, complete annual self-assessment questionnaires, or submit compliance documentation, "nevertheless must comply with, and are subject to liability under, all other provisions of" the then-current Payment Card Industry Data Security Standard.

The difficultly with Oracle Applications and achieving PCI compliance is that even though credit card processing may be only a one minor feature of the application, the entire application installation must be fully PCI DSS compliant due to the tight-integration and data model of Oracle Applications.  One of the key requirements is that all credit card numbers are encrypted in the database and only recently has Oracle included such functionality in Oracle Applications.

For those organizations that have completed SOX audits and remediation, the level of difficulty associated with PCI compliance is in the eye-of-the-beholder.  For those IT managers and DBAs who struggled with broadness and poor definition around SOX requirements will welcome PCI as it is a well-defined and documented standard.  On the other hand, it provides for few exceptions related to compensating controls.

To help Oracle Applications implementations sort through PCI compliance issues, we have compiled from some recent work general guidance for each PCI requirement related to the installation and configuration of Oracle Applications.  This whitepaper also provides details on the Oracle Applications Credit Card Encryption Patch (see Metalink Note ID 338756.1).

Whitepaper: Oracle Applications 11i: Credit Cards and PCI Compliance Issues