> that a company should not keep track of their individual sales? just some sort of large running grand total?
We're talking about the payment processor, not the merchant. It makes sense for a merchant to keep track of this information, less so for a payment processor. I'd expect the processor to delete/anonymize all the data past the chargeback/refund period.
Payment processors get audited, they need to store data for more than the chargeback/refund period. Plus, India deals with all kinds of instruments for which there isn't any "chargeback period" of sorts.
Disclaimer: I work at a competing payment org in India.
I think the whole point of India's project to abandon cash is to allow for tracking. If all this data is thrown away the entire excercise was pointless.
I'm not fully sure to what extent Juspay is used but one feature they use heavily is autofilling OTPs. Unlike the US, to make a card payment online according to RBI's guidelines, you need to enter a one time password that in most cases is sent to you over SMS.
What Juspay does is, it scans your SMSes and pastes the OTP automatically into the payment page. All the user has to do is click an approve button, streamlining the process as the user never has to exit the app.
not really, I worked on making this for another company. Reading is the simpler side of the story, the complex one is navigating the banking websites to be able to fill this in, and to maintain graceful degradation incase bank websites change
Indeed. You notice a variant of this with Plaid based integrations, common with roboadvisors to let you see a full-spectrum view of your accounts. The integrations which are based on the major banks that likely have tons of traffic fare okay. But if you've got 401ks from an employer provider that doesn't have a ton of traffic, you're in for some completely broken ugliness and no real major working protocol for your downstream applications to use.
I'm curious in particular about one thing you said, which is graceful degradation. What kinds of graceful degradation are you thinking about here?
At Amazon's scale they dont need to use a third party when they can do it themselves and payments is core functionality not some secondary feature which can be outsourced.
Juspay is one of the worst payment gateways anyway. It makes it impossible to pay for anything and I get scared whenever I see this stupid logo during payment.
Their site is an example of over-engineering designed to make seemingly simple things hard. Like for example, it always tries to detect OTP and fails most of the time. Then it obscures the Continue button and add an extra step.
But worse is their internet speed detection algo. Why in the world does a payment processor need to check my internet speed and show me a popup your internet connection is slow (happens mostly on 4G). Then it tries some refresh voodoo which makes the payment fail sometimes debiting the amount and failing (which takes 5 days to refund).
It's mind boggling that Amazon is one of their customers. Is nobody doing user-experience testing?
OTPs are big in India. Sent via SMS to your registered phone numbers, it is a popular way to authenticate a transaction or even login to your accounts.
That was the same argument that I heard against ATM skimmers ... until my city was hit by a massive wave of skimmer-related thefts about 5 years ago. My debit card got cloned too -- I woke up one fine evening to the sound of SMSes announcing withdrawals from my savings account :) The next morning, there was a crowd of almost 300 people waiting to file FIRs at the local police station. Apparently there were similar scenes in other localities as well. It looked like a fairly well-planned and well-executed operation. (Technological) effort is not a significant barrier for thievery as long as there is enough money to be made out of it.
Thats still smaller when the entire population is considered. Also lack of security will erode the trust in digital banking which is terrible for a developing country like ours
Now I'm confused :) Are you arguing for better security than OTPs, or against?
My claim is that OTPs aren't secure enough; the skimmer example was to illustrate that thievery in India can also employ technical sophistication, and hence that "secure technology" isn't much of a barrier against a sufficiently motivated set of actors.
But text messages and phone numbers are not a secure medium. I am on the fence whether SMS based OTP is actually a net positive for security. Probably helps with senior people not accustomed to using passwords, but it definitely lowers my security (I have a hardware token and generally try to disable SMS OTP)
Not sure where you are from but getting a SIM (mobile connection) or even getting your own SIM/number re-issued is not as simple as that is in many (western) countries.
Transfers/switches/porting always have a decent cool-off period. So while I am not saying it's as safe as it gets, I was just wondering whether you were assuming it's the same way in many other countries.
PS. Credit cards just can't work just based on credit card number, CVV, and expiry MMYYYY here either. You have got to have that SMS OTP auth and in many cases a password as well. Also, at POS (shops, restos etc) you must enter your PIN, it's not optional. (Now up to ₹2000 some cards let you just swipe/tap w/o a PIN, but it's an opt-in feature)
One issue still left: SMS are "relatively" easy to eavesdrop.
I am in the US. SIM reissuing scams are not uncommon and my own number was reassigned for half a week due to a technical glitch. During that time I had multiple conversations with customer support staff and it was ridiculous how many changes I could request without any verification or authentication.
The aim is to reduce the possibilities of getting robbed. Targeted attacks like sniffing SMSs of a user requires significantly more effort than just stealing their card.
As a counterpoint, Juspay's payments has always worked well for me, and the rotating logo personally inspires more trust than certain other wallet-cum-payment providers. I do all payments thru the web, and never on the phone, so that might apply.
I've also always had a flawless experience with Juspay payments, and their auto entering of OTPs is such a convenient feature! It baffles me why others haven't copied that yet.
> 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.
> 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.
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.
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?
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.
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.
51 comments
[ 6.2 ms ] story [ 104 ms ] threadget card details, do transaction with bank, send ACK to ecomm site and user, and done. why do they need to store these info?
that a company should not keep track of their individual sales? just some sort of large running grand total?
or perhaps some sort of anonymized database where they can see that stuff was sold, but not to who?
surely you can see the flaws here.
We're talking about the payment processor, not the merchant. It makes sense for a merchant to keep track of this information, less so for a payment processor. I'd expect the processor to delete/anonymize all the data past the chargeback/refund period.
Disclaimer: I work at a competing payment org in India.
What Juspay does is, it scans your SMSes and pastes the OTP automatically into the payment page. All the user has to do is click an approve button, streamlining the process as the user never has to exit the app.
reading OTP from SMS: to a layman, that's a rather small feature: and why doesn't Amazon do it by themselves ?
I'm curious in particular about one thing you said, which is graceful degradation. What kinds of graceful degradation are you thinking about here?
The Apple ecosystem has done this for years. Do Windows and Android not have similar features?
https://juspayproducts.medium.com/your-security-is-our-first...
Their site is an example of over-engineering designed to make seemingly simple things hard. Like for example, it always tries to detect OTP and fails most of the time. Then it obscures the Continue button and add an extra step.
But worse is their internet speed detection algo. Why in the world does a payment processor need to check my internet speed and show me a popup your internet connection is slow (happens mostly on 4G). Then it tries some refresh voodoo which makes the payment fail sometimes debiting the amount and failing (which takes 5 days to refund).
It's mind boggling that Amazon is one of their customers. Is nobody doing user-experience testing?
God that pisses me off so much. I hate seeing their logo nowadays online.
OTPs are big in India. Sent via SMS to your registered phone numbers, it is a popular way to authenticate a transaction or even login to your accounts.
My claim is that OTPs aren't secure enough; the skimmer example was to illustrate that thievery in India can also employ technical sophistication, and hence that "secure technology" isn't much of a barrier against a sufficiently motivated set of actors.
Transfers/switches/porting always have a decent cool-off period. So while I am not saying it's as safe as it gets, I was just wondering whether you were assuming it's the same way in many other countries.
PS. Credit cards just can't work just based on credit card number, CVV, and expiry MMYYYY here either. You have got to have that SMS OTP auth and in many cases a password as well. Also, at POS (shops, restos etc) you must enter your PIN, it's not optional. (Now up to ₹2000 some cards let you just swipe/tap w/o a PIN, but it's an opt-in feature)
One issue still left: SMS are "relatively" easy to eavesdrop.
I am in the US. SIM reissuing scams are not uncommon and my own number was reassigned for half a week due to a technical glitch. During that time I had multiple conversations with customer support staff and it was ridiculous how many changes I could request without any verification or authentication.
Their response to these accusations.
>Our card vault, in a different PCI-compliant store with encrypted card data, is secure.
Disclaimer: I work at a competing payment org in India.
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.
That's... cheap. And I doubt even slow algorithms will make it a hassle.
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.
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.