3 ms·

Wow, that's great (/s)! Next-gen ransomware can then finally allow zero-click payment of the ransom instead of all the convoluted "go to that site, register acc

Wow, that's great (/s)! Next-gen ransomware can then finally allow zero-click payment of the ransom instead of all the convoluted "go to that site, register account, buy bitcoin, send to address X, don't forget to add gas,..."-mess.

nih0 5y ago
this will make my job a lot easier! thanks @ms
hbn 5y ago
Can you clarify what you had in mind for this? Are you imagining the ransomware would grab users' locally-stored credit card info? In which case, is there reason to believe they'd actually be storing your card info locally? Isn't it more likely that after initially adding your card, it stays on MS servers as it does now, and this settings screen only gets sent the last 4 digits of your credit card? Or am I misunderstanding and/or missing something obvious?
- archi42 5y ago
  You can interpret my comment as part joke since I really hope that zero-click attacks on the payment method will not be possible, but also part "uuh, that can go wrong". I expect MS to reduce the user friction to some minimum, since less friction = more users = more profit. But often security adds friction ("enter your payment pin or click here if you forgot it", "we need to verify your payment, please follow steps x, y and z", "Please enter the code we send to your mobile +15551234",...). I imagine a low friction scenario in which the user only clicks a button to pay (e.g. s/he clicks an article in a newspaper application and have to confirm a UAC-style popup "Do you want to buy this stuff for x Pound Eurodollars?"). Even less friction if the user can allow an application s/he trusts to trigger payments without further user interaction (e.g. a pay-as-you-read newspaper application). A local attacker could abuse both scenarios. So yeah, I could imagine that (given some bad design or implementation decisions) even while all the critical data is stored on the MS servers, a local attacker could trigger fraudulent payments.

nih0 5y ago

this will make my job a lot easier! thanks @ms

hbn 5y ago

Can you clarify what you had in mind for this? Are you imagining the ransomware would grab users' locally-stored credit card info? In which case, is there reason to believe they'd actually be storing your card info locally? Isn't it more likely that after initially adding your card, it stays on MS servers as it does now, and this settings screen only gets sent the last 4 digits of your credit card? Or am I misunderstanding and/or missing something obvious?

archi42 5y ago
You can interpret my comment as part joke since I really hope that zero-click attacks on the payment method will not be possible, but also part "uuh, that can go wrong". I expect MS to reduce the user friction to some minimum, since less friction = more users = more profit. But often security adds friction ("enter your payment pin or click here if you forgot it", "we need to verify your payment, please follow steps x, y and z", "Please enter the code we send to your mobile +15551234",...). I imagine a low friction scenario in which the user only clicks a button to pay (e.g. s/he clicks an article in a newspaper application and have to confirm a UAC-style popup "Do you want to buy this stuff for x Pound Eurodollars?"). Even less friction if the user can allow an application s/he trusts to trigger payments without further user interaction (e.g. a pay-as-you-read newspaper application). A local attacker could abuse both scenarios. So yeah, I could imagine that (given some bad design or implementation decisions) even while all the critical data is stored on the MS servers, a local attacker could trigger fraudulent payments.