Now, the report doesn’t provide us a breakdown of cost to U.S. businesses but if the total costs are even half the reported estimate, it would seem that there just may be a compelling cost-benefit argument to changing the payment infrastructure.

Using a one-time PIN generator is another good approach, but EMV with dynamic data authentication is excellent and it’s already a standard that is being deployed in many markets.

The technology I am referring to uses a bank-owned and customer-carried one-time-PIN generator. Not only is it secure in a hostile retail environment, but can also be safely used over the web.

Likewise, regarding recurring & hotel transactions, of course those are supported. Do you think they don’t do those things outside the USA???

There are much less costly solutions currently available. Someone already mentioned the “format preserving encryption.” There are encryption drivers at the point of the swipe, there are hardware encrypted swipe devices. Heck, simply requiring end-to-end encryption on local networks (hardware or software), most likely would have prevented the Heartland and Hannaford breaches and others.

Lastly, to my knowledge, chip & pin does not address ecommerce, recurring, or hotel environments (check-in/check-out) so you’re still going to need a secure “other” system.

“Again, your suggestion leaves the burden of handling sensitive data in the retailer’s POS system, although for less time exposed than it does today. It doesn’t stop skimmers from being effective. It doesn’t stop insecure POS systems from leaking data. It doesn’t stop fraudulent merchants from stealing data. By moving it to the card, owned by the customer and protected by the bank, the protection is in place before it hits any of the retailers or processors. All these problems are solved.”

First, the approach described encrypts after swipe – it does not require sensitive data to be stored and managed by the POS -this is an inherent property of IBE (a Public Key Technology).

However, anything that sits either photographing the card from above (to OCR read it as its swiped, and perhaps also recording the PIN as its entered) or similar skimming techniques are always feasible if the cardholder data is static and presented to a device as it is today – but that kind of attack is more expensive to mount – each POS line or lane has to be compromised. Contrast this to attacking the core data repository of a vast array of cards then clearly one is more lucrative and more a target than the other.

I’ve even seen cases where entirely fake card readers and POS devices have been installed in merchants to allow payments yet siphoning off cardholder data for later upload – cases in Hong Kong in the 1990′s for example. Its not a new attack vector – its classic interception, clever hacking, and social engineering at play.

The key to managing large scale breaches however is to mitigate risk, and make attacks more expensive, more complex, and easier to detect and thus less attractive than other data targets. Nothing is perfectly secure – security is an issue of time and money of an attack.

In respect to the encrypt at Chip – This is clearly a vision of the card issuers, but the simple fact is that this is a very long term strategy, and until the entire world is uniform, the current problem of mag stripe swipe call back and the related data risks will be ever present. The standards around this also vary – Dynamic vs static authentication of chip, application on chip, POS application, clearing application, and static card identity material – perhaps these need revisiting now against current threats – EMV assumes many trusted environments. This is a **huge** investment – multiple tens of billions – in a hard economic climate.

However, if we are to solve and mitigate threats that exist *now* against systems in place *now* we need to step back from purism, and take pragmatic and tactical steps with an eye on what may come.

I have exprience these systems first hand – right down to the Silicon and OS level with experience in Mondex, Visa Cash, MULTOS, EMV, GSM SIMs, Digicash etc – at a standards level and at implementation level. Chip itself isn’t just the answer, but its a technology that can help. Think also how you use your nice Visa Chip cards or Amex Blue cards to buy on amazon.com for instance….today in your own country that mandates and has implemented C&P….its been the “year of the smartcard” for a couple of decades now!

Hacks have moved to making physical changes to the chip & pin terminal in store to capture the card number from the stripe or chip and the PIN from the keypad. There has even been a batch of terminals with hacker module installed somewhere in terminal supply chain, only easily detectible by weighing the terminal hardware (Google “Shell PIN hack” for some details). And more hacks now happening to card not present commerce like mail order, phone order & support (call centres around the world) & websites.

The main exploit is once you have card number and PIN (from a hacked C&P terminal or by very good video camera observation e. g. at an ATM), you can create a non-chip magstripe card and use it in ATM machines in countries that don’t support Chip & PIN yet or where ATM has fallback to magstripe where chip can’t be accessed, and then draw funds.

So lack of adoption of C&P in USA actually HURTS people in countries that have C&P!

Being good for only one transaction means just that: even if it’s sniffed, only the original transaction goes through. A second transaction with the same authorization code is blocked by the bank. Sniffing these transactions is safe.

@Cory Altheid,
These devices do not contain one-time pads, which is a completely different algorithm. These are devices that generate pseudo-random numbers and encrypt them using a private key stored in the smart card. I don’t want to get into a long discussion of the cryptography, but the end result is the only two cryptographic devices used in these transactions are both owned and secured by the bank. The only security required of the retailer is that needed to prevent a third party from collecting the payment from the customer instead of the retailer, and that’s the retailer’s problem, not the customer’s.

@Mark Bower,
Again, your suggestion leaves the burden of handling sensitive data in the retailer’s POS system, although for less time exposed than it does today. It doesn’t stop skimmers from being effective. It doesn’t stop insecure POS systems from leaking data. It doesn’t stop fraudulent merchants from stealing data. By moving it to the card, owned by the customer and protected by the bank, the protection is in place before it hits any of the retailers or processors. All these problems are solved.

Regards,
Archie Kline
archiekline@gmail.com

File intergrity systems that are signature and rules based may seem less susceptable to false positives but that may be because the rules are too simplistic.

It all boils down to due diligence by humans, there is no technological magic bullet.

What I haven’t seen answered here is how the malware was installed on the server in the first place. No matter what the OS, the fundamentals to protecting the server should still apply: uninstall non-essential software (if this server had email/browser installed – shoot that IT “pro”), disable non-essential services, isolate from both public and private networks with firewalls locked down to the barest minimum of open ports and even these ports should only be open to specific IP addresses. Unless this was an inside job (and nobody seems to be suggesting that it was), the opportunity for an external attack is almost nil if best practise is followed. I’m guessing now, but my guess is that the server wasn’t sufficiently protected from the rest of Heartland’s private network and the malware was planted via a compromised end user machine.

Traditional approaches to encryption suffer complexities that hamper success, scale, and meeting end-to-end protection: key management complexity and the diversity and legacy nature of most IT/Processing systems make traditional encryption difficult to deploy (ancient Non-stop systems anyone? :-). In addition, regulatory compliance with e-discovery/forensic and data recovery needs can be make investigations and contemporary real time fraud analysis extremely difficult.

There is a method called “Format Preserving Encryption” of using 256 or 128 bit for that matter AES Encryption which can be used in such a way as to encrypt any field (PAN, Expiry, Name, Address, SSN, National ID number etc) without changing its structure, without sacrificing strength whilst retaining format and referential integrity – even across data stores. Sub fields of a data structure like a PAN eg. Issuer/Routing data can be independently encrypted to the 6 digit account code, last 4 and so on, or certain segments can be left in the clear, and in practical implementation different roles and permissions can be applied to each encrypted field or sub field to permit “need to know” access controls from system or person to data.

This method is also being considered as part of the US NIST AES Standard (FFSEM mode AES). In essence this now enables direct encryption in place with an existing data structure or field and eliminates the need for tokenization databases and lookups – as the 256 bit AES space is the token map per 256 bit key. This allows POS capture to clearer end to end protection – but without impacting intermediate systems – key management and rollover is also completely handled, and in fact stateless. The technique of FPE is provably secure to the same strength as regular block mode AES – hence the NIST interest.

In terms of solving the key distribution issue and handling rollover, there is a public key technique called Identity Based Encryption (IBE). IBE permits any string – e.g. an email address, a serial number, a unique identifier etc or even a variable string like “serial number + date” to be used as a direct public key – the corresponding private key can be derived in near real time from a key server (somewhat analogous to a Root CA in traditional PKI) after authentication. This stateless approach also simplifies operations – no key database to manage or Secure or continuously sync to DR sites and so on.

So, FPE allows direct encryption – e.g. from POS to the back end – clearer/acquirer. IBE combined with FPE can also solve some difficult challenges, such as when POS systems have no ability to secure a key locally, offline POS cases and card capture in low cost mobile devices.

Fortune 500 Firms/Tier 1 merchants do in fact use these techniques to address large scale complex privacy regulations such as PCI DSS, GLBA, HIPAA etc.

So, other than merchants who copy the plastic in the store (small volume threat)- the problem of protecting vast data sources such as transactions systems at rest, in motion, and in use is a solvable problem – and in a practical and economical manner.

However – it would be an excellent security measure to put in place since to deter criminals with a financial motive you simply have to make the cost of acquiring the data illicitly greater than the payoff. Right now attackers are capable of running off with hundreds of thousands of cards by compromising a handful of machines. Riding an existing authorized transaction and adding a fraudulent transaction *should* be exceedingly difficult, time consuming, and of little reward if OTP were implemented properly.

What about a very simple tool such as an integrity checker that tells you about new files, deleted files, modified files, or any changes to critical files.

I was taught that was a basic standard to have such tool.

I guess they are not as sexy as IPS and this is why people do not use them. Even the most basic Host Based IDS would have detected such pattern.

Keep it simple

Clement

It only takes one transaction for someone to steal your money…Also, its good for a single transaction ANYWHERE (as apposed to per-merchant-passwords). If the data can be sniffed, it can likely be intercepted, so subvert the order information (e.g. product and/or delivery address).

Oh, and I’m sure people will end up losing PINs because of dirty fingerprints left on the keypad that lives on their credit-card! Will make the card itself more valuable, increasing the physical danger to cardholders.

That’s just more of the same “pile on the protection” mentality that leaves us exactly where we are today. So we encrypt data at a few more points, but then we decrypt it just before it leaves our system so it can travel SSL to a processor, who extracts the cleartext data and then reencrypts it. We’ll spend a million dollars to achieve this, we’ll spend another million having the PCI auditor bless and approve it, and the attackers will simply shift their attack to the decryption point. Millions of dollars more will be spent, and hacks will still happen.

But they can be stopped completely.

There is cryptographic technology in use today by some European banks that use a smart card to produce a one-time-use “authorization token”. The token generation happens only when the cardholder enters their PIN into their card — not the merchant’s terminal. The card is hardware owned by the bank, contains a private key injected by the bank, and is quite secure. The decrypting side is also hardware owned by the same bank, and is also secured by them. The authorization data itself is good for a single transaction, and it does not matter if it is sniffed by an attacker — it is only good for a single transaction.

With this change, merchants and processors can hand card numbers around with no particular caution. The card number itself is useless for trade without the authorization to use it.

The security of the system becomes the sole responsibility of the bank, and happens only inside bank-owned and controlled hardware. Neither retailers nor payment processors have to go through heroics to guard the data.

This technology is not ground-breaking. It is in use today. It could theoretically be adopted bank-by-bank with no changes to retailers’ POS systems by using the existing PIN equipment to carry the new authorization data.

What is lacking is the will to change the current process because we don’t think it hurts bad enough, but mostly because we are terrified of making a real change. Well, PCI compliance is taking money from all our pockets. That hurts plenty these days. And the change doesn’t mean the end of easy-to-use credit. It would add immeasurably to consumer confidence in the use of credit, strengthening web sales and reducing customer fears of “will this waiter skim my card?”

Each device or application that takes payment should encrypt data that is being transmitted and should require SSL as well. This isn’t hard to implement and shouldn’t be expensive. Today the information is tranmitted over public lines, phone or internet. to the procesosr. Once the processor receives it, it is transmitted for authorizaton over a secured dedicated network, or it should be. The point of encryption is at the device / application and dencrypt at the
processor.

PCI does have a number of valid regulations, however, PCI is only worried about the Network and the card information, Not how the card number is transmitted and Not what is required for a safe transaction, SSL and SSL2 have been hacked for years.

Multiple databases should be required, one for the card the other for the cardholder and one for the transaction. The cardholder information if stored should be encrypted as the cardnumber. No where should any part of the card information be stored. Transaction data, such as total cost, tax, order number, etc… can be stored unencrypted.

Decisions have to be made on what is required for safe transaction or what is required to identify and market consumers. Both can live in the same world but they are seperate processes that required seperate security.

In addition, not only would the banks would become the primary focus of attack (and they’re better at defense than retailers,) a breached bank could expose only their set of customers. There would be no cases of 100 million unrelated cardholders’ data leaked.

The very idea that six million web sites, one million retailers and hundreds of payment processors can all be 100% airtight 100% of the time is ludicrous. The idea that we all have to spend millions of dollars protecting our systems from something that we shouldn’t even have to concern ourselves over is maddening, and borders on extortion. Rolling over and saying “the status quo is fine” is to continue to pile on the costs with no end in sight.

Even with no costs associated with fraudulent card use, we’re still pouring serious money down the drain on PCI assessments. I believe we could have converted our systems to handle secure payment authorizations for less than 25% of the cost that we’ve spent complying with PCI so far. And our PCI auditors will be back for the 2009 season beginning in a month or so. There goes more money that we can ill afford to waste.

And I should think the payment processors would rejoice in such an upgrade, instead of opposing it. Protectionism shouldn’t enter into the equation. The value they add today is not in the secure handling of data, but in the consolidation of communications to the thousands of member banks and the aggregation of the payment process. In the future, their role might even evolve to become the guarantor of a bank’s legitimacy, protecting merchants from potential fraudulent “pop-up bank” attacks. I know retailers don’t have the capacity to evaluate every new bank that comes along.

Merchants and processors should band together to demand these changes from the card associations and banks, and soon. We have to end the waste while we’re still solvent.