5 ms·
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 ba
by Tharre 8mo 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.
- Retr0id 8mo agoWe know how to do hardware-bound phishing-resistant credentials now, it is a solved problem.
- Tharre 8mo agoI'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 8mo agoSMS 2FA is neither hardware-bound nor phishing resistant, I'm referring to hardware-bound phishing-resistant 2FA methods like passkeys.
- Tharre 8mo agoRead my previous comment again. Passkeys are nice, but they don't solve the problem that's being discussed here.
- Retr0id 8mo agoI'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.
- tadfisher 8mo agoCorrection: 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.
- deleted 8mo ago[deleted]
- mwwaters 8mo agoIf 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 8mo agoI 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 https://www.bankofamerica.com/.well-known/assetlinks.json
- RandomGerm4n 8mo agoThe 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.
- jrm4 8mo agoThis should be voted higher, it quite literally is this simple.
- Tharre 8mo agoThis 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.
- singpolyma3 8mo 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. 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 8mo ago> 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 8mo agoI 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.
- iamnothere 8mo agoAnd here we have it, the endgame of safety fascism. Do you have a loicense for that compiler?
- simonask 8mo agoDo you call building codes and bridge engineering standards "safety fascism" as well? The stakes aren't any lower for us.
- iamnothere 8mo ago