6 ms·

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

36 points by fmavituna 13y ago

rayiner 13y ago
PCI = peripheral component interconnect? I don't get it.
- Robin_Message 13y ago
  Payments Compliance(?) Industry(?) – rules you must follow to process credit card data. See https://www.pcisecuritystandards.org/ https://www.pcisecuritystandards.org/
- benmanns 13y ago
  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_Security_Standard https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...
- makmanalp 13y ago
  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 13y ago
    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
acd 13y ago
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 13y ago
  What's the alternative to not having a readable number on the card when I want to purchase something online?
  - drbawb 13y ago
    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/shopsafe.go https://www.bankofamerica.com/privacy/accounts-cards/shopsaf...
  - deleted 13y ago
    [deleted]
Osiris 13y ago
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.
- fmavituna 13y ago
  You pretty much described 3D Secure - http://en.wikipedia.org/wiki/3-D_Secure http://en.wikipedia.org/wiki/3-D_Secure which is quite popular in Europe. Actually even mandatory in some countries.
- Flenser 13y ago
  > 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.
tptacek 13y ago
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 13y ago
  > (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 13y ago
    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.
- adrr 13y ago
  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.
zrail 13y ago
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-compliant-web-applications/ http://kencochrane.net/blog/2012/01/developers-guide-to-pci-...
16s 13y ago
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.
JonFish85 13y ago
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 13y ago
  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.
lsh123 13y ago
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 13y ago
  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 13y ago
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 13y ago
  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.
ChikkaChiChi 13y ago
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.
nraynaud 13y ago
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 13y ago
  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.

36 points by fmavituna 13y ago

rayiner 13y ago

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

Robin_Message 13y ago
Payments Compliance(?) Industry(?) – rules you must follow to process credit card data. See https://www.pcisecuritystandards.org/ https://www.pcisecuritystandards.org/
benmanns 13y ago
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_Security_Standard https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...
makmanalp 13y ago
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 13y ago
  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

acd 13y ago

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 13y ago
What's the alternative to not having a readable number on the card when I want to purchase something online?
- drbawb 13y ago
  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/shopsafe.go https://www.bankofamerica.com/privacy/accounts-cards/shopsaf...
- deleted 13y ago
  [deleted]

Osiris 13y ago

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.

fmavituna 13y ago
You pretty much described 3D Secure - http://en.wikipedia.org/wiki/3-D_Secure http://en.wikipedia.org/wiki/3-D_Secure which is quite popular in Europe. Actually even mandatory in some countries.
Flenser 13y ago
> 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.

tptacek 13y ago

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 13y ago
> (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 13y ago
  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.
adrr 13y ago
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.

zrail 13y ago

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

16s 13y ago

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.

JonFish85 13y ago

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 13y ago
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.

lsh123 13y ago

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 13y ago
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 13y ago

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 13y ago
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.

ChikkaChiChi 13y ago

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.

nraynaud 13y ago

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 13y ago
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.