261–270 of 816 posts
If anyone would be interested I could write it up? I was surprised what a nice user flow it is and how easy it was to achieve.
The attack pattern is: 1) User goes to BAD website and signs up. 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.” 3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email. 4) GOOD sends a one-time login code email to the user’s email address. 5) The user is very likely to trust…
But granny can't go to a bank because they closed down most of their offices. Since 99% of what you need a bank for can be done using their app it no longer made financial sense to have a physical presence in most smaller towns and villages.
Lots of elderly were complaining about this when it happened because they were too lazy to learn how to use the bank apps. Hell, they already started complaining when you could no longer withdraw money at the desk even before they closed down the offices. Apparently even learning to use something as simple as an ATM was too much effort for them.
I've conscientiously ignored every attempt by every service in the past decade to bully me into giving up a phone number for 2FA. Authenicator apps and passkeys, fine. But never over SMS.
Earlier quoted context omitted.
Would it be a viable and simple solution to only enter 6-digit codes into the specific website that requested it? Isn't this the same thing as BAD asking, let us know the code i.e. password that GOOD gave you? Why would one be inclined to give BAD (i.e. someone else) this info?
This came to my mind too. But by using a password manager it will be able to differentiate between the GOOD and BAD site. So I think the point is valid only if the user is not using a password manager.
Earlier quoted context omitted.
I agree, but unfortunately the spec authors are already going out and dangling possible bans in front of projects who implement Passkeys in more user-friendly ways: https://github.com/keepassxreboot/keepassxc/issues/10407 > To be very honest here, you risk having KeePassXC blocked by relying parties But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the…
Reducing passkeys to the security level of passwords is not just "making something user friendly". It's undoing all of the hardware everyone else in the ecosystem is putting into to making a more secure way for authentication to be done.
Earlier quoted context omitted.
The problems of Passkeys are more nuanced than just losing access when a device is lost (which actually doesn't need to happen depending on your setup). The biggest problem are attestations, which let services block users who use tools that give them more freedom. Passkeys, or more generally challenge-response protocols, could easily have been an amazing replacement for passwords and a win-win for everyone. Unfortuna…
Do you have some examples where people actually require attestation in 3rd party facing systems? Or is this purely "But in theory..." and you've dismissed all the very real problems with the alternatives because you're scared of a theoretical problem ? I always reject attestation requests and I don't recall ever having been refused, so if this was a real problem it seems like I ought to have noticed by now.
We have already been through this with many services suddenly demanding that you give them your phone number "for security".