3 ms·

> Some places we recommend putting these include: Databases where you store customer payment information alarm klaxon sounds Why do you have a database contai

> Some places we recommend putting these include: Databases where you store customer payment information alarm klaxon sounds Why do you have a database containing customer payment information?

loeg 4y ago
Reducing friction in repeated transactions? Someone needs to store it.
- jameshart 4y ago
  Unless you’re an actual payment platform, that someone should not be you.
  - NavinF 4y ago
    There's a tradeoff. Card numbers in your db are a lot easier to move between payment platforms than tokenized card numbers. So many merchants get screwed by payment platforms that lock them out right in the middle of a large sale because the sudden increase in transactions looks like fraud. You gotta look out for number one.
croes 4y ago
Shopping sites?
hn92726819 4y ago
Do you think companies avoid storing this data? There's no reason for them not to, so they do it. Look at the target hack for an example of real word credit card info stored. Also, tons of companies have one-click payment options (ever order something from Chipoltle or Dominos app?) Edit: It should be disincentivised, but look at any "punishment" for a data leak and it's cheaper for them to just lose the data
- jameshart 4y ago
  PCI-DSS compliance auditing is not cheap. There’s the incentive right there. Individual retailers have no need to store actual cardholder information. All the payment platforms provide ways to persist cardholder information, in a way that allows it to be reused but never read.
  - philsnow 4y ago
    > All the payment platforms provide ways to persist cardholder information, in a way that allows it to be reused but never read. This is usually called tokenization, if you want to search for it.
lxgr 4y ago
To charge payments to customers? Yes, in many cases you can have your payment service provider store that data for you, but sometimes that's impracticable.
- jameshart 4y ago
  Interested in exactly when it becomes impractical. Personally I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for. Honestly shocked by how much pushback I've had on this on this thread. I feel like I made a fairly innocuous comment that, essentially, was just suggesting that it's probably best practice to avoid storing customer card details in your own database. That seems to me about as uncontroversial as saying 'you should not be storing plaintext passwords', but apparently, judging from the replies I've seen, it's hopelessly naive, and you can't actually handle payments without storing CC numbers. Which comes as a bit of a surprise to me, as in my day job I work on an e-commerce system that handles a billion dollars of credit card transactions a year, including stored payment methods and processing recurring billing - and we haven't got a single credit card number in any of our databases. So I kind of suspect it can be done.
  - lxgr 4y ago
    > Interested in exactly when it becomes impractical. Having multiple payment service providers, for example (or the plan to do so in the near future). Another example would be complex legacy systems (especially in the travel segment, constellations between various service providers get complex quickly). > I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for. No objections there :) > you can't actually handle payments without storing CC numbers. Now you're putting up a straw man. It's definitely not impossible, but in some circumstances, it can be very hard. Also, somebody will have to store the PANs in a database in the end, even if it's just the payment service providers themselves. There are much less payment service providers than merchants out there, but by the same logic, that makes them a much more valuable goal for attackers.
  - eastbayjake 4y ago
kmoser 4y ago
> Why do you have a database containing customer payment information? To seed with canary credit card numbers! But seriously, for widely implemented (i.e. not-proprietary) databases of CC numbers it would be great if there were more automated ways of seeding them with CC canaries. Sort of a "LetsEncrypt for CC databases." E.g. for CCs saved by your browser, I'd like to see a plugin that lets you use one click to seed that DB with a few random CCs. The whole idea would be to reduce the burden on the end user, who we all know will probably not take the time to do this manually.

> Some places we recommend putting these include: Databases where you store customer payment information alarm klaxon sounds Why do you have a database containing customer payment information?

loeg 4y ago

Reducing friction in repeated transactions? Someone needs to store it.

jameshart 4y ago
Unless you’re an actual payment platform, that someone should not be you.
- NavinF 4y ago
  There's a tradeoff. Card numbers in your db are a lot easier to move between payment platforms than tokenized card numbers. So many merchants get screwed by payment platforms that lock them out right in the middle of a large sale because the sudden increase in transactions looks like fraud. You gotta look out for number one.

croes 4y ago

Shopping sites?

hn92726819 4y ago

Do you think companies avoid storing this data? There's no reason for them not to, so they do it. Look at the target hack for an example of real word credit card info stored. Also, tons of companies have one-click payment options (ever order something from Chipoltle or Dominos app?) Edit: It should be disincentivised, but look at any "punishment" for a data leak and it's cheaper for them to just lose the data

jameshart 4y ago
PCI-DSS compliance auditing is not cheap. There’s the incentive right there. Individual retailers have no need to store actual cardholder information. All the payment platforms provide ways to persist cardholder information, in a way that allows it to be reused but never read.
- philsnow 4y ago
  > All the payment platforms provide ways to persist cardholder information, in a way that allows it to be reused but never read. This is usually called tokenization, if you want to search for it.

lxgr 4y ago

To charge payments to customers? Yes, in many cases you can have your payment service provider store that data for you, but sometimes that's impracticable.

jameshart 4y ago
Interested in exactly when it becomes impractical. Personally I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for. Honestly shocked by how much pushback I've had on this on this thread. I feel like I made a fairly innocuous comment that, essentially, was just suggesting that it's probably best practice to avoid storing customer card details in your own database. That seems to me about as uncontroversial as saying 'you should not be storing plaintext passwords', but apparently, judging from the replies I've seen, it's hopelessly naive, and you can't actually handle payments without storing CC numbers. Which comes as a bit of a surprise to me, as in my day job I work on an e-commerce system that handles a billion dollars of credit card transactions a year, including stored payment methods and processing recurring billing - and we haven't got a single credit card number in any of our databases. So I kind of suspect it can be done.
- lxgr 4y ago
  > Interested in exactly when it becomes impractical. Having multiple payment service providers, for example (or the plan to do so in the near future). Another example would be complex legacy systems (especially in the travel segment, constellations between various service providers get complex quickly). > I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for. No objections there :) > you can't actually handle payments without storing CC numbers. Now you're putting up a straw man. It's definitely not impossible, but in some circumstances, it can be very hard. Also, somebody will have to store the PANs in a database in the end, even if it's just the payment service providers themselves. There are much less payment service providers than merchants out there, but by the same logic, that makes them a much more valuable goal for attackers.
- eastbayjake 4y ago

kmoser 4y ago

> Why do you have a database containing customer payment information? To seed with canary credit card numbers! But seriously, for widely implemented (i.e. not-proprietary) databases of CC numbers it would be great if there were more automated ways of seeding them with CC canaries. Sort of a "LetsEncrypt for CC databases." E.g. for CCs saved by your browser, I'd like to see a plugin that lets you use one click to seed that DB with a few random CCs. The whole idea would be to reduce the burden on the end user, who we all know will probably not take the time to do this manually.