First six and last four are the limits for display set out by the PCI Security Standards Council. The things you should never store with the PAN are the PIN/PIN block or CVC/CVV.

https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storag...

While it complies with PCI standards, knowing first6+last4, plus contact information, you can be much more successful at phishing against the target.

First6 will give you ability to know the issuing bank of the card (so an email can be crafted to look like those banks emails). Plus last4 tends to be used by banks as a "hey, we know who you are!" when they send emails.

You might need them to reverse or refund the transaction with some payment gateways. Or if you are going to settle the funds at a time after authorization when shipping

How does that work? If you can't store the CVC/CVV, how come I don't have to re-enter it when I re-order form say Amazon or Foodora? Or maybe I do have to enter it? Don't remember :|

Most MSP (merchant service provider) gives you control over the details you personally want to capture to verify someone. The minimum and most insecure is simply approving card based on valid number! (Not even expiration date). Then you can enable EXP, CVV and AV (address verification). Fun tip about AV: your adres doesnt matter. There is so many spellings of "oak harbour drive apartment 2" that industry pretty much gave up on some smart AI knowing them all, it and only verifies the zip code (typical gas station card usage for credit cards: verification is your zip code)

Address line 1 in AVS is still used, however, only the numeric portion of the address is checked. The AVS results will generally tell you the individual match results for the address line and the postal code, so you can have a full match or a partial match. Most merchants will allow you through with a partial match.

A secure token is provided by the credit card processor that the vendor can safely store and reuse after the first successful transaction.

https://en.wikipedia.org/wiki/Tokenization_(data_security)

They are registering the fact that you knew it and used it to ship to a specific address in a previous transaction in order to reduce fraud risk. They aren't submitting it with every transaction. (Assuming they are following the rules...)

Amazon, specifically, never asks for CVC/CVV in the first place.

It is not required for charging a card, it is for reducing fraud.

Neither first six nor last four are considered PCI sensitive data. Not saying they should be randomly displayed, but in the context of many fintech apps they will be displayed together.

First 6 is shared across the cards a particular bank issues. Its not a secret as you can google the first 6 to find the bank or even the reverse google the bank to see what BINs they use. Last 4 is intended to be human visible so people can identify the card in use. When you factor in the check digit ruling out 90% of the remaining combinations, there are still 10,000 valid cc combinations plus an expiration date you would have to guess just to get a single acct.

They were publishing the expiry date too.

More details as an explanation.

Facebook was providing:

  Cardholder Name
  First 6
  Last 4
  Expiry Date
  Billing Address.

The only bits missing were CVV and the middle 6.

Yes, first 6 and last 4 are not considered sensitive for PCI compliance. However, like most security standards, the standard is a minimum, not what your target should be.

Given the ability for attackers to quickly guess CVV and the remaining digits[1], the attack becomes a numbers game. They don't care about _a_ card, they care about _any_ card.

This is why Visa and MasterCard are pushing to tokenize all cards - so the stored information is linked to the merchant storing it and can't be reused.

That's even before we take into account the account take over possibilities since those card details are used by other companies as verification for account recovery[2]. Yes, those vulnerabilities were closed, but that doesn't stop new companies from making the same mistakes.

Yes, it's impressive that they managed to prune the fields so quickly. Shows a very efficient escalation path!

[1] https://www.theregister.co.uk/2016/12/05/undetectable_sixsec...

[2] https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking...

Random question I've never found a place to ask before. Is there a formal language or method for specifying information like this, where I could map out different pieces of data and reason about how the pieces of data flow through a system, to prove mathematically that two (or n) pieces of data are never available in the same place?

You might model software data and operations in some formal system at various levels using a language like "coq" and develop some formal verification proofs. I've not read this book that apparently explores verifications like these: "Certified Programming with Dependent Types: ...".

I'm not sure what types of enterprises actually use formal verification since it's very costly. Writing software is much faster than verifying it. Embedded auto, aerospace, industrial applications, sure. Facebook? I doubt it.

Such methods could be useful, maybe coupled with fuzzing, for breaking software too. It might suggest avenues for exploit.

Systems like coq are used more naturally in math proofs, but even there it's very hard to apply.

It came up for me when designing a custodial management system for cryptocurrencies, where you could design it in such a way that the different steps/sensitive data were divided among separate systems and communication channels. I wanted some way to divide up responsibilities for processing a transaction (initiation, audit, control, approval, transmission) and then prove that any single component could be 100% compromised without allowing further unauthorized transactions. Even introducing temporary transformations (encryption/hashing) and re-routing keys specifically to prevent collisions of that data.

I noticed how similar the thought process was to GDPR work I've been involved in, where, for example, we can keep track of Last name and Phone Number in our company, but they could never be at rest unencrypted and unhashed in the same system. Or First Name + Job Title + Location but only 2 of those three can co-exist. It seemed like the kind of thing that would have a formal way of expressing. Our GDPR consultants were unhelpful in that.

You should vs human nature. We introduce bugs. Please don't be cynical, and cheer this up.

Kudos to facebook team that they responded shortly, I cannot tell if it was work hours or not, but either way, this is very very short in the context of large corporations.

I don't read at all the cynicism you seem to read.

A: that was fast!

B: that's because it was very serious!

Where is the cynicism? Can it not be summarized as: they fixed a serious issue very quickly?

"That's because you should never have first 6 and last 4 in the same place at the same time, particularly to someone who is not the owner of the card!"

Sounded to me more like "of course they fixed it fast, this is a serious issue", and undermined the speed it get resolved. Probably my bad.