Debit Card Fees - Simply another front in the ongoing class war

I just read this commentary in the Washington Post: In cutting debit card fees, Fed should use Congress’s standard. I could not disagree more. I have not got a clue where the author is getting his numbers? My guess is that he is calculating the $7B vs. $14B based the campaign marketing numbers used to sell the bill to congress and the public. There are flaws in this type of thinking and I'll get into that below, however, this did get me thinking of a related but bigger problem.

I'm sure by now everyone reading this has heard about the class warfare arguments in politics. Whether you believe the "rich" should pay more or not is one issue but to me, the bigger issue is the class warfare campaign. This is a slippery slope. Take for instance the Dodd-Frank Wall Street Reform and Consumer Protection Act. This is another battle of the same war being fought under the guise of "consumer protection."

I've briefly touched on the Dodd-Frank Act before. I think that this entire bill is a big can of worms that many proponents don't understand or choose to blindly ignore. Some of the provisions of the act that has generated buzz in the payments space are the restrictions it places on debit card transaction fees. Merchants have been told they will receive huge cuts in fees due to this bill. The NRF jumped on this bandwagon early in the process. I have not fully researched their involvement, but I would not be surprised if they provided parts to create this wagon.

There is one key component that the NRF and other merchant advocates blindly missed - the title of the act. Note the last two words just before Act: "Consumer Protection!" Not "Merchant Protection." Definitely not "Bank Protection." While today having the word "bank" in your name is synonymous to "rich", who's to say that tomorrow "merchant" won't be as offensive as "bank" to politicians? Currently the Dodd-Frank Act does not specify that merchants, or consumers for that matter, will receive one dime from the restrictions as there are many hands in the fee structure pie (not to mention various carved out exceptions). I can easily see a scenario where politicians realize that consumers are not reaping the rewards they were so generously promised so out pops "[insert name(s) here] Main Street Reform and Consumer Protection Act." Since politicians are so good at adding language to fix prior failures, one can expect a generous heaping of price controls for merchants to swallow, all under the same guise of "consumer protection."

As I said, this is a slippery slope. I've warned of side effect of price controls before this Dodd-Frank Act was implemented; we are seeing them now (see my previous post). One of the latest is that Visa and MasterCard have increased credit card fees: New Visa, MasterCard rates take effect. While not publicly stated, I have to imagine that this is to compensate for the loss of debit card fees. Since credit card usage rates are still higher in the US than debit card usage, this will mean a wash or an increase in fees even if the merchant does receive the debit card "rewards."

Just to clarify, I am not anti-merchant, and I am not pro-bank fees; instead I am very pro-merchant. I am against the government controlling prices for any industry. I feel allowing the government to dictate the price of any product or service is dangerous. Yes, there is precedence for government dictated price controls and some might argue this to be a good thing, and throw out some examples. But I would argue that these price controls have caused as much or more damage and problems than they fixed -- just to someone else (the politically out of favor class at the time).

Until next time...

Tokenization IS Encryption - NOT!

Recently I found a blog post by Ramon Krikken entitled I'll go ahead and say it: Tokenization IS Encryption. If you have read any of my posts on tokenization, or more specifically TrueTokenization (tokenization by it's original definition), you know I disagree. Here are links to a three part post I wrote on 4titude -- Shift4's voice with attitude:

• Tokenization IS Encryption - NOT! - Part 1 
• Tokenization IS Encryption - NOT! - Part 2
• Tokenization IS Encryption - NOT! - Part 3
  
  And the latest (added 09/27/2013)
• Tokenization IS Encryption - NOT! - Part 4

Tales From the Inbox - Iwueke

Dear Mrs. Iwueke,

Thank you very much for bringing this to my attention. I didn't even know I had a $1.8m ATM card and it very much concerns me that it is about to expire! Please act immediately upon my behalf to claim the outstanding balance and send me the proceeds via a certified check ASAP -- or better yet, exchange it for solid gold or silver and have it shipped. Please deduct the shipping costs from the proceeds. Also, in exchange for your kindness, please deduct an additional $500 from the proceeds for your time.

Again, thank you very much!

--Steve

---

From: Mrs. Elizabeth Iwueke [mailto:xxxxx.xxxxxxxxx@yahoo.com.ph]
Sent: Monday, October 24, 2011 11:37 AM
To: undisclosed recipients:
Subject: Contact Global Express Shipping Company Benin Repub.


ATTN, PAYMENT NOTIFICATION

This is to bring to your notice that, I have paid the re-activation and the delivery of your ATM, I paid it because the ATM Card ($1.8m),has less three days to expire and when it expires, the money will go into Government purse. With that I decided to help you pay the money so that the ATM will not expire, because I know when you get your ATM definitely you must pay me, my money back and even compensate me for helping you.

Now I want you to contact The Shipping Company Benin with your Full Contact information’s so that they can deliver your Card to your destination address without any delay. Like i stated earlier, The delivery charges has been paid but i did not pay their official keeping fees since they refused.

They refused and the reason is that they do not know when you are going to contact them todat before dumourage might increase. They told me that their keeping fees is USD$25 per day and i deposited it yesterday .

Below Is the Shipping Delivering Company Contact Information’s,

Contact Person: Dr.James Nelson.


The Director General Global Express
Shipping Company Benin Republic
E-Mail:(xxxxxxxxxxxxxxxxx@w.cn)
Contact Number: +229-########

Contact Today to avoid increase of their keeping fees and let me know once you receive your Card.


Best Regards,
Mrs. Elizabeth Iwueke

Is PCI Even Legal?

Back in September 2008 I put myself on PCI SSC's dung list as well as a separate entry on Bob Russo's personal ignore list with my post "PCI SSC Show Their True Colors -- Regulate for Profit". Recently I found an interesting post on Magtek's website: Fraud Mythology in the Payment World. It details a speech by Magtek CEO Mimi Hart where she rips into PCI, calling it "one of the more dangerous 'false gods' in payments." Now finally I have company on the dung lists! I have one small criticism about her speech though, every false GOD is dangerous so "dangerous" in that sentence is redundant. ;-)

Within the speech, Mimi Hart states "PCI has rapidly become a self-perpetuating, self-aggrandizing, profit-motivated authority", this got me thinking, is PCI even legal? Antitrust laws prevent the card brands from getting together in a room to set rates or make common rules for members, merchants, and customers. But before I go further, let me give a brief history lesson...

In the early days, prior to cardholder data security (pre-9/11/2001), the card brands, for the most part, relied on trust that cardholder data was being securely stored and properly used by merchants and applications. Sure, there was fine print in merchant agreements and various unpublished rules stating that merchants must do this or don't do that, but for the most part, there was no mechanism to enforce these hidden rules and fine print. After 9/11, the government decided payments needed better security and told the card brands to get it under control or they would step in.

Each of the card brands rapidly scrambled to create their own set of security mandates for merchants and vendors to follow. Visa had CISP, MasterCard had SDP, American Express had DSOP, Discover had DISC, and JCB had "security standards" (hmm, very creative!). While there were many common and compatible requirements, there were many that were unique to each, and worse, there were a few mandates that contradicted or deviated from mandates of other brands. In all this turmoil, PCI SSC was formed to unite all the security mandates and create one ring to control them all.

Ok, back to my question -- Is PCI legal?

Per the PCI SSC website: "The Council's five founding global payment brands -- American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. -- have agreed to incorporate the PCI DSS as the technical requirements of each of their data security compliance programs." Then a little further down on the same page, "All five payment brands share equally in the Council's governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organization."

I'm not a lawyer but to me this seems to imply that while PCI SSC is a separate organization, it is controlled by a round table of the five card brands. And because this is a "for profit" organization, this seems to have antitrust implications that may threaten PCI SSC's legal legitimacy.

PCI SSC was created as a way for the card brands to conspire to create a common set of security mandates without breaking antitrust laws. The problem is, PCI SSC is setup as a "for profit" limited liability corporation controlled by the card brands. If this was setup as a non-profit organization (as I assumed it was because of the .org domain name - silly me, another future rant) and a true standards committee like ANSI or ISO, I feel there would not be an issue. But as a "for profit" organization under the direct control of the card brands, there seems to be an issue here.

My recommendation: restructure as a non-profit organization, make the books public, and become a real open standards board eliminating the antitrust concerns.

If any antitrust attorney happens to read this, I would love to get your take on this question. Until next time...



P.S. For another take on the same speech, see the post in StorefrontBacktalk: Federal Reserve Listens to Security Vendor CEO Rip into PCI

P.S.S. Mimi, welcome to the list!

House Democrats Ask Justice Department to Probe Debit Fees

This is an interesting and quick read in Bloomberg Businessweek: House Democrats Ask Justice Department to Probe Debit Fees

If you don't have the time and need a Reader's Digest version: Lawmakers are crying because banks are making them look like incompetent boobs. That's about it.

Swipe Fees Revisited

I hate to say I told you so but:

• With a $1.67 Average Ticket, Vending Processor USAT Predicts Pain from Durbin Rate - A vending-machine payments processor highly dependent on debit cards is bracing for a 247% increase in its average cost for accepting big-bank debit cards as a result of new Visa Inc. and MasterCard Inc. interchange schedules set to take effect Saturday...
• Durbin Casts a Wary Eye on Rising Small-Ticket Debit Interchange - U.S. Sen. Richard Durbin on Tuesday said he is aware that new Visa and MasterCard interchange schedules will cause some merchants to pay much more in interchange when a consumer uses a debit card from a big bank to pay for small purchases...
• New BofA Fee May Hasten Debit's Demise - Bank of America Corp., the largest bank by assets, plans to start charging its checking customers $5 per month, or $60 annually, if they use their debit cards to make purchases...
• Durbin Attacks BofA's Decision - Sen. Richard Durbin, D-Ill., author of the debit-interchange regulation, attacked BofA's decision, charging the money-center bank is "trying to find new ways to pad their profits by sticking it to its customers."...
• National Retail Federation also denounced BofA’s Decision - The National Retail Federation also denounced BofA’s debit card fee.
• Bill Would Repeal Debit Fee Cap - ...Although the bill is expected to face resistance, Chaffetz and Owens believe it will gain momentum as consumers begin to see the consequences of the new price cap...

Oh, by the way, while I agree with most National Retail Federation stances, I believe they were dead wrong on this one. I have to imagine that someone over there is smarter than I and could have predicted side effects like these -- I guess not!  Asking the government to step in and regulate costs and fees for an industry cannot ever end well. If someone arrives on your door and says "I'm with the government and I'm here to help", RUN! But in this case, the NRF invited them in with open arms.

Tokenization and Relevance

I recently came across an interview in ISO&AGENT with Bob Russo on PCI's Tokenization Guideline: PCI Council Reveals Secrets of Tokenization

Much of the interview is standard talking points that I have seen in press releases and other stories from various sources, but it's worth a read if you follow tokenization.

The last paragraph of this story caught my attention though: "'When vendors first introduced tokenization, companies selling other fraud-security techniques were concerned about becoming obsolete,' Russo says. But over time, it has become apparent various layers of security are needed to keep data safe."

Tokenization was released to the public domain by Shift4 back in 2005 so "companies selling fraud-security techniques" really had nothing to be concerned about; all they had to do was incorporate tokenization into their solutions. Russo is absolutely correct in his assertion that various layers of security are needed to keep data safe, so even without tokenization, what cause did these companies have for concern?

Are we certain that the fear which Russo references was actually from fraud-security companies and not from PCI council members and QSAs? Some might think that the more you remove components and systems from PCI scope, the less relevance PCI and QSAs become. Personally, I think this fear of having less relevance was part of the motivation to redefine tokenization to include "high-value tokens" and defer token scoping to QSAs.

The primary goal of tokenization was to improve security by removing sensitive data from the merchant environment and a byproduct is a reduction of PCI scope. Similarly, PCI compliance should be a byproduct of solid security. As long as PCI acts as a liability shield for the card brands, PCI will have relevance. As long as QSAs focus on security and not compliance, QSAs will be have relevance. Neither should have feared tokenization by it's original definition, without the inclusion of "high value tokens."

Tokenization, the Newest Horse - err, Camel - in the Stable

As the old saying goes, "a camel is a horse designed by a committee." This saying perfectly describes the recently published PCI DSS Tokenization Guidelines from the PCI SSC. While the original intent of the document was a noble one, the final version fell way short.

The problem with having multiple blogs is to post onto multiple blogs. To avoid content duplication, please go here to read my post: http://blog.shift4.com/2011/08/tokenization-the-newest-horse-err-camel-in-the-stable.html

My take on Swipe Fees

There is an ongoing debate in the restaurant and retail industries about swipe fees for debit cards. There are bills being written and debated in congress that address swipe fees and I see trade associations from both industries cheering on these new regulations. My advice:

Quit crying for government regulations and

start fixing the problem yourself!

There is no regulation that I'm aware of that says a business must accept plastic -- credit or debit. If merchants think the card brands are charging too much, organize something that would get your point across. Have a "no plastic day" or "no plastic week". If enough merchants participated, this would send a strong message to the card brands and with little risk of unforeseen consequences. To me, this debit swipe fee trivial, a much bigger issue are the different rates for reward cards vs. non-reward cards and not knowing the fee up front, during the authorization event. It seems strange to me that the reward card rates are rarely, if at all mentioned by these same trade groups and the reward rates are much more significant than the debit rates.

It’s a cliché of mediation, uttered by every mediator trying to push two unhappy parties to reach agreement on a resolution, that "a good settlement is one where both sides are unhappy." The problem is when politicians create regulations, having both sides unhappy does not buy votes so one side or the other is going to be ecstatic, while the other side is going to get screwed. In this environment things will change because both sides need to be profitable and this is where unforeseen consequences enter the picture. Many times (I would say most times when it comes to government regulations), these unforeseen consequences can be worse than the original problem that was being addressed. I strongly believe that it much better to keep politicians out than to suffer the unforeseen consequences that will ensue.

Some Recent PCI Results

I just read a report on a PCI survey quoting some PCI statistics: PCI DSS compliance generates results. According to a recent survey performed by Imperva and the Ponemon Institute, businesses tend to perceive PCI compliance as something that does not have a positive impact on their security systems. However, the survey's results indicate companies that maintain PCI-compliant systems are significantly more secure than their non-compliant counterparts.

While I think PCI is a good thing because in a round about way it forces merchants to recognize security, I question statistics like this -- particularly the first number quoted: "...64 percent of PCI compliant respondents did not experience a data breach involving credit card data during the past two years."

In the past Visa has stated "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." Based on this statement I question whether or not the 36 percent of the PCI compliant respondents that were breached were "PCI compliant?" A catch-22. The report should have said 100% of PCI compliant respondents were not breached vs. some percentage of the non-compliant respondents were breached.

Nit-picky I know, but as my blog byline states, random thoughts.

Beware Mac users - as popularity grows, so does the target on your back

It's been a while since my last post. I hope to start posting somewhat regularly again in the near future. It's been a madhouse around here as we have been building a new data center from scratch; new hardware, more hardware, new O/S, more memory, new software, new, new, more, more, better-stronger-faster everything, etc., etc. In the last few weeks we've been migrating various services and customers to it; throw in our annual PCI audit and presto -- no time. You'll hear more about this entire project in the next few weeks. For now, suffice it to say it's been a busy time.

Over the years I have posted on several forums my belief that no operating system is inherently secure simply because it is not Windows. Many anti-Windows zealots tout that Linux or Mac or whatever is much more secure based on the number of reported hacks and vulnerabilities: "Hey, simply look at the number to prove my point." And this argument always has a reference to some vulnerability report showing Windows (some big number), their O/S of choice (some little number). I always point out a very similar report showing market share: Windows (some big number), their O/S of choice (some little number). My argument is that hackers go to where the money is -- the market leader.

Well an interesting read that just came out the other day: Coming soon to a Mac near you -- serious malware. When I read this article I had to check back to the author a few times to make sure it was not me as an alias. Give it a read if you have some time.

From Europe with Love

The Peoples Republic of California is looking more and more like Europe everyday. In case you missed it: California retailers can't ask patrons for ZIP Codes, court rules.

In reading the story, the courts ruling seems like a noble one -- protect consumer privacy. But I feel this blanket decision totally ignores the rates merchants are charged processing these transaction with vs. without address verification information and all but ignores the security aspect for merchants requiring a ZIP code. To me, a ruling that merchants could not use any information associated with the processing of the payment for marketing or purposes, then it would have been fine. When I saw the headline, it was screaming: "CALIFORNIA WELCOMES ALL SCAMMERS AND FRAUDSTERS WITH OPEN ARMS!"

As to the rate difference, California card-present merchants will need to decide what to do in the event a card cannot be swiped: Don't ask for the ZIP code and accept the higher cost and higher potential for a fraudulent transaction OR ask for another form of payment. My advice with be the latter, but this may not be the optimum advice for all merchants.

The court touched on the security aspect, but it does leave a big hole: "....allows ZIP Codes to be collected under certain circumstances, such as at gas station pumps where the information is requested for security reasons..." -- why wouldn't all merchants fall under this "certain circumstance?"

And then the biggest little line in the entire story: "The court said retailers may still ask consumers to produce a driver's license for identification purposes but may not record the personal information on it." This advice from the courts goes against most (maybe all) merchant agreements. I'm not sure if this was a simple oversight by the courts showing lack of knowledge in payment processing regulations, or if this was an intentional warning shot over the bow of the card brands?

Forced Password Changes - good or bad?

For years now there has been a debate in the security community as to whether or not users should be forced to change password at regular intervals and if so, how often. On one side there is the argument that changing passwords frequently makes it harder for hackers to acquire a users password and limits the exposure if a hacker were to acquire a user's password. On the other side you have the argument that forcing users to change password increases the chances for forgotten passwords and more dangerous, the chance that users will write down passwords on paper or post-it notes stuck to their monitor or under their keyboard.

I'm one that argues the latter and I believe that most in the security community agree with this argument (at least today). I would argue that if you have sufficient controls in place to prevent, or at least throttle brute force attacks and notify users of last login successes and failures, then a user should never be forced to change their password. I would add a caveat that the password should be of sufficient length and complexity (7 character minimum, alpha and numeric, etc.) and if they are not, then a forced change should be required.

A few years back PCI decided to side with the first argument and mandate regular password changes. They believed this argument so much as to require what I believe to be a very short change interval of 90 days:

“PCI DSS 8.5.9 Change user passwords at least every 90 days.

• 8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.
• 8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”

“PA-DSS 3.1.4 The payment application requires changes to user passwords at least every 90 days. (aligns with PCI DSS Requirement 8.5.9)”

The 2005 OWASP best practice included the following:

“Passwords are trivially broken and are unsuitable for high value systems. Therefore, ...

• Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after (say) 90 days instead.”

This tells me that in 2005 the OWASP people were leaning to the side of the first argument. Now, the latest 2010 OWASP states:

“Password Guidelines...

• Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely...”

While “frequently” is somewhat vague, I interpret this as OWASP is leaning toward the latter argument now.

The Problem: In several places in PA-DSS and PCI DSS, references are made to adopt best security practices and the latest security standards like OWASP -- but PCI mandated a 90 password change period. PCI does note specific exceptions in the case when these other security standards differ from PCI:

“However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.”

But, these notes appear to have limitations, in the case of PCI DSS:

“The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published...”

and in PA-DSS:

“The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.9 and in PCI DSS at 6.5.1 through 6.5.9 were current with industry best practices when this version of PA DSS was published...”

So the problem is that while PCI SSC does realize that other best practice security standards may outpace PCI's requirements and they attempt to accommodate these discrepancies, they limit the use of these standards -- at least as far as compliance goes. To me, this can easily be correct by removing the limitations. With these limitations in place, this would be a case where “security” and “compliance” go different directions.

I welcome your thoughts.