| ▲ | tadfisher 2 hours ago | ||||||||||||||||
> 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. | |||||||||||||||||
| |||||||||||||||||