[0x5FC3]

Its limited to about $1000 a day.

The QR is a URI with the ID, amount and maybe other stuff. It's a client-side implementation.

RuPay sure "works within the system" but is pretty much useless for international payments/subscriptions. Not really a VISA/MasterCard replacement.

[bigfishrunning]

So people scan a QR code, and then enter a secure banking pin? this sounds like a security problem waiting to happen...

[wiradikusuma]

The QR code doesn't open a link. It's just "gibberish" text only usable by app that can understand it (e.g. banking apps).

(I don't know anything about UPI, but in Indonesia we use a similar system)

[porridgeraisin]

Its not gibberish text.

Its just a URI.

  upi://pay?pa=payeeID&pn=payeeName

You can add things like &am= to prefill the amount. Merchant txns have reference IDs and all that stuff.

[bigfishrunning]

And that's the problem -- all i have to do is come up with a website that looks enough like your banking app, and get you to scan the uri to that website, and that'll trick you into giving me your pin.

this is why QR codes, especially ones with complicated encoded uris, are a security problem. they're very hard for leypeople to audit before doing the wrong thing

[porridgeraisin]

No. You don't scan the QR with your camera or whatever. You open the app and scan it inside there. And there's no website. Only mobile apps in devices where attestation and full device/SIM binding is possible are allowed. The SIM has to match the one you register with your bank as well. And once you register (which involves 2FA with your bank), the device/app identity is frozen. And then there is a transaction-time secret which is your 6 digit UPI pin. Obviously, just knowing someone's PIN is useless - I know all my close friends PINs. Its just 6 digits after all. Even 4 is allowed. This is checked at the end of the line in the bank's server.

Client only talks to the payment service provider server which checks attestation, And only those few approved PSPs can talk to the NPCI server. And only the NPCI server can talk to banks.

The core code used by all the PSPs is the same, there is a common SDK that they have to use to be approved. There is a common test suite for the server side as well, that each PSP has to pass for certification.

PSPs like Google pay that aren't banks themselves, are called TPAPs, and they have to first partner with a willing bank. And you get TPAP client -> TPAP server -> partner bank server -> NPCI in the chain above. This is mostly for regulatory reasons.

Client side security though, relies on

1) app when registering sends an SMS to the bank, the bank uses the telecom-network side ID (and not the number in the SMS body), and checks that this number is attached to the bank.

2) play integrity/device attestation

Attaching a SIM to a bank requires in person KYC, so does buying a SIM.

So to break it you need

1) play integrity exploit on the targets phone + getting them to actually install your app and getting your app on the play store Or 2) a SIM swap attack on the target, which involves KYC/biometric forging/in person social engineering at the telecom providers shop.

Even if you SIM swap, the bank will check with the telco if you recently got a new SIM and restrict high value transactions for a while. The telco themselves will have a cooldown period. Some banks you can make you do in person KYC again at the bank's side. My bank requires this when you replace SIMs.

Similarly when you change phones, you get stricter limits for a while. Because the device fingerprint changes (with the SIM being the same).

You can do all that and get... 1000$. And there are per month limits, etc, which you can tweak yourself with your bank.

Of course there is the purely scammer route, where you scam someone into paying you money, authorising it themself. For these things there is usual risk-based stuff. The payee name you as the scammer give the victim has to match the one in your scammer bank account. And merchant payments / individual payments are differentiated, so the user gets visual indication that they are paying a person and not a company. And so on.. here obviously it is defense in depth and not cryptographic defense, since the user is the one authorising.

[bigfishrunning]

given this explanation, i concede that it's somewhat likely that my QR-code-spidey-senses were too sensitive here

[unmole]

> all i have to do is come up with a website that looks enough like your banking app, and get you to scan the uri to that website, and that'll trick you into giving me your pin.

It is not how any of this works. But sure, keep up the uninformed fear mongering.

[Imustaskforhelp]

I am Indian and I think what you are saying is correct. It opens up the banking app or in our case UPI providers app so like Google pay, Phonepe,paytm, Bhim UPI and other such apps.

[SanjayMehta]

It depends on the QR code:

1. Static QR codes displayed by the vendor have the problem you describe.

2. Dynamic QR codes are time limited, have the amount embedded in them along with the destination. These are the ones generated by websites or POS terminals for payment. Most people will only use these at a POS terminals, pay and move on.

Fraudulent websites have used static QR codes but I'm told one can dispute the transaction and the amount is usually reversed in a couple of days.

[unmole]

QR code based payment systems have been widely used across Asia for well over a decade. That doesn't stop randos on HN from middlebrow fear mongering.