
PCI Compliance - The Good, The Bad, and The Insecure - Part 2 - fmavituna
https://www.mavitunasecurity.com/blog/definitive-pci-dss-compliance-guide-web-application-security/
======
tptacek
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.)

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

Gonna throw in a recommendation for Spreedly
([http://spreedly.com](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).

~~~
adrr
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.

------
JonFish85
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.

~~~
lreeves
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.

------
Osiris
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.

~~~
Flenser
> 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.

------
lsh123
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.

~~~
windexh8er
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.

------
david_shaw
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.

~~~
ChikkaChiChi
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.

------
acd
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.

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

~~~
drbawb
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...](https://www.bankofamerica.com/privacy/accounts-
cards/shopsafe.go)

------
zrail
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-...](http://kencochrane.net/blog/2012/01/developers-guide-to-pci-
compliant-web-applications/)

------
ChikkaChiChi
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.

------
16s
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.

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

~~~
makmanalp
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.

~~~
robertfw
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](http://www.thefilterbubble.com/ted-talk)

------
nraynaud
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.

~~~
jewel
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.

