You found me!

Congratulations, you found me!

For any new viewers, I recently moved from shift4sms.blogspot.com to here, paymenttidbits.blogspot.com.

Stand Up and Be Heard

While not directly "payments related," this is something that affects all industries. Don't let the bad guys win. Stand up and let your voice be heard. In November, vote out the corruption -- from both parties.

If your politicians believe they are smarted than the people they supposedly represent - then stand up and let them know how naive¹ they really are. If your politicians believe processes defined in the Constitution are only there as barriers for the unimaginative - then voice your concern. If your politicians believe ramming things through by any means, including bribes, kick backs, favors, arm twisting, threats of prosecution - then vote them out in November. If your politicians believe that the national debit is someone else's problem so spend while the spending is good - then definitely let them know now and vote them out in November.

Lastly, if you think that government is the solution for all problems and the free stuff politicians are promising to provide is truly free, then stay at home on election day - because nothing is truly free. As the famous quote goes: "Government is not the solution to our problem; government is the problem."

¹ Ongoing theme from a previous thread; but this time I am mean the www.dictionary.com definition.

Hitler and Cloud Computing Security

Ok. I found this You Tube video via a post on Evan Schuman's StorefrontBacktalk blog which was found via a post on Bruce Schneier's blog which was found via who knows. Anyway, it's funny and a must see -- if you're a Internet nerd/junky like me:

Hitler and Cloud Computing Security

Security Hole -- Coming to a store near you!

Over the last few years Cambridge University has uncovered a few weaknesses in the EMV technology (a.k.a. Chip & PIN). Just recently they uncovered the biggest flaw yet: EMV is susceptible to a man-in-the-middle attack.

The BBC story can be found here along with a video showing the vulnerability in action: http://www.bbc.co.uk/blogs/newsnight/susanwatts/2010/02/new_flaws_in_chip_and_pin_syst.html

This latest vulnerability appears to be a devastating blow to the primary supporters of the technology -- the banks. Banks are always keeping an eye out for shifting liability from the banks, to, well anyone but the banks. Chip & PIN was the perfect vehicle for this liability shift. Virtually overnight (relative term, overnight in bank time is a 4-8 years in real time) the banks in Europe shifted fraud liability from them to the card holder or the merchant, depending on whether or not the merchant used EMV technology.

After some consumer complaints, bank regulators put some of the liability burden back onto the banks, at least requiring them to provide some proof in the event of a cardholder report of fraud. Now with this latest man-in-the-middle vulnerability, it appears that the liability is firmly back onto the banks.

Most likely a patch will be found for the latest vulnerability, but at what cost to the merchant? They just spent a big chunk of change when they were forced to upgrade to EMV. What will the fix cost them and how long will they have to implement the fix? Canada is currently in the process of forcing their merchants to implement EMV technology. How will this affect the rollout? All big unknowns.

Round 3, Tokenization vs. End-to-End Encryption

Before I get started, a disclaimer. I am a firm believer in a layered security approach. I have said several times, end-to-end encryption (E2EE) has a very important roll in the "optimum" payment security environment. E2EE, by itself, is not a silver bullet. Similarly, tokenization, by itself, is not a silver bullet either. However, if for some reason you are evaluating tokenization OR E2EE, I argue that a properly implemented front-end tokenization solution will reap more rewards than an equivalent E2EE solution.

Round 1: Tokenization enters the payment space. Shift4 releases tokenization to the public domain in October 2005. Initial document described back-end tokenization to address data storage. Since that time, technology has evolved to include front-end tokenization, which addresses data in flight as well as storage.

Round 2: End-to-End Encryption enters the payment space. In March 2008, VeriFone announces it joint end-to-end solution with Semtek. In June 2009, Heartland Payment Systems announces its entry into the E2EE arena with Voltage and E2EE, at least how we know it in the payments space is born.

Round 3: End-to-End proponents lobby PCI to deem E2EE data out-of-scope for PCI, similar to tokens. Recently PCI SSC appears to have conceded in a FAQ entry: "However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it." I believe security wise, this is a mistake and this is an example where "security" and "compliance" go separate routes.

So we are all on the same page, let me first briefly explain the difference between tokens and encrypted data. True tokens (I specify "true" because some tokenization vendors do not follow the definition of token) are not derived from the data it is protecting. A true token is simply a reference to the card data that is stored within a fully PCI compliant system. The token can be a sequential number (1=first card number swiped, 2=second card number, etc.), or it can be a time stamp, a random number, or any combination. The key is that the token is in no way derived from the card number and instead is only a reference to the card information.

Encrypted data, on the other hand, is directly derived from the original data – the card number. A key is used to encrypt the data, and either the same shared key or a related public/private key is used to decrypt the data. What keeps the data safe is the strength of the encryption method used, and the keys themselves. If the keys are ever compromised, the data is no longer safe.

The issue for me here is the decree from PCI SSC, "encrypted data may be out-of-scope." Many will read this statement and a light bulb will pop on: "silver bullet!" This type of thinking can be detrimental to the overall security risk of the card holder data.
Encrypted data can always be decrypted. Whenever I mention this, it triggers an immediate response from various encryption experts about how brute force attacks will take hundreds to billions of years to crack based on today’s technology. Maybe true, if you are only talking about brute force attacks and ignore any possibility of a encryption algorithm weakness (MD5 comes to mind). Also, a brute force attack is not the easiest way to get an encryption key. Key storage and key management are the weakest points of most encryption solutions. My point is, if the key is ever compromised by any means, the encrypted data can be decrypted and is therefore vulnerable.

Now we go back and look at how PCI SSC’s decree affects security. If E2EE data is out of scope, this information can be stored, logged and freely distributed – after all it is out-of-scope. Does this sound secure – especially if you consider encrypted data can always be decrypted?

One aspect where the jury might still be out: Will the card brands take the same stance? If and when this out-of-scope data is ever compromised, this stance would in effect be a safe harbor clause; the card brands have avoided safe harbor clauses for merchants like the plague. Breach equals fine and I don't see the card brands honoring any out-of-scope decree from PCI SSC as a safe harbor.

As I stated in the beginning, a layered security approach is the best. If it’s a one or the other decision, you know my recommendation. If you decide to go the E2EE route, my recommendation would be to ignore PCI SSC in this case and instead treat E2EE data as in-scope.

Until next time…

What a Rip!

For the most part, you can file this post in the who cares category -- Steve is just being a cry baby -- but I thought I would take a break from ticking off POS vendors, and instead tick off a competitor. If you don't have time to waste reading non-important stuff, simply come back later and I'll be sure to have a more important topic posted. Notice the byline above, "random thoughts" and "simply vent" -- this qualifies for both.

Do you ever get that feeling you're being watched? Not watched as in big brother is watching (but come to think of it, I think they are!). But more watched like in a little Chihuahua staring at you from the ground below while you are eating. But then the little rodent gets impatient, it tries whatever it can to either get your attention, or better yet, distract you in the hopes you drop some crumbs it's way.

I get that feeling with one of Shift4's competitors, X-Charge by CAM Commerce Solutions. In the past they have covertly hired employees from Shift4 -- not for their technical skills, sales prowess, or expertise, but simply for their knowledge of trade secrets and customer lists (it's strange, how these ex's move on after their information ceases to be relevant due to time). Imagine my surprise when Shift4's marketing director sends me a link to their site and now the covert is actions have switched to overt actions by ripping content straight from Shift4's site and putting it onto their site. But I'm not talking features and benefits, or even catchy phrases or graphics; ripping off stuff like this is far too often common on the Internet. No, they rip partner lists for republication and don't even have the time to reorder them or remove little asterisks that signify something on Shift4's site but not on theirs. Talk about "me too" marketing!

Shift4: http://www.shift4.com/pos_pms.htm
X-Charge: http://www.x-charge.com/products/listHospitality.asp (cut & paste the URL yourself, I don't want to give them the benefit of a search engine boost)

Some interesting points of fact, many of the partners listed on both sites have exclusive partner arrangements with Shift4. Several listed are custom interfaces that only interface to Shift4's DOLLARS ON THE NET. Some listed are no longer in business and are only listed on Shift4's site because there are customers still using the applications. Lastly, if you were to call most of the vendors on the list you'll find they never heard of X-Charge and will confirm there is no existing interface. If you call CAM Commerce, they will most likely tell you that they will work with any of the vendors listed (as opposed to they currently work with the vendors).

In a prior post, I prematurely used labeled a vendor as "unscrupulous" without considering all the possibilities for the vendor's action. In this case I don't think I would be out of line using this word -- I think this vendor is unscrupulous (not to mention lazy). If you are in the market for a payment gateway, you may want to cross these guys off your list.

Merchants beware when shopping for something as important as a payment gateway provider. If the provider gives references or lists interfaces, do some fact checking for yourself. Call some and if facts don't agree, dump them. Beware of weasel words, or more importantly, discrepancies in phrases like "we work with" vs. "we will work with." Make sure what salesmen tell you verbally or via email agree with the information on their site, "we work" vs. "we will work" is a big red flag. Make sure any reference list is their reference list. Good luck.

POS Ending Event - Redux II

In my prior POS Ending Event posting and it's Redux, some read them as a vilification of a POS vendor. The intent of the posts were to warn merchants that they need to do their own research and just because materials reference PCI does not make it fact. In the original post I used one vendor's letter as an example and some interpreted this as an attack on this vendor as opposed to this is something vendors, or marketing departments sometimes do. I gave some reasons for this but even my reasons were misinterpreted as "stupid vendor."

Apparently I was naive in that my definition of naive was wrong. My understanding of naive was "an innocent misunderstanding or innocently believing incorrect information." In referencing dictionary.reference.com, their closest definition is "having or showing a lack of experience, judgment, or information" -- well, now I've really stepped in it as that was not my intention. Sorry. Someday I hope to have this English stuff down.

Anyway, I'm hearing second hand that this particular vendor has written proof from PCI SSC that clearly states that "they (PCI SSC) will immediately deem any products that only operate on an O/S that is no longer supported by the O/S vendor as non compliant." I'm also told this was backed up by one of the major card brands and the vendor's QSA.

I'm hoping to get a copy of this letter because if so, this changes everything. I can see an incorrect interpretation by a QSA, after all, this was the seed that started me on this topic. I can also see one of the major card brands stating something like this -- these are huge organizations and many times you'll get a variety of answers based on who you happen to ask. But PCI SSC?! If this is what they are telling their members and QSA's, then this is a real POS Ending Event and this vendor is simply an innocent victim of PCI. Stay tuned...