| ▲ | Tharre 5 hours ago |
| There simply isn't a known solution to this problem. If you give users the ability to install unverified apps, then bad actors can trick them into installing bad ones that steal their auth codes and whatnot. If you want to disallow certain apps then you have to make decisions about what apps (stores) are "blessed" and what criteria are used to make those distinctions, necessarily restricting what users can do with their own devices. You can go a softer route of requiring some complicated mechanism of "unlocking" your phone before you can install unverified apps - but by definition that mechanism needs to be more complicated then even a guided (by a scammer) normal non-technical user can manage. So you've essentially made it impossible for normies to install non-playstore apps and thus also made all other app stores irrelevant for the most part. The scamming issue is real, but the proposed solutions seem worse then the disease, at least to me. |
|
| ▲ | singpolyma3 4 hours ago | parent | next [-] |
| > There simply isn't a known solution to this problem. If you give users the ability to install unverified apps, then bad actors can trick them into installing bad ones that steal their auth codes and whatnot. This is also true if they can only install verified apps, because no company on earth has the resources to have an actually functional verification process and stuff gets through every day. |
| |
| ▲ | iamnothere 3 hours ago | parent [-] | | > This is also true if they can only install verified apps, because no company on earth has the resources to have an actually functional verification process and stuff gets through every day. This is true, but if this goes through, I imagine that the next step for safety fascists will be to require developer licensing and insurance like general contractors have. And after that, expensive audits, etc, until independent developers are shut out completely. | | |
| ▲ | simonask 21 minutes ago | parent [-] | | I don’t know if I agree, but we are very much in a world where that would make sense. Why do drug companies deserve justice for developing and pushing heroin-analogues, but not tech companies? Our work has real consequences. |
|
|
|
| ▲ | RandomGerm4n 4 hours ago | parent | prev | next [-] |
| The solution would be a "noob mode" that disables sideloading and other security-critical features, which can be chosen when the device is first turned on and requires a factory reset to deactivate. People who still choose expert mode even though they are beginners would then only have themselves to blame. |
| |
| ▲ | Tharre an hour ago | parent | next [-] | | This is just a variant of the "complicated unlocking mechanism" I was talking about. It still screws over everything not coming from the play store because the installation process for them essentially becomes a huge hassel, that even involves factory resetting their device, that most people won't want to deal with. | |
| ▲ | jrm4 3 hours ago | parent | prev [-] | | This should be voted higher, it quite literally is this simple. |
|
|
| ▲ | Retr0id 5 hours ago | parent | prev [-] |
| We know how to do hardware-bound phishing-resistant credentials now, it is a solved problem. |
| |
| ▲ | Tharre 5 hours ago | parent [-] | | I'm going to assume you're referring to auth codes, especially the ones sent via SMS? In which case yes, banks should definitely stop using those but that alone doesn't solve the overarching issue. The next step is simply that the scammer modifies the official bank app, adds a backdoor to it, and convinces the victim to install that app and login with it. No hardware-bound credentials are going to help you with that, the only fix is attestation, which brings you back to the aformentioned issue of blessed apps. | | |
| ▲ | Retr0id 4 hours ago | parent [-] | | SMS 2FA is neither hardware-bound nor phishing resistant, I'm referring to hardware-bound phishing-resistant 2FA methods like passkeys. | | |
| ▲ | Tharre 4 hours ago | parent [-] | | Read my previous comment again. Passkeys are nice, but they don't solve the problem that's being discussed here. | | |
| ▲ | Retr0id 4 hours ago | parent [-] | | I'm not sure if you understand what makes passkeys phishing-resistant? The backdoored version of the app would need to have a different app ID, since the attacker does not have the legitimate publisher's signing keys. So the OS shouldn't let it access the legitimate app's credentials. | | |
| ▲ | Tharre 3 hours ago | parent | next [-] | | I understand how passkeys work. You don't need the legitimate app's credentials, we're talking about phishing attacks, you're trying to bring the victim to giving you access/control to their account without them realizing that that's what is happening. A simple scenario adapted from the one given in the android blog post: the attacker calls the victim and convinces them that their banking account is compromised, and they need to act now to secure it. The scammer tells the victim, that their account got compromised because they're using and outdated version of the banking app that's no longer suppported. He then walks them through "updating" their app, effectively going through the "new device" workflow - except the new device is the same as the old one, just with the backdoored app. You can prevent this with attestation of course, essentially giving the bank's backend the ability to verify that the credentials are actually tied to their app, and not some backdoored version. But now you have a "blessed" key that's in the hands of Google or Apple or whomever, and everyone who wants to run other operating systems or even just patched versions of official apps is out of luck. | | |
| ▲ | tadfisher 2 hours ago | parent | next [-] | | > He then walks them through "updating" their app, effectively going through the "new device" workflow - except the new device is the same as the old one, just with the backdoored app. This is where the scheme breaks down: the new passkey credential can never be associated with the legitimate RP. The attacker will not be able to use the credential to sign in to the legitimate app/site and steal money. The attacker controls the fake/backdoored app, but they do not control the signing key which is ultimately used to associate app <-> domain <-> passkey, and they do not control the system credentials service which checks this association. You don't even need attestation to prevent this scenario. | | |
| ▲ | Tharre an hour ago | parent [-] | | > do not control the signing key which is ultimately used to associate app <-> domain <-> passkey, and they do not control the system credentials service which checks this association. You're assuming the attacker must go through the credential manager and the backing hardware, but that is only the case with attestation. Without it, the attacker can simply generate their own passkey in software, because the backend on the banks side would have no way of telling where the passkey came from. | | |
| ▲ | tadfisher an hour ago | parent [-] | | How did the service authenticate the user in order to create the new credential within the attacker-controlled app? | | |
| ▲ | Tharre 30 minutes ago | parent [-] | | With banks, typically a combination of your account number, pin and some confirmation code sent via email or SMS. And of course unregistering your previous device. Not sure where you're going with this though? |
|
|
| |
| ▲ | microtonal 2 hours ago | parent | prev [-] | | I understand how passkeys work. You don't need the legitimate app's credentials, we're talking about phishing attacks, you're trying to bring the victim to giving you access/control to their account without them realizing that that's what is happening. That doesn't work, because the scammer's app will be signed with a different key, so the relying party ID is different and the secure element (or whatever hardware backing you use), refuses to do the challenge-response. |
| |
| ▲ | tadfisher 3 hours ago | parent | prev [-] | | Correction: nothing prevents the attacker from using the app's legit package ID other than requiring the uninstall of the existing app. The spoofed app can't request passkeys for the legit app because the legit app's domain is associated with the legit app's signing key fingerprint via .well-known/assetlinks.json, and the CredentialManager service checks that association. | | |
| ▲ | mwwaters 2 hours ago | parent | next [-] | | If the side loaded app does not have permission to use the passkeys and cannot somehow get the user to approve passkey access of the new app, that would be a good alternative to still allow custom apps. | | |
| ▲ | tadfisher 2 hours ago | parent [-] | | I don't think you understand. This exists _today_, regardless of how you install apps, because attackers can't spoof app signatures. If I don't have Bank of America's private signing key, I cannot make an app that requests passkeys for bankofamerica.com, because bankofamerica.com publishes a file [0] that says "only apps signed with this key fingerprint are allowed to request passkeys for bankofamerica.com" and Android's credential service checks that file. No need for locking down the app ecosystem, no need to verify developers. Just don't use phishable credentials and you are not vulnerable to malware trying to phish credentials. 0: https://www.bankofamerica.com/.well-known/assetlinks.json |
| |
| ▲ | 3 hours ago | parent | prev [-] | | [deleted] |
|
|
|
|
|
|
