Slashdot Mirror
Credit Card Security Standard Issued
alphadogg writes "The Payment Card Industry Security Standards Council, the organization that sets technical requirements for processing credit- and debit-cards, Wednesday issued revised security rules, while also indicating next year it will focus on new guidelines for end-to-end encryption, payment machines and virtualization. PCI adherence has been pushed big time in the industry to help avoid more big breaches such as the one involving TJX. Those familiar with the standard say it could be expensive to implement and that there are some things those using wireless LANs will need to pay especially close attention to."
I don't know how many reading this have been through the whole PCI thing. Personally, I think that it is pushed by folks that are selling 'scanners' and other remediation software.
I believe that security standards are a good thing. I appreciate that PCI has helped many environments be more secure. However...
I have worked in 3 unix shops that were devoted to E-Commerce. Currently, I'm really impressed with the company that I work for and how they do things. Unfortunately, I have seen things that most Unix admins/Security admins would have nightmares about in some other places that I have consulted. Yet, no matter what security flaws are there, they always passed.
I shudder when I think of one company that I worked with. They are a very high level financial institution. Guess what their AIX HMC passwords are? Can you get to them from the outside world? Yep. Could I down their production servers, a year after I worked there? Yep. Are they considered compliant to DSS/PCI standards? Yep.
Consumers in the US in particular are hugely behind the curve as far as end to end security goes. A lot of Credit and Debit cards are still being issues without Chip & Pin. Yet worse for some mind boggling reason Credit Card companies have started installing RFID into these cards.
In the EU, the UK in particular Chip & Pin is mandatory while RFID is nowhere to be found. Now I appeaciate that the US only recently moved away from Checks and still have a very questionable Direct Debit (bank to bank transfers) system in place but you would think one of the worlds leaders wouldn't be one of the worlds losers in terms of card security and fraud protection.
I think you answered your own post. The EU is more up to speed because security has been regulated (fraud is the merchant's problem in the US, not the bank or processing network). Card issues care less about security and more about transaction volume.
I can't explain why our banking system sucks though. I would've thought we'd be ahead of the curve when it comes to moving money electronically. *shurgs*
* very very very hard way to physically clone a CC/DC;
* very very very strong encryption in communication;
* user-changeable authentication and authorisation, so it won't be enough to have just a copy of the data printed on the CC sides to make a purchase on internet.
Anything else, will simply suck as far as "security".
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
RFID is everywhere in Europe - just not on the credit cards. Yet. But the situation is changing.
The US is skipping on the chip-n-pin because it makes sense for them to jump directly to the RFID cards, which are physically more durable, and allow for different form factors (like mobile phones or keyfobs).
The RFID card security problems currently can be attributed to flawed security design, not to the technology itself. We trust TSL over WiFi, and WiFi is far more easier to skim than RFID comms.
You misunderstand the system.
Credit card companies and banks make money from fraud. You (as a customer) pay for insurance that they use to cover the fraud. They have no incentive to change. Changing will just cost them money and won't affect their bottom line.
At least, that's been the situation for decades. However the consequences of handing billions to criminals is starting to have an effect. The criminals have billions in assets, and can leverage those for bigger and bigger forms of fraud, and they are.
I don't really want to hear any more of this crap about how they're going to "segment" my secret pieces of information behind a firewall. The whole system is a house of cards, built on "secret pieces of information" and heuristics about the kinds of transactions fraudsters perform. Once someone has stolen all the relevant secret pieces of information, all bets are off and the system has failed. These "secret" pieces of information are not hard to obtain, and adding more secret pieces of information (i.e. CVV2) is absolutely not a solution. I want end-to-end encryption and transactions which don't need to be perpetually stored in a database alongside my secret pieces of information.
In short, I want electronic, encrypted cash. When my wallet is stolen and not worry that I will lose any more than the cash actually in the wallet. I don't want to have any more transactions denied because I traveled to a foreign country.
But most importantly, I want to take those billions out of the hands of criminals.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
As a small company who has recently been through the self assessment procedure, I can say that the guidelines are very poorly designed in many cases.
For example, on the instructions page (https://www.pcisecuritystandards.org/saq/instructions.shtml) there is a link to SAQ Validation Type 1 form (A) and describe the type of applicant thus:
"Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants."
But in form A part 2c it states:
"Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handles these functions;"
By answering yes to this question, a merchant is saying that they will not transmit the details on (i.e from, to or within) their premises. This would mean that e.g. a mail or telephone operator could not *transmit* the card details to a third party service provider. i.e. they cannot use the PAN in any way (they *can* store it on paper - so orders by mail are OK), but the requirement very specifically says "Merchant does not ... transmit any card holder data on merchant premises". If I cannot transmit this information on my premises I cannot send it out to our service provider for processing etc.
This does not make logical sense. In theory, I could process payments via a PDQ machine directly connected to the phone line system and as the phone company is a "third party service provider" this could be argued to be compliant, but if I send it via e.g. an HTTPS website to an application hosted by our hosting company, this is technically going through our internal network before going through the wider internet (albeit encrypted via SSL) to our third party service provider. This is clearly "transmission on merchant premises".
I'm probably interpreting things quite pedantically (but isn't that what you're supposed to do with this kind of security thing?), but the guidelines and forms are riddled with these ambiguities and contradictions. :(
RFID are in Credit Cards in Europe!
check out http://news.bbc.co.uk/1/hi/business/6975820.stm
and http://www.mastercard.com/uk/personal/en/paypass/faq.html
PCI was set up as an attempt to get merchants that don't care about security to consider it with out it being too hard and forcing them away from card payments. They pretend to have no conflict of interest yet the only way to get certified is by proving you do have a conflict of interest. Many of the ideas for standards tends to be controlled by people who want to micromanage how things are done (which means you can use their product). Some of the ideas tend to get implemented poorly just in a way to be "PCI compliant" without the full consideration of the real security issues at hand.
The most interesting thing about the system is that the purpose of the auditors is to be the fall guys and take the liability. If a clearing house looses a bunch of card details, they won't be around long enough for anyone to sue which is why the auditors need so much insurance.
I'm not convinced RFID makes much sense really.
With chip'n'pin there is cryptographic processing going on on the card to verify it's not being lied to by the shop or the bank. With RFID.... a number gets returned. Not so useful.
If you're referring to wireless EMV (or similar) then that's different, but is usually still going to be in card form.
"Credit card companies and banks make money from fraud."
Not in the UK they don't. Oh sure, they probably have it insured, but until recently the liability for loss (where they couldn't prove the merchant or customer was complicit and don't catch anyone) was all theirs. This is because they supply the tech, they mandate the schemes, they set the standards.
EMV goes some way to what you want, there is encrypted information sent between the card and the issuing bank that nobody else can read, but is dependant upon PIN. The biggest hole in the scheme is that you are still allowed to fall back to magnetic strip transactions in some places. They tend to be where the fraud is done now.
PCI compliance is not too difficult to follow. It should be the minimum done by anyone handling card commerce and trade.
most of these issues is why when I want to buy something online I just go to the bank and simply transfer money from my safe account (can't be used to buy online) to my unsafe account. Buy the stuff and that's it. You can't buy anything with my card cuz there's nothing on it until I want to buy something.
I think one of the banks available here have this system: you have a debit account and virtual account associated with it. You can transfer money between them at any ATM. Sort of like "transferring" money from pocket to hand to buy groceries.
Lose the ATM and move to online banking and that's about it. Online banking as far as I know is encrypted (I hope so).
mov ax,4c00h
int 21h
PCI really seems like a good idea, gone wrong.
It's getting more and more expensive and convoluted to abide by if you have to do more than the self-assessment. All the while, quite a few companies skirt by dangerously by faking it or lying.
It seems like we might all be a little safer if they toned the requirements down a bit in a few areas, but beefed up the auditing requirements on the fundamentals.
For instance, it clarifies that all operating systems associated with card processing have to run antivirus software, while many had thought this was only about Microsoft Windows.
great, now I have to run ClamAV on all my fully-patched and secured dedicated web servers that don't store CC data anyway. I thought about writing my own AV program:
#!/bin/sh
echo "scanning for viruses..."
sleep 10
echo "no viruses found."
exit 0
From TFA:
For instance, [the PCI revision] clarifies that all operating systems associated with card processing have to run antivirus software, while many had thought this was only about Microsoft Windows.
"That sounds like a sensible piece of advice," says Sushila Nair, product manger at BT, who says organizations often deploy antivirus on Windows but erroneously believe Unix and Macs and other operating systems are somehow more invulnerable. However, she notes accommodating the clarified PCI rule on antivirus in many places will be "expensive."
So what would constitute compliance with this rule? Is running periodic ClamAV scans on my Linux server sufficient? Will saying that I have ClamAV installed on the audit form be sufficient to comply with the new rule?
This change seems to have as much to do with protecting the Windows franchise from erosion by *nix systems (in the name of "levelling the playing field") as it does with security. Not only does it ignore the very real differences in security among the various platforms, but it makes selling a Windows solution to upper management much easier than selling Linux. Of course a system with a Windows server and Norton or McAfee will pass muster. Linux+ClamAV? Who knows?
There is no solution that would allow for the non logging of transactions that would also allow for accountability. Transactions simply must be logged for proof that the transaction happened and, in the case something goes wrong, to allow the rebuilding/ confirmation of the correct account balances.
Having said that PCI-DSS does demand end to end encryption and the requirements for storage encryption go up considerably if you actually store the entire credit card number (masking it out works better). CVV2 does actually help because merchants are not ever allowed to store the CVV2 info. If the credit card companies ever find out that a merchant is storing CVV2 their ability to process transactions will be revoked.
Open your wallet and look for the funny colored pieces of paper. It also does not have accountability, and has worked fantastically for thousands of years.
Accountability is something I can live without, and would occur at other points in the system (i.e. bank transfers, paycheck deposits, etc). Accountability with merchants is needed only if the system is so insecure that a merchant can actually perform a fraudulent transaction. A merchant cannot take physical cash from my wallet from afar.
An encryption scheme with the same properties as cash (and no accountability) can be easily created.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Yes there is the insurance aspect, however it is useful to note that the card schemes attempt as much as possible to push liability to the card issuers who push to the acquirers / third party processors who push to the merchants.
The requirements relating to segmentation give the payment processor the ability to implement stronger security within the 'PCI' secured segment. That is, corporates do not have to prove the same level of security is in place for the corporate network side - as long as the full PAN, CCV, exp date is not able to be accessed from the corporate network side.
There are also requirements about length of time transactions are to be stored / retained in full. There is less of a problem (note: not no problem) for the actual transaction authorisation / payment and more on the merchant storing the data (particularly those that store the data in their POS systems (integrated into the acquirer terminals or separate).
Card Schemes are pushing the card issuers to have the reviews performed on the third parties they use for payment processing, this goes all the way down to the smallest merchants. However companies that have low transaction volumes are not required to prove compliance (through external review) and are just required to self report.
Every person I know carries around a digital camera in their pocket. The number is printed on the credit card. CVV2 is treated as secret by certain parties, but fraudsters are certainly not going to play by those rules. As such, CVV2 is like the "orange alert" system. "Hey look! We're doing something!" It may mitigate some fraud occurring high in the CC processing chain, but I doubt that's not where most of the fraud was coming from in the first place.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Credit cards are an authorization based system and NOT a transaction-based system. If you hold the right credentials (secret pieces of information) you are authorized to perform any transaction you want, at any time. Did you know merchants you transacted with a year ago still have authorization to perform transactions later, without your consent?
I want a transaction-based system in which I can perform transactions, and no information is stored anywhere about anything except for the transaction itself. It is then easy to verify transactions, because the only ones that get initiated are ones with my card, when I am present, and I can choose to agree or not agree to the transaction at the time it occurs. (Just like cash)
I do not ever want to give anyone authorization to perform transactions against my account. I want to give them a specific amount of money, at a specific time, and that's it.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
CVV2 is there to force the card theft to be either physical (from the back of the card) or real time (by monitoring transactions on the server).
If I take a picture of your credit card: I have one credit card and it took me several seconds to get it and I risk getting caught.
If I monitor the server I have to either transmit the data back to myself in real time or break in again to read my logs. Both increase my risk of being caught but I can gain hundreds or thousands of cards.
Before CVV2 If I broke in to your server once I could grab all of your logs and have thousands or even millions of credit card numbers in a single shot without having to come back. It was actually a huge problem before CVV2.
last year barclays ran a trial in and around canary wharf, london.
it was a rfid card that could be used for payments under £10. not sure how far this has spread but i'm seeing these machines in other areas now.
i also heard plans to integrate the card with oyster (underground ticket) and a nokia mobile.
Although security standards do have some appeal, the way it's playing out is that everyone is doing the same thing--that which is required to pass a "security scan" and no more. No reason to like, think about it or anything, or hire a real expert. Mind you, it's hard to assess the expertise of someone if you're not a member of their profession.
Anyway, monoculture is bad, mmkay. Not saying I have a nice pre-packaged solution with a pamphlet and everything....
expandfairuse.org
EMV is becoming the standard worldwide.
RFID is not necessarily more secure, however, it's more convenient, but only if the proper education is given to vendors and consumers alike that adopt the cards and readers with RFID technology.
The whole idea behind RFID is convenience. No swiping and waiting, just pass over with a certain proximity and out comes the receipt, under $25 no signature required. DES is used primarily for security, but I'm sure whatever else the Payments industry is setting standards for will be followed up with in short time.
It makes more sense for banks to issue RFID cards and key fobs (ie. citibank and Master Card Pay Pass fobs) because they don't have to expire, lessening the cost of producing more plastic cards every couple years and spending more money on the inlays with the chips in them each time.
The added security feature I would imagine is not having the credit card numbers and your name taken from the card for fraud, because the key fobs don't have that information on them. And you would always use the same solution if you lost a card or key fob, you call the company and have them cancel it and send you a new one.
WWJD? (What Would Jonas Do? - Spinward Fringe by Ran
That's fine if all you ever use your card for is buying things in a shop, but some people want to use it for recurring payments, which requires the merchant to be authorized for future transactions.
Ideally I'd like to be able to restrict *how much* they can take in a transaction, but I really don't want to have to fill in my details every month to pay the bill for my internet connection.
So it won't be too long before unscrupulous cashiers (or their handlers) fit optical scanners on their clandestine card skimmers to read the CVV2 (and signature - why not) from the back of the card whilst the mag stripe is being swiped. At least with chip and pin stuff, the ATMs in the countries that support it will actively compare magstrip with data read from the ICC, and probably reject transactions or retain the card if they suspect fraud (eg. if the auth request says there was only a mag stripe, but the issuer says that card should have a chip on it, then they get rejected). This just means that the skimmed card clones end up being used in countries that still only use mag stripe.. Which is fairly easy for the fraud triggers at the card issuer to work their magic. Cardholder present in geographically disparate locations within a few hours.. That sort of thing.
At least, that's been the situation for decades. However the consequences of handing billions to criminals is starting to have an effect. The criminals have billions in assets, and can leverage those for bigger and bigger forms of fraud, and they are.
Are the former criminals going into politics or actually just starting their own banks now?
So start Bill's Credit Emporium. Merchants will surely jump to work with someone who is willing to be liable for all transactions (or rather, force their other customers to be liable, whatever).
Nerd rage is the funniest rage.
Now I appeaciate that the US only recently moved away from Checks...
Moved away from checks? Hardly. Go to any grocery store in the US the day all the old folks get their social security checks and you'll see what I mean. Most bills still are paid by check despite the cost, inconvenience and inefficiency. Checks remain very heavily used in the US anywhere you go. Hell, Visa even has an entire ad campaign for their debit cards to try to get people to use the cards instead of writing checks. Visa wouldn't be bothering if checks weren't an incredibly common method of payment.
Otherwise you are right. The security sucks and there seems little motivation to improve matters.
The amusing thing about CVV2 is that you have to tell it to any merchant you want to charge something with. If you do, it becomes worthless, and if you don't, it's worthless.
I had to follow this standard on a previous project, and looking at the summary of changes, it's largely rather routine. Most of the changes actually look like relaxations: Less frequent testing, more generic terminology (removing specific wireless security mechanisms), and a bunch of clarifications of intent. The ruling on antivirus software for UNIX systems is a little silly to me, but it doesn't make much in the way of strong clarifications as to the quality of the software. It sounds like a standard cover-your-ass ruling. While annoying to install, it's nothing difficult for any topology I can imagine. The threat of changes yet to come may be a hassle, but if they aren't defined yet, I wouldn't really call that hideously newsworthy.
An encryption scheme with the same properties as cash (and no accountability) can be easily created.
Go ahead and try. It's no so easy as you appear to think. To get you started, try answering this question: How do I know that this "e-cash" hasn't been duplicated (spent more than once) without a central database tying each unit to its current owner?
Cash works because it's tied to physical matter, and because effective counterfeiting is hard (and incurs highly disproportionate penalties). Even assuming that e-cash cannot be counterfeited per se (each "e-note" being securely signed by the issuer) you still have the problem that receiving an e-note does not in any way imply that the sender no longer possesses said e-note. They can send it to someone else and it will appear just as genuine to them as it did to you.
Also, every electronic system which has come anywhere close to the anonymity of cash has been shut down for "money laundering". Cash itself only survives because it remains political suicide to even consider doing away with it.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
I work for a small(ish) software house where our two main clients are UK FTSE100 companies. Both are using exactly the same software and have a very similar network setup. They both independently employed different PCI consultants to audit the software and network and sent the results to us for comment. One set of consultants had recommended a huge amount of changes before they could certify PCI compliance, the other just some tweaks here and there. Guess what, the company that recommended all the changes could, coincidentally, carry out a large portion of the work themselves. Until the CC industry addresses cowboys like that, it's no wonder that companies look at PCI as being a waste of time and money.
So you sign a recurring "not to exceed" transaction.
Why are you letting these clowns ruin our country?
Imagine if each bank/company could issue their own cash. They would each print their own denominations with different security features... it would be a mess.
So why doesn't the government regulate 'e-security'. At the very least, it should take opinion from the IEEE or something to guide the industry.
I'm still amazed we don't have chip cards.
Anywhose...
PCI is all about encrypting credit card numbers and expiry dates - and nothing else. Even a fully-PCI-compliant system is a rich source of unencrypted information for Identity Theft.
Although the PCI security standards recommend to companies that they do criminal history checks on suspect employees working with credit card data (and a company I worked for, claiming PCI compliance, had a compulsory criminal history check on the first day for *all* employees even though they were working nowhere near credit card data) it still doesn't address some of the weakest links: the human operators and the GUIs that they use.
I recently closed a Buyers Edge credit card, operated by GE Capital Finance in Australia. I couldn't supply the "account password" to the telephone operator on one call, but after supplying other identifying information the operator was able to READ MY ACCOUNT PASSWORD BACK TO ME. What's up with that: displaying the password for the account in clear text on the screen? Why aren't they encrypted? Why don't they have an input to type potential passwords in to that says "Yes it's right," or "No, it's wrong"? There's nothing stopping employees from snooping through customer records to gather saleable information for the Identity Theft market.
The only good thing I can say from my experience is, "I'm glad my credit card with them is closed."
There are ambiguities and different interpretations of the PCI standard however, in my experience of multiple audits, the biggest issues are (i) the standards body does not do a good job answering questions (ii) the standards body only sets the standard, it defers 100% to the card companies on compliance dates and fines.
IMO if implemented properly the standard does lower risk but of course you can never have zero risk.
On the question of why doesn't the USA adopt chip and pin. I have heard that the card companies don't believe American consumers would sacrifice convenience for security. Chip + pin and/or encryption at the point of entry are no brainers that we should be adopting as strategic solutions.
On RFID security. Hacking wireless networks is mostly just "cool" but if you can hack RFID you can get money...I wonder which has the higher risk rating.
I have the job of assuring PCI compliance at my company. In July the PCI rules changed and some of our systems suddenly became non-compliant as reported by our scanning service.
The two issues were:
1) we ran identd
2) we ran anonymous ftp
The problem is that just the existence of these services is a PCI violation. Even though it is possible (and we do) to configure these services securely.
For identd, the "threat" is that it will leak information about user accounts. We run the liedentd daemon, which responds "nobody" to every request. Thus no information is ever leaked, yet we are not compliant. We run identd since we send a lot of mail and a large percentage of remote sites do ident queries and having an ident server speeds things up.
For anonymous ftp, the threats are: user account leaks, DoS by filling your disk, and making files available. All of these are easily mitigated. Running anonymous ftp in a chroot jail with a private password file limits revealing any information about users -- just delete all but the mandatory "root" and "ftp" user IDs. Limit uploads by only allowing uploads into a small disk partition mounted as the "incoming" directory. We use a file-based virtual file system (vnode file system in BSD) to limit uploads to 50MB. There is no way to fill our real disk. Finally, because it is in a chroot, no other files will be leaked.
At least for the anonymous ftp, we could fake out our scanning company by renaming the "root" account in the jail to "toor".
There is no workaround for the identd "violation". I don't think the people making the PCI really think very much about the anything other than traditional e-commerce web service applications.
The only ``intuitive'' interface is the nipple. After that, it's all learned.
Those losses have to be paid from somewhere. It's either paid by the consumer (hidden in the interest rates and fees), or by the merchants (in the transaction fees), or the credit card companies would go out of business. That was the GP's point.
They do not make money from fraud. Do you have some evidence they they buy 'insurance' to cover these losses? Because that would be expensive and ridiculous. They are self insured. Granted, when they can they push fraud losses onto someone else (the merchant).
But in the bigger picture, they want to stop /rampant/ fraud, and have an interest in doing so. If the credit cards are no longer viewed by consumers as safe, they will be used less, and that will deprived the card brands of $$$.
The PCIDSS, PADSS, and other security initiatives are the card brands trying to add some security to what is, in essence, a weak (broken) system. They pretend that the cardholder data (track,PAN,CVV2) is secret, when in fact you have to give it out for every transaction. Much like we pretend that SSNs are a secret, when every doctor's secretary has them.
That said, they are trying to protect what is inherently a weak system, because they aren't going to throw it out over night because you want encrypted cash.
Your software can't be trusted to tell others how much money you have, so your information has to be backed by credible sources. The best-case scenario is this: These credible sources keep your funds both private and accessible. They give you a physical key to unlock your funds when making physical purchases, and a digital key to send to Internet applications. The physical key should be difficult to copy and easy to invalidate and replace in case of theft or loss. The digital key should be complex enough to discourage random duplication yet simple enough to be inputted into computer systems using traditional input devices. Since communication can be intercepted on the Internet, the transmission of the digital keys must be encrypted. This would complete the architecture, and would leave the rest in the hands of the maintenance department, including battling fraud. Due to the digital component, there are more attack vectors against it than against cash.
You have what you wanted in its most evolved form. If you know of a way to improve it, I would have liked to have read it.
This resembles an anarchist advocating a system in whose most evolved form he is already living.