Payment processor for Amazon India had leak of over 100M users
businessinsider.in
businessinsider.in
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.
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.
https://juspayproducts.medium.com/your-security-is-our-first...
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?
get 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.
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.