>>108638610
All of this is stupid because the premise is that it requires an authorized merchants terminal.
You can already steal $50-$100 depending on the card from ANY Visa or Mastercard by just tapping a merchant terminal to anyone's butt or approximate location of their wallet
You can do that a couple of times before someone reports the tx as fraud, your bank will block your account, the cops will get involved which have an easy time finding you because all your data is linked to the merchant terminal (which is one of the prerequisites for getting it in the first place).
So in the end you will go to jail for fraud AND not get any money anyway because your bank will freeze the merchant account before you can get any payout

Nice demo but useless in practice

>>108638643
You can't be this naive, criminals get those authorized merchant terminals with stolen identities and fake documents, they get hundred of them, then they transfer every hour the money to another account from a different bank, even to another country, when the terminal get flagged they continue using another one, they never use their own personal information, are you dumb?

File: average apple users are l(...).jpg (33 KB, 636x358)

33 KB JPG

>>108638643
ok butthurt applefag
have fun calling visa or apple when you owe $10k

>>108638658
name one instance of this happening

File: 1682489584425624.jpg (16 KB, 273x184)

16 KB JPG

>>108638667
whenever jeets are around

>>108638610
looks like linus tech tips' faggot son in the background

>>108640063
How's that approved terminal located in new delhi help you get 50 bucks from people in europe?

>>108638610
There are a number of limitations, but the exploit is retarded.

>>108640375
The terminal itself could be anywhere because you're MITMing it anyway.

>>108638643
bro I know somalians that are running SNAP fraud using merchant terminals that have been operating for 6+ years now without being caught. they drain tens of thousands of accounts of the full benefits each month.

>>108638610
VISA is the issue not iPhones. Because iPhones doesn't want to know how much you're spending, it does not check for values, it instead trust the data sent by the payment processor.

File: 1641628970520.gif (665 KB, 498x488)

665 KB GIF

>>108638610
iTODLERS BTFO!

File: IMG_0900.jpg (75 KB, 1170x907)

75 KB JPG

>>108638610
>>108638659
>>108641291
>uses Express mode
so a nothingburger?

>>108638610
isn't this solved by requiring your phone to be unlocked for the transaction to work, or for you to confirm the transaction by doing a secondary unlock after tapping?
>>108638643
this is why I lined my wallet with tinfoil when I got my first tap card. can't even notice it, it's those stupid pockets behind cards, between cards and the bill pocket.

>>108638610
Is that a boy or a girl?

>>108638610
We need IDs tied to devices to prevent this.

oh no it appears I have stored my card and phone on my penis haha please don't steal from me

apple just went "not our problem" and theyre kinda right

>>108641725
of course its a nothingburger, the new veritasium is private equity owned and a therefore a clickbait content mill now
they even split this video up into two parts for maximum ad revenue

>>108641725
Isn't that option enabled by default?

>>108641291
>Because iPhones doesn't want to know how much you're spending, it does not check for values
Incorrect.
But as pointed out in the video, there are other ways to set it up so that it still works the same but blocks this, the system Samsung has.
It's a problem that could be solved by either Apple or VISA, and neither want to do it. Easier to Apple to do, because a tiny system update that basically every user would install would do it, while VISA would need a shitton of terminals, including not normally internet connected terminals, to be updated.

>>108641818
>isn't this solved by requiring your phone to be unlocked for the transaction to work, or for you to confirm the transaction by doing a secondary unlock after tapping?
Na, the exploit takes advantage of Express mode, which is used for payments on public transport where you don't want to hold up lines by having to unlock and verify for the gate to let you through.

>>108638643
In theory you can take the proxy phone (using bluetooth/mobile data) into any store and buy expensive shit that is easy to sell.
I'm sure it would be possible to run the "exploit" directly on a rooted android phone, you could make a custom holder that keeps the stolen iPhone and proxmark together in your pocket, then connect to it with a long USB cable or a proxmark bluetooth module.
Of course you have to somehow hide your face because as soon as police get involved they are going straight to that store to collect CCTV footage.

>>108643128
They were doing clickbait before you were an itch in your dad's scrotum, lurk moar.

>>108644396
all as part of the acquisition process

>>108638643
>You can already steal $50-$100
Which is bad enough.
$10,000 - that's another matter.

>>108638610
Am I being gaslit here when he says MasterCard is safe? All he describes is just a asymmetric cryptography over a singular MITMed channel where the keys are not verified by a third party. That is NOT safe. The Attacker can just store your keys and forward their own. Unless atleast one of them is pinging the Bank to verify the key of the other party, that is not safe. Presumably that's what happens though, since the phone has to verify whether the terminal is actually authorized by the bank or not before the transaction.

Secondly, Why on this beautiful earth is the phone fucking allowed to just say that it has verfied things that the bank should be verifying. Your verification does not mean jackshit broski, preagree on a secret token with a bank (ideally never stored and thus generated on the fly by whatever method of authentication the device uses), encrypt the transaction data with it and let the bank figure out whether you've verified it or not.

Indians of all people figured this shit out with the UPI, because afaik, the pin is not checked locally and is sent over (xored with secret account deets and transaction id then hashed, I think(even if with just 10^6, it's only safe because it's throttled by the bank)) to the bank to verify, what in the actual fuck gives that fucking phone a right to think it can just say it has "verified" things without any proof of that verification.

>>108644478
Who in hell is designing these protocols by the way?
There's no way even a mildly competent cybersec guy thought of this tap to pay system. Was this hastily pushed by apple and forced to be adopted by everyone else?

File: 1751655903097242.jpg (128 KB, 1210x1510)

128 KB JPG

>>108643988
apple pay doesnt work the same as google pay
for the latter google acts as an intermediary signing

this is why it works for iphones, but not for android phones
the iphone always generates the payment signature locally, whereas the android phone delegates this to an external google server

>>108644478
>preagree on a secret token with a bank (ideally never stored and thus generated on the fly by whatever method of authentication the device uses), encrypt the transaction data with it and let the bank figure out whether you've verified it or not
this is how apple pay works

>>108644549
The video says that they literally just flip a bit in the protocol for the terminal to think that the transaction has been verified. No verification information is checked in with the bank.

>>108641671
BASADO

>>108644574
the secure enclave on the phone only signs a transaction, the verification is up to the bank
thats by design, apple doesnt want to process transactions

what youre arguing is for the iphone to verify the transaction instead
that only makes sense within the frame that its an effective solution to this vulnerability
outside of that, apple is right
its not their responsibility, and while not illegal, would be unprecedented since apple isnt part of the agreement between you and the bank

>>108644636
I'm not asking apple to verify shit. I'm asking to have a protocol where you to take a method of authentication (say your password), hash it, ask the bank to save it as a authentication token and then delete it. Now everytime a transaction is made, instead of signing it with a YES/NO, encrypt the confirmation part with the hash of the inputted password and let the bank try to decrypt it with the pre agreed token.

Apple has 0 burden to do any verification locally here. And it would stop someone from forging your sign.

>>108644636
>>108644714
You only have to do it in scenarios like these, replacing a binary confirmation, it's not an additional burden at all to any other scenario btw. All it requires is that when Apple Pay is given the super secret deets of the card, they talk a little more to ensure that nobody else can say YES/NO on their behalf.

>>108638610
it only affects visa according to all the research

>>108644636
>>108644714
What would solve this is that that transport mode is limited to $40 or so. There's no reason not to, and kinda crazy they didn't at least put some crazy number like $100 and equivalent in every currency.

Then it would just be the same as any card where lower transactions require no verification.

>>108644478
mastercard is safe because to dumb it down, the terminal requires the details of the transaction to be signed while visa only requires this sometimes.

>>108644794
More importantly, why can't there just be a saved table that gets updated in a while? It's not like everyone's changing their laws willy nilly everyday.

Even if there is an update, and the device is hasn't updated it's tables yet, what's the harm if it asks for verification until that happens?

>mastercard is safe because to dumb it down, the terminal requires the details of the transaction to be signed while visa only requires this sometimes.
If by signing you mean cryptographic signatures, that doesn't change much. I only know this mechanism as far as the video goes, but like I said, it is unsafe, no matter what, unless atleast one device (ideally the user's phone) can contact the payment processor or bank.

>>108644852
>unless atleast one device (ideally the user's phone) can contact the payment processor or bank.
Which I presume they can
I have never used this shit and thus I have no idea if it requires an internet connection at all. Cash is king.

Oh I realize what the problem is here, you're watching blackrock slop. I thought you guys were watching the nigger, in his video they explain it properly.

>>108644852
>More importantly, why can't there just be a saved table that gets updated in a while? It's not like everyone's changing their laws willy nilly everyday.
Sure. That's the weird part here.
>If by signing you mean cryptographic signatures, that doesn't change much. I only know this mechanism as far as the video goes, but like I said, it is unsafe, no matter what, unless atleast one device (ideally the user's phone) can contact the payment processor or bank.
The vulnerability is just tap-to-pay then. It allows small transactions without any verifications on 99% of cards these days. It's a little insecure, someone can take $40 ish a few times with a stolen card but that's generally considered worth it for the convenience.

>>108644913
>I thought you guys were watching the nigger, in his video they explain it properly.
I was watching whatever OP posted but thanks.

>It's a little insecure, someone can take $40 ish a few times with a stolen card but that's generally considered worth it for the convenience.
That's so fucking retarded

>>108644714
no need to get angry just because you dont understand how any of this works

banks will never allow you to have your own authentication method
other than that, its pretty much exactly how apple pay already works

>>108644994
What I suggested removes nothing on the bank's side of work to verify things. It's not auth for the transaction, it's auth for the confirmation anon, you know, the thing that's entirely unauthenticated in this transaction.

>>108644794
ive explained the reason but maybe not clearly enough
so let me restate: apple doesnt do it for legal reasons

>>108644733
>they talk a little more to ensure that nobody else can say YES/NO on their behalf.
and that doesnt happen, the secure enclave is still solely responsible for signing transactions
ultimately the phone isnt responsible for saying yes or no, its only job is to sign a transaction to validate it
after that its up to the bank to say yes or no

>>108645018
the confirmation is for the payment terminal, not the phone

>>108644977
>That's so fucking retarded
I mean you can think so but that's standard. I don't mind personally.
Actually there is a advantage to the customer with less security, your bank/creditor will have to reverse it if you say it was theft when there is no verification. With pin verification, they will blame you.

>>108645023
>so let me restate: apple doesnt do it for legal reasons
What would be the legal reasons to not block obviously fraud payments?
I think the legal implications of enabling these fraud payments when in any other usecase (such as with your card) they would be blocked are bigger. And a PR nightmare.

>>108645042
It is responsible for saying that it verified a LOW VALUE transaction made by a TRANSIT TERMINAL, which, as far as I can gather from this, is an important enough thing to verify that someone can siphon your entire bank account in a single transaction with it.

You clearly know more about apple pay than I do, but I hope you appreciate that whatever they are signing, does not include this critical information that can save the day. What it does, essentially, is allow any Terminal to have complete authority on what transaction is considered Low Pay and what type of transaction it's authorized for, which clearly, it being the device hypothetically controlled by the party who receives monetary gain from said transaction, is god awfully designed.

>>108645075
And what I'm saying is that neither the phone or the Payment Terminal, should have that authority in this case. Even if the Terminal needs to know in the moment if the transaction was verified in case it's offline, that's just blowing a fucking hole through the window, because now you're saying that it's the User that has to be bumfucked by the wishes of the terminal, and not the other way around.

What you seem to be ignoring that while it's only this Apple+VISA combination that works for the MITM attacker, a malicious terminal, can do it for any card (and possibly more phones than just the iphone, depending on how the responses work). How this is even remotely justifiable according to you, is beyond me.

I don't think that the guy asking me for my money should have the liberty of showing me one receipt and then sending another to the bank for the cash out.

>>108645110
it would set the precedent that apple is a payment processor
this would make them liable for transactions, and not just the general security of the system
but more importantly, it would inevitably force apple to open up apple pay to third party vendors

if you want an analog, think of apple as a card manufacturer, thales and idemia arent reponsible for the verification of transactions either

>>108638610
tl;dr just turn off transit mode.

>>108638610
Yea no shit, this is why I ask my bank to disable NFC on my cards.

>>108644478
>Secondly, Why on this beautiful earth is the phone fucking allowed to just say that it has verfied things that the bank should be verifying. Your verification does not mean jackshit broski, preagree on a secret token with a bank (ideally never stored and thus generated on the fly by whatever method of authentication the device uses), encrypt the transaction data with it and let the bank figure out whether you've verified it or not.
Because payment networks and processors have just become boomer parasite companies that survive off regulation. The reality is they're extremely unsafe and run of ancient, unsafe tech and standards. But because how of strict the regulatory body surrounding finance is, it's difficult for anyone to compete with them even though it's about as secure as vibe coded dogshit made by a jeet over one weekend.

>>108645174
No it does not. You're being incredibly disingenuous.

If Apple is allowed to get a DAN number to link with the card, they should be allowed to also keep an auth token on hand, to encrypt the details of the payment happening between the device and Terminal too. This does not further their involvement one bit.

Hell, just fucking encrypt that information with the private key you already have received with the DAN, and include that in the protocol. That adds literally zilch to Apple's involvement in this and completely eradicates this fraud.

>>108645153
>What it does, essentially, is allow any Terminal to have complete authority on what transaction is considered Low Pay and what type of transaction it's authorized for, which clearly, it being the device hypothetically controlled by the party who receives monetary gain from said transaction, is god awfully designed.
this is what ive been trying to explain, that is just not within the scope of apple pay
it is up to the payment processor to implement additional security measures, which mastercard has done by using asymmetric signatures, and visa deems unnecessary because transactions still rely on bank authorisation regardless

>What you seem to be ignoring that while it's only this Apple+VISA combination that works for the MITM attacker, a malicious terminal, can do it for any card (and possibly more phones than just the iphone, depending on how the responses work). How this is even remotely justifiable according to you, is beyond me.
this is explained in the video
visa justifies this by shifting responsibility to the bank, which has to authorise all transactions

now is that fair?
in theory everyone needs to all the security, always, meaning apple should implement more strict validation and visa should implement a secure handshake
but in the real world it just doesnt matter
fraud is fraud, you can get your money back anyway
and if this is costing you as a bank a lot in compensation, you can disable apple pay or switch to mastercard
the system is working as intended

>>108645240
thats exactly what happens with mastercard issued cards

>>108645174
>it would set the precedent that apple is a payment processor
It wouldn't, that's incredibly farfetched. Actually the only thing that would happen is that they wouldn't get this bad PR. And it's a 1 line code change and a ~190 table of values.

They are already liable for setting up this whole system with "transit transactions" that don't need verification.

>but more importantly, it would inevitably force apple to open up apple pay to third party vendors
Of what?! Payment protocols? Because they had a sanity check?

>>108645240
>If Apple is allowed to get a DAN number to link with the card, they should be allowed to also keep an auth token on hand, to encrypt the details of the payment happening between the device and Terminal too. This does not further their involvement one bit.
You're still overcomplicating. All they need is "if value > 100*currency_value".

>>108645354
>>108645354
>now is that fair?
>in theory everyone needs to all the security, always, meaning apple should implement more strict validation and visa should implement a secure handshake
I never said it was on Apple. What Apple should and indeed can do is implement a sane maximum for "Low Value" transactions, I said this is a protocol issue and both payment processors and banks have the responsibility to sort it out, and more to that, I've just been arguing that is comically bad,

>>108645405
Mastercard's precautions secure communication between the device and the terminal. As far as I can tell about the protocol (which is how Visa gets away with it), what the terminal advertised about the transactions to the device is never actually forwarded securely to the banks, which should get to see and be the final judge what the limits on Low Value transaction are. A malicious terminal can still just send you false information and as long as the iphone says "sure", because Apple is staffed by morons, Mastercard can't protect against it.

>>108645419
>You're still overcomplicating. All they need is "if value > 100*currency_value".
Fair enough, but a bad protocol is a bad protocol, you can't have that loophole in spec for idiots like Apple to shoot themselves in the foot with. It's supposed to be standard between leading financial bodies that govern possibly most of the world populace's finances. You are not allowed to be sloppy.

For a deeper review, I can only find Visa's Transaction Acceptance Device specifications for this. Why is this entire protocol not public? Overlooking things like these is exactly why open protocols are promoted.

>>108640472
Most banks flag transactions from "unrealistic travel".

>>108644514
The primary goal was to make it easy to spend money and for it to be compatible with as many devices as possible. The people calling the shots on these systems are not programmers.
If a securely programmed system makes it any more difficult for people to spend their money, some money is instead spend lobbying to allow for insecure protocols with a lot of "This is not our threat model" types of exceptions to pass.

>>108643963
not for me