11 ms·

Banks seem to actually "want" Play Integrity. At least they act like it. I bet they would like for normal online banking on user-controlled devices to completel

Banks seem to actually "want" Play Integrity. At least they act like it. I bet they would like for normal online banking on user-controlled devices to completely go away.

IshKebab 1y ago
Only because it's there. I don't think the would demand it if it wasn't offered, but once it's there imagine being in a bank and saying to management "it recommend we don't enable this security feature that works on 99.99999% of phones".
- mhast 1y ago
  As someone who used to work for a bank building applications I would say no. This is definitely a feature companies and organizations like banks would request if it wasn't available. There are a lot of scams targeting vulnerable people and these days attacking the phone is a very "easy" way of doing this. Now perhaps there is a more forgiving way of implementing it though. So your phone can switch between trusted and "open" mode. But realistically I don't think the demand is big enough for that to actually matter.
  - const_cast 1y ago
    Play integrity does almost nothing to prevent malicious actors. In fact, id say overall it's probably more harmful because it gives actors like Banks false confidence. Even with play integrity, you should not trust the client. Devices can still be compromised, there are still phony bank apps, there are still keyloggers, etc. With the Web, things like banks are sort of forced to design apps that do not rely on client trust. With something like play integrity, they might not be. That's a big problem.
    - brookst 1y ago
      That’s a “seatbelts so no good because people still die in car crashes” argument with a topping of “actually they’re bad because they give you a false sense of security” Play integrity hugely reduces brute force and compromised device attacks. Yes, it does not eliminate either, but security is a game of statistics because there is rarely a verifiably perfect solution in complex systems. For most large public apps, the vast majority of signin attempts are malicious. And the vast majority of successful attacks come from non-attested platforms like desktop web. Attestation is a valuable tool here.
      - pona-a 1y ago
        How does device attestation reduce bruteforce? Does the backend not enforce the attempt limits per account? If so, that's would be considered a critical vulnerability. If not, then attestation doesn't serve that purpose. As for compromised devices, assuming you mean an evil maid, Android already implements secure boot, forcing a complete data wipe when breaking the chain of trust. I think the number of scary warnings is already more than enough to deter a clueless "average user" and there are easier ways to fish the user.
        Sayrus 1y ago
        And those apps use MEETS_DEVICE_INTEGRITY rather than MEETS_STRONG_INTEGRITY so a compromised device can absolutely be used to access critical services. (Usually because strong integrity is unsupported on old devices) This reminds me of providers like Xiaomi making it harder to unlock the bootloader due to phones being sold as new but flashed with a compromised image.
        pona-a 1y ago
        Maybe a good compromise is to change the boot screen to have a label that the phone is running an unofficial ROM, just like it shows one for unlocked bootloaders? If the system can update that dynamically based on unlock state, why can't it do it based on public keys? Might also discourage vendors/ROM devs from using test keys like Fairphone once did.
        drewbug 1y ago
        Pixels with, for example, GrapheneOS already do exactly that: "Your device is loading a different operating system."
        mike_hearn 1y ago
        I developed this stuff at Google (JS puzzles that "attest" web browsers), back in 2010 when nobody was working on it at all and the whole idea was viewed as obviously non-workable. But it did work. Brute force attacks on passwords generally cannot be stopped by any kind of server-side logic anymore, and that became the case more than 15 years ago. Sophisticated server-side rate limiting is necessary in a modern login system but it's not sufficient. The reason is that there are attackers who come pre-armed with lists of hacked or phished passwords and botnets of >1M nodes. So from the server side an attack looks like this: an IP that doesn't appear anywhere in your logs suddenly submits two or three login attempts, against unique accounts that log in from the same region as that IP is in, and the password is correct maybe 25%-75% of the time. Then the IP goes dormant and you never hear from it again. You can't block such behavior without unworkable numbers of false positives, yet in aggregate the botnet can work through maybe a million accounts per day, every day, without end. What does work is investigating the app doing the logging in. Attackers are often CPU and RAM constrained because the botnet is just a set of tiny HTTP proxies running on hacked IoT devices. The actual compute is happening elsewhere. The ideal situation from an attacker's perspective is a site that is only using server side rate limiting. They write a nice async bot that can have tens of thousands of HTTP requests in flight simultaneously on the developer's desktop which just POSTs some strings to the server to get what they want (money, sending emails, whatever). Step up the level of device attestation and now it gets much, much harder for them. In the limit they cannot beat the remote attestation scheme, and are forced to buy and rack large numbers of genuine devices and program robotic fingers to poke the screens. As you can see, the step-up from "hacking a script in your apartment in Belarus" to "build a warehouse full of robots" is very large. And because they are using devices controlled by their adversaries at that point, there's lots of new signals available to catch them that they might not be able to fix or know about. The browser sandbox means you can't push it that far on the web, which is why high value targets like banks require the web app to be paired with a mobile app to log in. But you can still do a lot. Google's websites generate millions of random encrypted programs per second that run inside a little virtual machine implemented in Javascript, which force attackers to use a browser and then look for signs of browser automation. I don't know how well it works these days, but they still use it, and back when I introduced it (20% time project) it worked very well because spammers had never seen anything like it. They didn't know how to beat it and mostly just went off to harass competitors instead.
    - mike_hearn 1y ago
      I've worked on such systems. Love it or hate it, remote attestation slaughters abuse. It is just much harder to scale up fraud schemes to profitable levels if you can't easily automate anything. That's why it exists and why banks use it.
      - ulrikrasmussen 1y ago
        Wouldn't device-bound keys for a set of trusted issuing secure elements (e.g. Yubikeys) work just as well but without locking down the whole goddamn software stack?
        mike_hearn 1y ago
        RA schemes don't lock down the whole software stack, just the parts that are needed to allow the server to reason about the behavior of the client. You can still install whatever apps you want, and those apps can do a lot of customization e.g. replace the homescreen, as indeed Android allows today. You need to attest at least the kernel, firmware, graphics/input drivers, window management system etc because otherwise actions you think are being taken by the user might be issued by malware. You have to know that the app's onPayClicked() event handler is running because the human owner genuinely clicked it (or an app they authorized to automate for them like an a11y app). To get that assurance requires the OS to enforce app communication and isolation via secure boundaries.
        ulrikrasmussen 1y ago
        That's waay too much locking down, and while it gives me some control, it does not give me real control. I cannot remove or modify software in the software stack whose behavior I disagree with (e.g. all of Play Services). I can't replace the OS with a more privacy and security focused OS like GrapheneOS. Imagine if this was done for desktop computers before we had smartphones. That's just crazy. Relying on hardware-bound keys is fine, but then the scope of the hardware and software stack that needs to be locked down should be severely limited to dedicated, external hardware tokens. Having to lock down the whole OS and service stack is just bad design, plain and simple, since it prioritizes control over freedom.
  - IshKebab 1y ago
    > This is definitely a feature companies and organizations like banks would request if it wasn't available. Really? Because they've been fine without this feature on desktop for literally decades.
  - cyphar 1y ago
    Unfortunately, this kind of thinking leads to insane situations such as the South Korean banking cartel which requires users to install several pieces of "security software"[1] which make your computer more vulnerable to security issues[2] and almost certainly doesn't protect anyone from actual fraud -- classic security theatre. There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. [1]: https://palant.info/2023/01/02/south-koreas-online-security-dead-end/ https://palant.info/2023/01/02/south-koreas-online-security-... [2]: https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-mandatory-financial-security-software-becomes-a-backdoor-and-a-target/ https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-ma...
    - cyphar 1y ago
      > There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. That is to say, banks are not the only entities in existence. If they really need such high security to avoid scams and losing such large sums of money they should just issue bank customers with a locked down device that can only be used for banking (maybe banks can collaborate on a standard for it so you can have one device for multiple banks). To be clear, I would still probably be strongly against such a proposal but at least we would be talking about a somewhat understandable approach.
- wkat4242 1y ago
  On the other hand, it's not really up to the bank. It's my money, not theirs. I really wish I wouldn't need to have my money managed by some corporate drones in suits but it's really hard these days to do without a bank account. This is why I was really into crypto at the beginning; it envisioned giving us control abck over what's ours. But all the KYC crap and the wishes of the speculators for more oversight basically made crypto the same nasty deal as the public banking sector.
- blueg3 1y ago
  It is desired enough that plenty of developers license third party libraries that roll their own device attestation, instead of or in addition to Play Integrity.
ulrikrasmussen 1y ago
What's absurd though is that they have never demanded it for browsers. I think there is a much higher risk of someone being tricked into downloading a compromised browser with a backdoor than someone being tricked into downloading a modified version of their particular banking app. It gives the attacker the same level of control though.
- mike_hearn 1y ago
  Banks have never accepted browsers. They don't need to because they can require the web app be paired with a mobile app or SMS code to log in. Before they used mobile apps they issued smartcard readers (at least they did everywhere I lived). The smartcard readers were also used to digitally sign transactions. In other words, there aren't many banks that let you take sensitive actions with just a browser and that's been true since the start of online banking. These days they also apply differential risk analysis based on the device used to submit a transaction and do things to push people towards mobile. For instance in Switzerland there's now a whole standard for encoding invoices in QR codes. To pay those you must use the mobile apps. Edit: people are getting hung up on the "never accepted browsers" part. It means they only use the browser for unimportant interactions. For important stuff like login or tx auth, they expect the use of separate hardware that's more controlled like a SIM card/mobile radio, smartcard or smartphone app. Yes some banks are more lax than others but in large parts of the world this was always true since the start of online banking.
  - ulrikrasmussen 1y ago
    Thats ... false. Every bank I have used in Denmark allows me to log in and do all operations without an app. They require authentication and authorization using the national digital identity (MitID) which comes as an app, but also as a TOTP token and a FIDO (or similar) chip. No apps needed. I guess the smartcard reader is equivalent. But my point is that locking down the OS of the phone is sufficient to establish client trust but not necessary. You should always be allowed to run the app without strong Play Integrity verification but then just be required to scan your hardware token with NFC in every authentication and authorization flow.
terminalshort 1y ago
Of course they do, and of course they would. Banks are in a crazy legal position where they are financially liable for user stupidity. If my bank account gets breached, it doesn't matter that I didn't take any reasonable security measures, the bank will still have to refund me. If the bank could say "you didn't follow our recommended security practices to use a PW manager and MFA or passkeys, so it's a FAFO situation for you," then they wouldn't be pushing for this stuff. But they can't do that because the government doesn't allow them to. There is even government regulator pressure now for financial services to be liable for cases where the user legitimately authorizes a transaction to a party that turns out to be a scammer. Of course the banks want to watch your every move and control your devices. They would be stupid not to given the incentives.
- palata 1y ago
  If they want to do it properly, they can use the Android hardware attestation: https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu...
- blizdiddy 1y ago
  In what country do you live? In America, users are liable for the banks stupidity. If they don’t verify credentials and give away all of my money, I do NOT get it refunded, they are NOT responsible, and I am the victim of “identity theft.”
  - deleted 1y ago
    [deleted]
  - terminalshort 1y ago
    I live in America. I have got back every single cent I have lost due to fraudulent charges on my account. Furthermore, I was refunded instantly by the bank pending investigation.
    - cromka 1y ago
      Are you mixing up fraudulent credit card charges? Because that's a whole lot other story. I can't even imagine you would be able to get any fraudulent debit card charges back from the bank.
RobotToaster 1y ago
Because it allows them to outsource "security", for "free".

Banks seem to actually "want" Play Integrity. At least they act like it. I bet they would like for normal online banking on user-controlled devices to completely go away.

IshKebab 1y ago

Only because it's there. I don't think the would demand it if it wasn't offered, but once it's there imagine being in a bank and saying to management "it recommend we don't enable this security feature that works on 99.99999% of phones".

mhast 1y ago
As someone who used to work for a bank building applications I would say no. This is definitely a feature companies and organizations like banks would request if it wasn't available. There are a lot of scams targeting vulnerable people and these days attacking the phone is a very "easy" way of doing this. Now perhaps there is a more forgiving way of implementing it though. So your phone can switch between trusted and "open" mode. But realistically I don't think the demand is big enough for that to actually matter.
- const_cast 1y ago
  Play integrity does almost nothing to prevent malicious actors. In fact, id say overall it's probably more harmful because it gives actors like Banks false confidence. Even with play integrity, you should not trust the client. Devices can still be compromised, there are still phony bank apps, there are still keyloggers, etc. With the Web, things like banks are sort of forced to design apps that do not rely on client trust. With something like play integrity, they might not be. That's a big problem.
  - brookst 1y ago
    That’s a “seatbelts so no good because people still die in car crashes” argument with a topping of “actually they’re bad because they give you a false sense of security” Play integrity hugely reduces brute force and compromised device attacks. Yes, it does not eliminate either, but security is a game of statistics because there is rarely a verifiably perfect solution in complex systems. For most large public apps, the vast majority of signin attempts are malicious. And the vast majority of successful attacks come from non-attested platforms like desktop web. Attestation is a valuable tool here.
    - pona-a 1y ago
      How does device attestation reduce bruteforce? Does the backend not enforce the attempt limits per account? If so, that's would be considered a critical vulnerability. If not, then attestation doesn't serve that purpose. As for compromised devices, assuming you mean an evil maid, Android already implements secure boot, forcing a complete data wipe when breaking the chain of trust. I think the number of scary warnings is already more than enough to deter a clueless "average user" and there are easier ways to fish the user.
      - Sayrus 1y ago
        And those apps use MEETS_DEVICE_INTEGRITY rather than MEETS_STRONG_INTEGRITY so a compromised device can absolutely be used to access critical services. (Usually because strong integrity is unsupported on old devices) This reminds me of providers like Xiaomi making it harder to unlock the bootloader due to phones being sold as new but flashed with a compromised image.
        pona-a 1y ago
        Maybe a good compromise is to change the boot screen to have a label that the phone is running an unofficial ROM, just like it shows one for unlocked bootloaders? If the system can update that dynamically based on unlock state, why can't it do it based on public keys? Might also discourage vendors/ROM devs from using test keys like Fairphone once did.
        drewbug 1y ago
        Pixels with, for example, GrapheneOS already do exactly that: "Your device is loading a different operating system."
      - mike_hearn 1y ago
        I developed this stuff at Google (JS puzzles that "attest" web browsers), back in 2010 when nobody was working on it at all and the whole idea was viewed as obviously non-workable. But it did work. Brute force attacks on passwords generally cannot be stopped by any kind of server-side logic anymore, and that became the case more than 15 years ago. Sophisticated server-side rate limiting is necessary in a modern login system but it's not sufficient. The reason is that there are attackers who come pre-armed with lists of hacked or phished passwords and botnets of >1M nodes. So from the server side an attack looks like this: an IP that doesn't appear anywhere in your logs suddenly submits two or three login attempts, against unique accounts that log in from the same region as that IP is in, and the password is correct maybe 25%-75% of the time. Then the IP goes dormant and you never hear from it again. You can't block such behavior without unworkable numbers of false positives, yet in aggregate the botnet can work through maybe a million accounts per day, every day, without end. What does work is investigating the app doing the logging in. Attackers are often CPU and RAM constrained because the botnet is just a set of tiny HTTP proxies running on hacked IoT devices. The actual compute is happening elsewhere. The ideal situation from an attacker's perspective is a site that is only using server side rate limiting. They write a nice async bot that can have tens of thousands of HTTP requests in flight simultaneously on the developer's desktop which just POSTs some strings to the server to get what they want (money, sending emails, whatever). Step up the level of device attestation and now it gets much, much harder for them. In the limit they cannot beat the remote attestation scheme, and are forced to buy and rack large numbers of genuine devices and program robotic fingers to poke the screens. As you can see, the step-up from "hacking a script in your apartment in Belarus" to "build a warehouse full of robots" is very large. And because they are using devices controlled by their adversaries at that point, there's lots of new signals available to catch them that they might not be able to fix or know about. The browser sandbox means you can't push it that far on the web, which is why high value targets like banks require the web app to be paired with a mobile app to log in. But you can still do a lot. Google's websites generate millions of random encrypted programs per second that run inside a little virtual machine implemented in Javascript, which force attackers to use a browser and then look for signs of browser automation. I don't know how well it works these days, but they still use it, and back when I introduced it (20% time project) it worked very well because spammers had never seen anything like it. They didn't know how to beat it and mostly just went off to harass competitors instead.
  - mike_hearn 1y ago
    I've worked on such systems. Love it or hate it, remote attestation slaughters abuse. It is just much harder to scale up fraud schemes to profitable levels if you can't easily automate anything. That's why it exists and why banks use it.
    - ulrikrasmussen 1y ago
      Wouldn't device-bound keys for a set of trusted issuing secure elements (e.g. Yubikeys) work just as well but without locking down the whole goddamn software stack?
      - mike_hearn 1y ago
        RA schemes don't lock down the whole software stack, just the parts that are needed to allow the server to reason about the behavior of the client. You can still install whatever apps you want, and those apps can do a lot of customization e.g. replace the homescreen, as indeed Android allows today. You need to attest at least the kernel, firmware, graphics/input drivers, window management system etc because otherwise actions you think are being taken by the user might be issued by malware. You have to know that the app's onPayClicked() event handler is running because the human owner genuinely clicked it (or an app they authorized to automate for them like an a11y app). To get that assurance requires the OS to enforce app communication and isolation via secure boundaries.
        ulrikrasmussen 1y ago
        That's waay too much locking down, and while it gives me some control, it does not give me real control. I cannot remove or modify software in the software stack whose behavior I disagree with (e.g. all of Play Services). I can't replace the OS with a more privacy and security focused OS like GrapheneOS. Imagine if this was done for desktop computers before we had smartphones. That's just crazy. Relying on hardware-bound keys is fine, but then the scope of the hardware and software stack that needs to be locked down should be severely limited to dedicated, external hardware tokens. Having to lock down the whole OS and service stack is just bad design, plain and simple, since it prioritizes control over freedom.
- IshKebab 1y ago
  > This is definitely a feature companies and organizations like banks would request if it wasn't available. Really? Because they've been fine without this feature on desktop for literally decades.
- cyphar 1y ago
  Unfortunately, this kind of thinking leads to insane situations such as the South Korean banking cartel which requires users to install several pieces of "security software"[1] which make your computer more vulnerable to security issues[2] and almost certainly doesn't protect anyone from actual fraud -- classic security theatre. There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. [1]: https://palant.info/2023/01/02/south-koreas-online-security-dead-end/ https://palant.info/2023/01/02/south-koreas-online-security-... [2]: https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-mandatory-financial-security-software-becomes-a-backdoor-and-a-target/ https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-ma...
  - cyphar 1y ago
    > There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. That is to say, banks are not the only entities in existence. If they really need such high security to avoid scams and losing such large sums of money they should just issue bank customers with a locked down device that can only be used for banking (maybe banks can collaborate on a standard for it so you can have one device for multiple banks). To be clear, I would still probably be strongly against such a proposal but at least we would be talking about a somewhat understandable approach.
wkat4242 1y ago
On the other hand, it's not really up to the bank. It's my money, not theirs. I really wish I wouldn't need to have my money managed by some corporate drones in suits but it's really hard these days to do without a bank account. This is why I was really into crypto at the beginning; it envisioned giving us control abck over what's ours. But all the KYC crap and the wishes of the speculators for more oversight basically made crypto the same nasty deal as the public banking sector.
blueg3 1y ago
It is desired enough that plenty of developers license third party libraries that roll their own device attestation, instead of or in addition to Play Integrity.

ulrikrasmussen 1y ago

What's absurd though is that they have never demanded it for browsers. I think there is a much higher risk of someone being tricked into downloading a compromised browser with a backdoor than someone being tricked into downloading a modified version of their particular banking app. It gives the attacker the same level of control though.

mike_hearn 1y ago
Banks have never accepted browsers. They don't need to because they can require the web app be paired with a mobile app or SMS code to log in. Before they used mobile apps they issued smartcard readers (at least they did everywhere I lived). The smartcard readers were also used to digitally sign transactions. In other words, there aren't many banks that let you take sensitive actions with just a browser and that's been true since the start of online banking. These days they also apply differential risk analysis based on the device used to submit a transaction and do things to push people towards mobile. For instance in Switzerland there's now a whole standard for encoding invoices in QR codes. To pay those you must use the mobile apps. Edit: people are getting hung up on the "never accepted browsers" part. It means they only use the browser for unimportant interactions. For important stuff like login or tx auth, they expect the use of separate hardware that's more controlled like a SIM card/mobile radio, smartcard or smartphone app. Yes some banks are more lax than others but in large parts of the world this was always true since the start of online banking.
- ulrikrasmussen 1y ago
  Thats ... false. Every bank I have used in Denmark allows me to log in and do all operations without an app. They require authentication and authorization using the national digital identity (MitID) which comes as an app, but also as a TOTP token and a FIDO (or similar) chip. No apps needed. I guess the smartcard reader is equivalent. But my point is that locking down the OS of the phone is sufficient to establish client trust but not necessary. You should always be allowed to run the app without strong Play Integrity verification but then just be required to scan your hardware token with NFC in every authentication and authorization flow.

terminalshort 1y ago

Of course they do, and of course they would. Banks are in a crazy legal position where they are financially liable for user stupidity. If my bank account gets breached, it doesn't matter that I didn't take any reasonable security measures, the bank will still have to refund me. If the bank could say "you didn't follow our recommended security practices to use a PW manager and MFA or passkeys, so it's a FAFO situation for you," then they wouldn't be pushing for this stuff. But they can't do that because the government doesn't allow them to. There is even government regulator pressure now for financial services to be liable for cases where the user legitimately authorizes a transaction to a party that turns out to be a scammer. Of course the banks want to watch your every move and control your devices. They would be stupid not to given the incentives.

palata 1y ago
If they want to do it properly, they can use the Android hardware attestation: https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu...
blizdiddy 1y ago
In what country do you live? In America, users are liable for the banks stupidity. If they don’t verify credentials and give away all of my money, I do NOT get it refunded, they are NOT responsible, and I am the victim of “identity theft.”
- deleted 1y ago
  [deleted]
- terminalshort 1y ago
  I live in America. I have got back every single cent I have lost due to fraudulent charges on my account. Furthermore, I was refunded instantly by the bank pending investigation.
  - cromka 1y ago
    Are you mixing up fraudulent credit card charges? Because that's a whole lot other story. I can't even imagine you would be able to get any fraudulent debit card charges back from the bank.

RobotToaster 1y ago

Because it allows them to outsource "security", for "free".