PCI Compliance - The Good, The Bad, and The Insecure - Part 2 | Hacker News Reader

PCI Compliance - The Good, The Bad, and The Insecure - Part 2

mavitunasecurity.com

36 pointsfmavituna27 comments

Salted SHA512 is absolutely not a safe way to store authenticators for payment card information. Using salted hashes for payment cards is even worse than using it for passwords, because the input domain for payment card information is so much smaller.

If a pentester finds that you did that, you will almost certainly get that written up sev:hi.

We work with lots of companies that handle payment card information (though we do not do PCI audits, which are a race to the bottom). The best practice solution for this problem is to isolate the cardholder information on a protected backend machine, keep it encrypted, and replace it on every other machine with an opaque token.

(You are much better off using Stripe or Braintree than doing this yourself.)

> (You are much better off using Stripe or Braintree than doing this yourself.)

Gonna throw in a recommendation for Spreedly (http://spreedly.com) right here. It's a processor-agnostic payment vault, so that you can offload your card storage needs without having to commit to a processor for the life of your business.

Build against Spreedly and if you want to use Stripe today, and some new YC 2014 startup next year, you just change one line of code and you're done. If you store your customers' cards at your processor, you're locked in to that choice to various degrees (from having to request some kind of encrypted hand-over and re-implementing all your billing code, to having to ask every single customer to re-enter their billing info because you chose a processor that won't give you your information when you leave).

We're looking at spreedly right now. Do know if they use Hardware Security Modules? Working in E-commerce field i've seen some pretty bad "secure implementations" like storing all the credit card data in a separate database encrypted, but they put the private key into the code base.

Saw the hash statement and thought the same thing especially when you store the last 4 digits and BIN unencrypted for looking up accounts and analytics.

(disclaimer - I work for WePay which is another payment processor)

If you are collecting credit card numbers in your application, then you are still required to be PCI compliant (see TOS for the companies you've mentioned). The reasons are obvious: if your servers are hacked or you have a malicious (or just incompetent) employees then the credit card data will be at risk. Thus you will still need to do SDLC, firewalls, HTTPS, and a few other things.

If you don't want to deal with PCI at all then you might want to checkout the iFrame checkout from WePay. This way you are completely isolated from the credit card data and PCI while you still keep the user on your website.

PCI is a bullshit standard anyways, in my opinion. Any standard that specifically states that the moment you are breached, you are "out of compliance" is a scam in my opinion. "If you follow this, then you'll be safe, but if you get breached, by default, you weren't in compliance". I'm not really sure who that protects, exactly. I hate it.

I agree a lot of is bullshit, but it doesn't say you're out of compliance when you're breached at all. It specifies that a compliance test is a point in time though, and being compliant doesn't mean that you're still compliant the next day.

Personally, I think that credit cards should use two factor authentication. Put an e-ink strip on the back of the card that displays a new 6 digit pin every 10 minutes or so. The pin would be required to complete in-person and online transaction.

Skimmers would become useless because the PIN number entered would only be good for a few minutes after it was captured. Stealing a credit card number and sharing online would be equally useless without the physical card.

This would, of course, cause some problems for online purchases, like Amazon's 1-click, but something like vendor-specific passcodes could solve that. You could go to your credit card website and request a passcode to provide to a specific online store. If their database gets compromised, you can revoke the password.

You pretty much described 3D Secure - http://en.wikipedia.org/wiki/3-D_Secure which is quite popular in Europe. Actually even mandatory in some countries.

> vendor-specific passcodes could solve that. You could go to your credit card website and request a passcode to provide to a specific online store. If their database gets compromised, you can revoke the password.

If it's vendor specific then it shouldn't matter if anyone else has it. Only that vendor should be able to use it. If that's not possible then if their database gets compromised, the vendor should be able to invalidate their password.

PCI standard is the minimum requirement. In my experience, people don't really think about security and PCI at least forces them to think and ask questions. From this perspective, PCI is actually doing its job.

The problem is that there is no transparency to the end user (customer). As stated previously PCI is a barebones set of recommendations that doesn't make any commitments to a real world security model at all. Instead it is more of a revenue model than a tool that helps offset risk for businesses. All of the audit and products built around it are mostly as valuable as PCI itself.

If PCI were to be revamped an actual assessment which graded real-world efficacy would be transparent to the customer prior to purchase. Real-world efficacy is the hard part, as it is not a static of any sort.

TL;DR Businesses are bound by process and governance. Attackers are not. If you use PCI as a driver for security implementation you will fail. PCI 'compliance' continues to be a fallacy of warm and fuzzy security kittens.

Just as a quick aside: PCI compliance is a huge (mandatory) motivation that fuels much of the information security industry. While I'm careful not to "bite the hand that feeds," there is a large gap between being PCI compliant and being in any way secure. For those that are interested, hacker/security conferences such as DEF CON, Black Hat, ShmooCon, etc. regularly have interesting presentations on completely owning PCI compliant networks.

There is a difference between building a network that is built to pass a PCI Compliance test and building a network that can pass PCI's SAQ.

PCI compliance is actually there because the card industry uses 1970 style security. Fact is the ATM cryptos was broken in the 1990s and it is more expensive to change all the card terminals than compensate the customers for fraud.

Most broken is the fact that US credit cards still uses magnetic stripe when everyone else have converted to using smart card chips. Why the is there visible PAN numbers on the cards and magnetic stripes this is year 2013.

Fact card companies uses broken security mechanisms on the cards. Then everybody else have to comply with PCI because their broken security.

What's the alternative to not having a readable number on the card when I want to purchase something online?

Your bank could issue "virtual credit cards" [or debit cards] that provide you with the cleartext card number and verification code.

Some banks already provide this service.[0]

The other alternative would be to buy a compatible smart-card reader.

[0]: https://www.bankofamerica.com/privacy/accounts-cards/shopsaf...

Ken Cochrane has a really good guide to PCI compliance from a developer's standpoint. The main point that it drives home, though, is that you really don't want to ever be in a position where you could be touching card-level data. You want to hand that off to Stripe, Braintree, Balanced, PayPal, someone else before it hits your server.

http://kencochrane.net/blog/2012/01/developers-guide-to-pci-...

PCI-DSS is a great tool to get management to understand what sort of security is required to handle customer's data properly. It's not meant to be a handbook for security experts to tick off a bunch of boxes and act like they are Neo with Kung-Fu.

If you have ever been in a meeting and been face to face with the blank stares of management while you explain why you need to spend time on hardening your servers or software, you would be thankful that PCI exists.

The way I read the standard, the string 'soccer1' is a valid/compliant PCI password. At least it for PCI-DSS v2.

8.5.10 Require a minimum password length of at least seven characters.

8.5.11 Use passwords containing both numeric and alphabetic characters.

In fact, the string 'password1' exceeds the requirements.

PCI = peripheral component interconnect? I don't get it.

Payments Compliance(?) Industry(?) – rules you must follow to process credit card data. See https://www.pcisecuritystandards.org/

PCI short for PCI DSS which stands for Payment Card Industry Data Security Standard. I.e. the standard that regulates how you capture, transmit, or store credit card information.

https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...

Comments like this make it really tough for me to not post a snarky lmgtfy link.

edit: Seriously people, it's the first result for "pci" on google. Even when not spelled all caps. Come on.

It may be your first result on google, but thanks to individualized filtering and filter bubbles [1] there is no way to tell what the first result will be for someone else.

[1] http://www.thefilterbubble.com/ted-talk

about encrypting the card data, can't you encrypt with an RSA public key and store the private key off-site? I thought it also worked backwards like that.

Yes, at a former job that was exactly how we did it in our point-of-sale software. The software had the public key and could do a one-way encryption of the data for temporary storage on disk if the network was down. The private key only existed on a server we controlled.

Reply on news.ycombinator.com