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

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.

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.

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.

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.

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.

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.

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.