33

I have a credit card saved to my primary Paypal account. To make a long story short, I needed to make another Paypal account that would not be connected to my original one.

I used a different computer, which had never been logged in to my original one. When I tried to register my credit card to the account, Paypal told me I was unable to register it, as they said

this card is already linked to a different Paypal account.

How can they possibly know that? Shouldn't my credit card be stored with a hash under my account only? How and why is Paypal keeping all their registered cards in one big file for cross-reference?

TheAsh
  • 495
  • 1
  • 4
  • 6
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/96934/discussion-on-question-by-theash-how-can-paypal-know-my-card-is-being-used-in-an). – Rory Alsop Aug 01 '19 at 19:03

5 Answers5

82

There are a couple reasons why Paypal (or more generally, any payment service) can know if you've used your card in more than one place.

Your credit card is absolutely tracked everywhere possible

Shouldn't my credit card be stored with a hash under my account only?

If your card is kept hashed then it can be easily compared across accounts. Hashes are deterministic, so for a fixed hashing algorithm a given credit card will always give the same hash. Therefore if they were storing hashes, they could easily compare across accounts and determine if the card was already stored elsewhere. Doing so can be advantageous, as in this case it is being used to prevent fraud (the implication is that if the same card is added to multiple accounts, it is likely due to fraud). Once you have a "secure" hash of a credit card, there's no reason not to check it across different accounts. Paypal certainly can and does.

However, this ability isn't limited to Paypal, and can easily be available to much smaller merchants. For instance with Stripe (a common PCI-compliant payment method) the merchant will be given a unique identifier for each credit card number stored on Stripe. The merchant doesn't keep (or even see) the card number, but they can still compare the given hash against other card hashes that have been used in their systems. This can (and is) easily used for the less-altruistic purpose of tracking a user's buying history across multiple accounts and anonymous transactions, while still maintaining PCI compliance.

So to be clear, your credit card is tracked absolutely everywhere by as many people as can keep their hands on it, even if they don't know your credit card number themselves.

Paypal keeps your actual credit card number on file - not just a hash

Smaller merchants can and should make sure and never store, transmit, or even look at actual card details. However, there is no requirement that forbids any merchant from keeping the actual card number if they so desire. In general though any merchant that wants to keep card numbers on file and remain PCI compliant will (theoretically) have to go through stricter validation, security auditing, and effectively have to pay a ton of money in fees. The increased costs and liability of keeping credit card numbers on file while remaining PCI compliant are so large that any moderately well run small-medium business will never try.

However, large businesses can and do choose to do otherwise. The reality is that someone has to store card numbers somewhere so that your card can be billed. The larger credit card processors (which Paypal definitely is) certainly store the full card number. They should store the numbers using strong encryption and secure keys/access control procedures.

As for the details of how they actually determine that a credit card number is used twice, ultimately only Paypal can answer that. They may have a method for comparing encrypted card numbers directly, but more likely they also store a hash of the card numbers and compare those directly (h/t Jory Geerts). Either way though, they do keep your card number on file, and they can compare card numbers against accounts.

Note that this doesn't mean that they are "Keeping all registered cards in one big file for cross-reference". Their infrastructure for secure card storage is certainly far more complicated than that. However, they obviously have a compelling business need to be able to compare cards across accounts, and have setup their infrastructure so that they can both store your cards securely and also check for duplicates across accounts. I agree with the linked comment: I would guess that they are also calculating a secure hash of the credit card number and using that for easy comparisons.

Community
  • 1
Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • 2
    "I'm sure they are just comparing credit card numbers directly." So if someone hacks them, we're all screwed? – TheAsh Jul 29 '19 at 04:07
  • 34
    @TheAsh yes. Ditto if someone hacks Visa. Although in reality this is where PCI compliance is supposed to help. Then again it's not just Paypal: a well-known gaming company I worked for stores full credit card numbers for all their popular MMO subscribers - but again, in full compliance with PCI. – Denis Jul 29 '19 at 10:13
  • @Denis at least they did so in in a PCI compliant fashion. I did contract work for a large number of small businesses related to e-commerce, and knew of at least one of them that, effectively, kept plain text copies of card details on office computers. They at least did B2B commerce, so only ever caused trouble for businesses and not consumers... – Conor Mancone Jul 29 '19 at 10:41
  • 8
    "I'm sure they are just comparing credit card numbers directly." As far as I'm aware, PCI-DSS requires things like encryption. Decrypting everything is pretty expensive (in terms of CPU time). In addition, it puts the "cardnumber comparision service" in a higher "scope" (meaning "lots of rules") vs something that just compares some hashes but never touches an actual card number. So in my opinion, comparing hashes is far easier than comparing the actual numbers. – Jory Geerts Jul 29 '19 at 11:57
  • @JoryGeerts Good point. I was just pointing out the fact that they do in fact have full credit card details on hand, rather than trying to make strong statements about how they might actually do the comparison. As a result I've updated that section. – Conor Mancone Jul 29 '19 at 12:15
  • I used to develop ATM software for a living and it's not as easy as you make it sound. First of all I am certain that "full credit card details" are not being stored as it's forbidden to store the card security code (or the full mag-stripe but this is less relevant for Paypal). Also, for encryption we used a dedicated hardware encryption module where only the two security officers possessed half of the key and it does not have a "decrypt" command (just commands for encrypting the data under another key which must have been manually entered before) – Hans Jul 29 '19 at 13:28
  • "Paypal keeps your actual credit card details on file". Unfortunately, with your latest edit, you effectively didn't answer the question. Of course they keep the information on file (otherwise I wouldn't be able to purchase anything), my question is, do they have a large unencrypted megafile showing all the accounts and credit card numbers linked? Or do they merely store the card info under each account never comparing the information, as I thought they should? – TheAsh Jul 29 '19 at 13:45
  • @TheAsh one more update for you. They definitely don't have a large unecnrypted mega file. – Conor Mancone Jul 29 '19 at 14:45
  • 5
    I used to work for a company which stored credit card numbers. They were encrypted via HSM, so that no-one could get its hands on the keys for off-line decryption, and network traffic to the HSM was heavily restricted and monitored. – Matthieu M. Jul 29 '19 at 15:31
  • @ConorMancone and due to that edit, I've accepted your answer. – TheAsh Jul 29 '19 at 16:39
  • @MatthieuM. The way it should be! And yet, credit card theft is still big business. There's too many people who don't do it right (although it also doesn't matter how secure your credit card storage is if an attacker injects themselves somewhere else in the process, which has happened countless times. https://www.theregister.co.uk/2018/09/12/feedify_magecart_javascript_library_hacked/ – Conor Mancone Jul 29 '19 at 16:52
  • 1
    @TheAsh Ironically this just came out today: https://gizmodo.com/a-hacker-stole-capital-one-data-on-106-million-customer-1836806812. Which is to say that, indeed, when financial institutions themselves are hacked, consumers get screwed. – Conor Mancone Jul 30 '19 at 13:37
  • 2
    Am I doing the math wrong? A hash you can search of credit cards is worthless. ~4 digits of issuer ID leaves 12 digits of any real randomness; searching a trillion hashes is trivial. To avoid this you need a really strong salt, and such a salt makes searching by hash impractical. – Yakk Jul 30 '19 at 15:00
  • 3
    @Yakk Credit cards have even less entropy than that. The first digit is the company, the last digit is a check digit, and there are other small constraints on the card number. You can crank up the cost factor on many hashing algorithms, but I'm curious how a CC number **would** be securely hashed - it's even worse than passwords. I think that there are some large companies that use hashes, and so I presume that there is a "right" way to do it, but either of those statements could be wrong. – Conor Mancone Jul 30 '19 at 15:08
  • 1
    @ConorMancone *nod*, even with a megabyte of salt, that blocks rainbow tables but doesn't make the attack vs use ratio much better. – Yakk Jul 30 '19 at 15:15
  • @Yakk and this is why you should usually regard your credit-card number as effectively public information. While the CVC should be somewhat private, everything printed on the front of your card is just to easily copied. – Falco Jul 31 '19 at 13:06
  • @ConorMancone For the OP's purposes, a database may well be comparable to a "mega file," but of course they won't be in plain text. – jpaugh Jul 31 '19 at 21:14
  • @Yakk Your comment is precisely the intent of my question. – TheAsh Aug 02 '19 at 02:14
22

PayPal is a payment processor, not a merchant, they need to pass the card number to your bank (or card issuer) when they're processing payments, so they need to store your credit card in a way that can be decrypted back to card numbers. To comply with PCI-DSS, they'll have to encrypt these information on their servers and comply with all of the more stringent PCI-DSS requirements, but they cannot use a one way hash to store the information and still able to process payment.

With that said, even if they store the information in a one way hash, it's still fairly straightforward to find numbers that are exact match for duplicate detection.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
6

Card numbers have long been a part of PayPal's risk assessment process. We used to use their Website Payments Pro product, and sometimes we'd have an issue where someone would put their card number into our checkout and PayPal would reject it because

  1. It was associated with a PayPal account with a fraud alert on it (sometimes as internally assessed by PayPal)
  2. The card had been seen previously in bad actor activity

This all predated PCI compliance. #1 was problematic because it literally required the customer to call PayPal and resolve the issue directly (sometimes on accounts closed for years). This is not new activity by PayPal.

PCI does not necessarily prohibit this. Card numbers can be stored in totality, as can expiration dates. Only CVV2 numbers are prohibited from being stored. If you store the card data like that, you have to meet certain security criteria (see this question for some details)

Machavity
  • 3,766
  • 1
  • 14
  • 29
1

They will have a rule that a card may only be linked once. The image they use to probe may not be plain text, and it may have been "packed" (COMP-3 or BCD) before hashing but it should be entropic enough (high cardinality) to avoid collisions.

It will not just be the number, it will also be the expiry date, and possibly the cvv. All credit card numbers start with a 4 digit BIN, and end with a check digit based upon the Luhn algorithm. They are necessarily recycled as there are a finite number of digits left, especially when Visa and MasterCard banks might use the next two or three digits for sub product information. I know of one bank that used the first 10 digits for certain cards issued to staff as employees. So sooner or later someone else gets your number when you get another number.

It is a very simple matter to probe an index for an existing value.

mckenzm
  • 469
  • 2
  • 6
-3

The other answers assume Paypal stores the full details, plus a hash to perform the comparison.

This is likely incorrect in general. In modern credit card security, especially for e-commerce transactions, credit card account numbers are switched for tokens, often limited to a single merchant:

Visa card tokenization

(From an explanatory document available on Visa's site).

A merchant will likely receive a constant token for each card. Additional details - such as the user's account number - can also be returned. Depending on how tokenization is handled, it's possible for these tokens to be unusable by other merchants, possibly negating the need for hashing or encryption.

Clockwork-Muse
  • 640
  • 4
  • 8
  • 2
    You're misunderstanding the question. This is not about tokenization – Machavity Jul 29 '19 at 22:41
  • @Machavity - how so? If a token is constant for the merchant (that is, PayPal), then necessarily they would be able to compare the token in place of the card number. – Clockwork-Muse Jul 31 '19 at 02:51
  • In Step #1 the customer enters their PAN **and Visa stores it**. Which is what PayPal is doing to the OP. Furthermore, if they issued the same token for the same PAN every time it would be far easier to reverse engineer the token to determine the PAN. There's no guarantee the PAN is even part of the token generation process either. More importantly, PayPal has been doing this for over a decade – Machavity Jul 31 '19 at 03:25
  • @Machavity - The process would be - give PAN to PayPal, PayPal passes it to Visa, Visa returns token (or some other identifier), PayPal stores/uses token. This limits PayPal's PCI compliance worries. The primary reason to use PayPal is so websites don't have to worry about integrating with Visa themselves. And the underlying technology could certainly have changed over time. `Furthermore, if they issued the same token for the same PAN every time it would be far easier to reverse engineer the token to determine the PAN.` ... you mean, like hashing the PAN? – Clockwork-Muse Jul 31 '19 at 17:10
  • @Clockwork-Muse Please remember that [PayPal is not a merchant](https://security.stackexchange.com/a/214247/88532). In fact, they provide payment services to merchants. If a merchant can get a token via PayPal, then PayPal has to generate that token, and must have the original card details on hand in order to process payments against the real card, not the token. – jpaugh Jul 31 '19 at 21:17
  • It would be possible for them to use credit card providers to do some work on their behalf, but there's no requirement that they do this; they simply must pay higher fees and pass more stringent security checks for the privilege of storing credit cards themselves. Even some larger merchants do this, and I'd be surprised if a payment processor did not do their own payment processing: otherwise, where's their business model? What keeps Visa from offering the same services directly to Paypal's customers, and putting them out of business? – jpaugh Jul 31 '19 at 21:20
  • @jpaugh - Because they handle more than just Visa - they handle multiple card types, stored value, and more. If I'm programming a web application, I don't want to handle multiple processors/gateways - I just want one widely recognized one, and to be done with it. – Clockwork-Muse Jul 31 '19 at 22:50
  • Mastercard does something similar too: https://masterpass.com/en-us.html – ave Aug 01 '19 at 08:06
  • @Clockwork-Muse That's a good point; but it is also further reason that they would need to store credit cards in order to have a business model: they can't expect Visa and Master Card to offer their services in the same way; so they'd have to do their own "leg work" (so to speak) in order to provide a consistent experience to the merchants. – jpaugh Aug 02 '19 at 18:04
  • @jpaugh - that makes no sense. With datasets as large as they have, a flow and database per issuer isn't unlikely. Adapters and mapping classes are almost certain, _even if they store the full number_. Plus, given you can use things like bank accounts or "refund credits" in PayPal, the simplest way to give a consistent merchant experience is just to return the merchant a transaction id with "success". No card details, no nothing (for a number of reasons they likely do return some details, though). PayPal hides the differences between issuers for the merchants. – Clockwork-Muse Aug 02 '19 at 18:27
  • @Clockwork-Muse At this point, either of us are probably guessing; but to return a *consistent* transaction ID, I'd expect they would first have to make one, since Visa and MasterCard aren't obligated to return the same kind of number, or offer a consistent experience to PayPal's customers. Visa might have a transaction ID of a hash of the date and dollar amount while the MC might return a GUID. Then again, PayPal could actually have an SLA which obligates Visa and MasterCard to present transaction IDs (and tokens or whatever else) in the same way. – jpaugh Aug 02 '19 at 18:37