5 ms·
I worked at a bank on the backend for architecture and security.. and I've posted this attestation here before, but the sheer volume of fraud and fraud attempts
by browningstreet 7mo ago
I worked at a bank on the backend for architecture and security.. and I've posted this attestation here before, but the sheer volume of fraud and fraud attempts in the whole network is astonishing. Our device fingerprinting and no-jailbreak-rules weren't even close to an attempt at control. It was defense, based on network volume and hard losses.
Should we ever suffer a significant loss of customer identity data and/or funds, that risk was considered an existential threat for our customers and our institution.
I'm not coming to Google's defense, but fraud is a big, heavy, violent force in critical infrastructure.
And our phones are a compelling surface area for attacks and identity thefts.
- gzread 7mo agoThen don't issue an app. Issue people cards to pay with and let them come to the bank for weird transactions.
- quesera 7mo agoThat'd be great, if your goal was to hemorrhage customers.
- drnick1 7mo agoThis 100%. I don't understand why everything needs to be an app nowadays. Some things are best done in person and without to technology. No, I won't install some shitty app that requests location and network access to order lunch. If a venue does not provide a paper menu and accept cash, they have just lost my custom.
- pas 7mo agoRevolut seems to work without physical presence. And the website and app of my bank with offices is ... how should I put it ... a bit Kafkaesque. The obvious thing banks should be doing is putting fucking restrictions on these accounts by default and let people ask for exceptions. And of course if regulations don't encourage them to pick social-engineering-proof defaults then things won't improve.
- catdog 7mo agoYou can even use the chip on the card together with some cheap HW device to authorize the transactions made with the app. This actually exists [1] for quite some time but seems to be mostly limited to Germany. But this and the use of other HW tokens systems is on decline. Banks increasingly use apps now, increasingly without any meaningful second factor, not even offering better options. They want this and are fully to blame. [1] https://en.wikipedia.org/wiki/Transaction_authentication_number#ChipTAN_/_Sm@rt-TAN_/_CardTAN https://en.wikipedia.org/wiki/Transaction_authentication_num... (This is a bit outdated, nowadays it works via QR codes instead of those flickering barcodes but the concept stays the same)
- browningstreet 7mo agoGo find a bank without an app.
- ls612 7mo agoDo you allow customers to log in to their account with a web browser on a windows machine?
- browningstreet 7mo agoWeb browsers are secure fingerprinted as well, on a sliding scale of access requests, from login to "initiate a wire transfer for $1M".
- josephg 7mo agoI wish we had technical solutions that offered both. For example, a kernel like SeL4, which could directly run sandboxed applications, like banking apps. Apps run in this way could prove they are running in a sandbox. Then also allow the kernel to run linux as a process, and run whatever you like there, however you want. Its technically possible at the device level. The hard part seems to be UX. Do you show trusted and untrusted apps alongside one another? How do you teach users the difference? My piano teacher was recently scammed. The attackers took all the money in her bank account. As far as I could tell, they did it by convincing her to install some android app on her phone and then grant that app accessibility permissions. That let the app remotely control other apps. They they simply swapped over to her banking app and transferred all the money out. Its tricky, because obviously we want 3rd party accessibility applications. But if those permissions allow applications to escape their sandbox, and its trouble. (She contacted the bank and the police, and they managed to reverse the transactions and get her her money back. But she was a mess for a few days.)
- JuniperMesos 7mo ago> (She contacted the bank and the police, and they managed to reverse the transactions and get her her money back. But she was a mess for a few days.) And this almost certainly means that the bank took a fraud-related monetary loss, because the regulatory framework that governs banks makes it difficult for them to refuse to return their customer's money on the grounds that it was actually your piano teacher's fault for being stupid with her bank app on her smartphone (also, even if it were legal to do so, doing this regularly would create a lot of bad press for the bank). And they're unlikely to recover the losses from the actual scammers. Fraud losses are something that banks track internally and attempt to minimize when possible and when it doesn't trade-off against other goals they have, such as maintaining regulatory compliance or costing more money than the fraud does. This means that banks - really, any regulated financial institution at all that has a smartphone app - have a financial incentive to encourage Apple and Google to build functionality into their mass-market smartphone OSs that locks them down and makes it harder for attackers to scam ordinary, unsophisticated customers in this way. They have zero incentive to lobby to make smartphone platforms more open. And there's a lot more technically-unsophisticated users like your piano teacher than there are free-software-enthusiasts who care about their smartphone OS provider not locking down the OS. I think this is a bad thing, but then I'm personally a free-software-enthusiast, not a technically-unsophisticated smartphone user.
- nijave 7mo agoYeah, I worked at a bank once. I was told following policy and using dependencies with known vulnerabilities so my ass was covered was more important than actually making sure things were secure (it was someone else's problem to get that update through the layers of approval!). Needless to say, I didn't last long
- basilikum 7mo agoHow does preventing people from running software of their choice on their own device (what you call jailbreaking) prevent fraud in practice? It's a pretty strong claim you're making there. And it's being made frequently by institutions, yet I have never seen it actually explained and backed up with any real security model. All the information and experience I ever got tells me this is security theater by institutions who try to distract from their atrocious security with some snake oil. But I'm willing to be convinced that there is more to it if presented with contraindicating information. So I'm interested in your case. How did demanding control over your customers' devices and taking away their ability to run software of their choice in practice in quantifiable and attributable terms reduce fraud?
- browningstreet 7mo agoThe app does fingerprinting and requires certain secure device profile characteristics before the app lets a user initiate certain kinds of financial transactions. Those are based on APIs available from the mobile devices. Google and Apple can offer other means by which to secure these things, and to validate that the device hasn't been cracked and is submitting false attestations. But even a significant financial institution has no relationship with Apple on the dev side of things.. Apple does what it decides to do and the financial institution builds to what is available. These controls work -- over time fraud and risk go down.
- basilikum 7mo agoI know what device attestation is. You did not answer my question.
- browningstreet 7mo ago"and taking away their ability to run software of their choice in practice" Who did that?