Reply to post: thoughts... Re: ma1010 "Sounds like a lawsuit"

thoughts... Re: ma1010 "Sounds like a lawsuit"

My guess is that they never accessed her card details at all, but instead repeatedly charged against a card-on-file token that they'd legitimately kept for her card. How they got to doing that could be one of those few differences between debit cards and credit cards, and how their booking system didn't properly deal with them. (I'd be surprised if the hotel's booking system itself ever handled the card details - that's normally handed off to a third-party service due to the high PCI-DSS compliance cost of doing it yourself).

What they're most likely doing is asking for the customer's details to be retained on file with their card acceptor service, for later use. The result of that operation is a random-ish payment token that can be given back to the acquirer to make charges against that card in future.

My guess is that she was, unfortunately, the first customer to present a debit (not credit) card to the hotel. Debit cards have a subset of the functions of a credit card, so the returned information from a card acceptor will be smaller set of fields than for a debit card, with some values set to NULL (or missing, which can be the same thing depending on how you process the response). And that's where I think the fun would have begun...

If I wanted to make this happen, here's how I'd do it:

1. The response from card acquirer has NULL for a field that "always" has a value when used with a credit card, but despite that, still contains a usable "charging" token that can be used to raise charges against the card.

2. The unexpectedly-NULL field is used as the first term in a concatenation operation to generate a key to identify that card, but because of concatenation-to-NULL, the whole result ends up as NULL.

3. As there's not a card on file already there with NULL as its local "unique" id, the victim's card token gets stored into the "cards on file" table with the "unique ID" of NULL, but the correct token.

4. That card-on-file ID (NULL) gets stored against the first customer's booking record.

5. (later) The hotel booking system looks up the token for the first customer and charges the customer.

But...

Another customer with a debit card arrives, and steps 1..3 repeat as before, but this time, because there's already a card on file with the "unique" ID of NULL, the first customer's charging token gets associated with the new customer's booking.

...Repeat until the first customer gets very,very mad..

Incidentally, PCI-DSS doesn't cover the handling of stored tokens such as this, as they cannot be used to reconstitute a customer credit card account, and they bind exactly one merchant to the card (you can give someone else the token you acquired, but if they use it, the money still goes into your merhcant account, not theirs).