3 ms·

> The breach was restricted to an isolated system containing non-sensitive masked card primarily used for display purposes on merchant UI and cannot be used for

> The breach was restricted to an isolated system containing non-sensitive masked card primarily used for display purposes on merchant UI and cannot be used for completing a transaction. All of the customers’ full card numbers, order information, card PINs, or passwords are secure. The compromised data does not contain any transaction or order information. https://juspayproducts.medium.com/your-security-is-our-first-concern-8d98c96e5f17 https://juspayproducts.medium.com/your-security-is-our-first... From this posting's article: > In this case, Juspay has hashed the 16-digit debit and credit card numbers in order to process transactions. > Juspay has masked only six digits out of sixteen-digit card numbers. Rajaharia says that while this is good, the safety of users rests primarily on the hashing algorithm.

grenoire 6y ago
So wait; if the hashing algorithm is known, salted or otherwise it should be extremely easy to discover the unhashed card numbers, right? If I understood the masking part, that means you only need 1,000,000 guesses with whatever hashing algorithm. That's... cheap. And I doubt even slow algorithms will make it a hassle.
- deleted 6y ago
  [deleted]
- lemonspat 6y ago
  Ya, but if only six of the 16 are hashed, I'm trying to think of where an attacker will deduce the other 10? It's a known integer space, but how do they know which 10 belong to the other 6?
  - paulryanrogers 6y ago
    Is there a Luhn check digit?
- sirn 6y ago
  Unfortunately, credit card security for traditional online payment rely on payment processor actively blocking bruteforce attempts and CVC number never being stored to stay secure. Masking six digits out of sixteen digits is a very common practice in the industry. The first 6 is BIN which is sort-of public data (full BIN table are distributed by Visa/Master only to acquirer/issuer, but some acquirer may provide them for free to a payment processor/merchant), next 6 is not unique enough since it depends on issuer's scheme so last 4 is used for identifying a card with the middle 6 masked. I don't know about this particular case (and it depends on QSA), but if the number is in any way reversible e.g. a plain hash(card_number), it would put any system that store that hash in a PCI-DSS storage scope. I once worked with a system that solve this issue by having unique salt to each card, but the salt is never exposed outside of PCI-DSS scope. This prevent rainbow table attack, but still open to brute force. 3-D Secure was suppose provide a better security for online transactions by requiring a second factor (e.g. OTP), but it introduces a lot of hassle since it rely on HTTP POST from a client's browser (thus the "Your payment is being processed. Please do not refresh this page." screen), add two extra vendors to trust (ACS/MPI), and the card is still usable with merchants that doesn't enforce 3-D Secure (though I'm not sure if this is the case with India), making the whole scheme similar to having a tightly locked door with a window open wide. The scheme protects merchant more due to liability shift which removes them from being liable to chargebacks. 3-D Secure 2.0 tries to fix the hassle part by requiring merchant and payment processor to send data about the transaction back to the bank (email address, previous transaction info, shipping address, etc. which may be a privacy issue) and letting them decide whether a transaction should require an extra authentication.
vishnugupta 6y ago
> Juspay has hashed the 16-digit debit This is factually incorrect. It’s more like a DB pointer to salted-hash which in turn gets recalculated once a week or so. I’ve worked with their team, known their systems reasonably well. I’ve also lead a team that built a card store system that held nontrivial number of cards. Storing card hash anywhere will result in failing PCI audit. While the data breach is indeed bad please don’t read too much into the media reporting. It’s one thing to report the breach but this article takes it to another level by sensationalizing it.

grenoire 6y ago

So wait; if the hashing algorithm is known, salted or otherwise it should be extremely easy to discover the unhashed card numbers, right? If I understood the masking part, that means you only need 1,000,000 guesses with whatever hashing algorithm. That's... cheap. And I doubt even slow algorithms will make it a hassle.

deleted 6y ago
[deleted]
lemonspat 6y ago
Ya, but if only six of the 16 are hashed, I'm trying to think of where an attacker will deduce the other 10? It's a known integer space, but how do they know which 10 belong to the other 6?
- paulryanrogers 6y ago
  Is there a Luhn check digit?
sirn 6y ago
Unfortunately, credit card security for traditional online payment rely on payment processor actively blocking bruteforce attempts and CVC number never being stored to stay secure. Masking six digits out of sixteen digits is a very common practice in the industry. The first 6 is BIN which is sort-of public data (full BIN table are distributed by Visa/Master only to acquirer/issuer, but some acquirer may provide them for free to a payment processor/merchant), next 6 is not unique enough since it depends on issuer's scheme so last 4 is used for identifying a card with the middle 6 masked. I don't know about this particular case (and it depends on QSA), but if the number is in any way reversible e.g. a plain hash(card_number), it would put any system that store that hash in a PCI-DSS storage scope. I once worked with a system that solve this issue by having unique salt to each card, but the salt is never exposed outside of PCI-DSS scope. This prevent rainbow table attack, but still open to brute force. 3-D Secure was suppose provide a better security for online transactions by requiring a second factor (e.g. OTP), but it introduces a lot of hassle since it rely on HTTP POST from a client's browser (thus the "Your payment is being processed. Please do not refresh this page." screen), add two extra vendors to trust (ACS/MPI), and the card is still usable with merchants that doesn't enforce 3-D Secure (though I'm not sure if this is the case with India), making the whole scheme similar to having a tightly locked door with a window open wide. The scheme protects merchant more due to liability shift which removes them from being liable to chargebacks. 3-D Secure 2.0 tries to fix the hassle part by requiring merchant and payment processor to send data about the transaction back to the bank (email address, previous transaction info, shipping address, etc. which may be a privacy issue) and letting them decide whether a transaction should require an extra authentication.

vishnugupta 6y ago

> Juspay has hashed the 16-digit debit This is factually incorrect. It’s more like a DB pointer to salted-hash which in turn gets recalculated once a week or so. I’ve worked with their team, known their systems reasonably well. I’ve also lead a team that built a card store system that held nontrivial number of cards. Storing card hash anywhere will result in failing PCI audit. While the data breach is indeed bad please don’t read too much into the media reporting. It’s one thing to report the breach but this article takes it to another level by sensationalizing it.