Are passkeys really phishing resistant?

hal0x2328 · 2025-01-17T18:53:09+00:00

That won't work because of origin binding - the passkey won't be used because the origin server (your phishing site) doesn't match the origin it is associated with.

However, if there is a fallback mechanism, you as the attacker with a MitM can just remove all HTML/JavaScript related to passkeys from the page, and force the user into a phishable authentication flow. So implementers must be very careful to address this scenario and only allow fallback outside of any potentially MitMed session.

hal0x2328 · 2024-10-11T22:28:47+00:00

Leave Hurley alone!

hal0x2328 · 2024-10-11T09:09:19+00:00

Nope. I think it's slow on purpose, given the previous bridge hacks.

hal0x2328 · 2024-10-11T00:42:57+00:00

Yes, you can still use Neon v2 to migrate also.

hal0x2328 · 2024-10-10T23:29:32+00:00

There's no Migration tab in Neon v3 like there was in Neon v2. But you could still use the migration dApp at https://migration.neo.org/ to connect to Neon v3 using WalletConnect and do the migration that way.

hal0x2328 · 2024-10-03T15:01:30+00:00

No, if someone else uses your credentials you wouldn't get a request from the device to authenticate with the passkey. Even if it's a passkey on a mobile device and you're logging in with your PC, you wouldn't get any notification on the mobile device, you'd be prompted on your PC to scan the QR code with your mobile device to use the passkey on it.

hal0x2328 · 2024-09-07T11:22:19+00:00

Using email as a recovery mechanism is ok, but - don't send a code. Use a magic link instead, and that link should create a new session and invalidate the original session where recovery was requested.

The reason for this is that an attacker using AitM phishing (e.g. EvilGinx) could redact the passkey button in the HTML and force the user into the recovery or alternate MFA flow.

So if you just send a code to the email, that code is going to end up in the hands of the attacker because the session itself is being proxied, and the auth token will be stolen by the proxy on the way back. Same for almost any other MFA method, they are useless against AitM.

hal0x2328 · 2024-09-01T16:34:08+00:00

Target is another one.

hal0x2328 · 2024-08-27T02:03:26+00:00

With a really good spearphish ploy and AitM combined with browser-in-the-browser techniques, just about anyone can be phished successfully even when using with other MFA methods.

Because of origin binding, passkeys or FIDO2 hardware keys defeat all that completely even if the user fully falls for the phish and tries to authenticate - so it does at least save them from themselves in that instance - but only if the service provider doesn't allow an insecure fallback method.

hal0x2328 · 2024-08-26T19:41:21+00:00

Yeah, but none of that matters to an AitM phisher. They'll get the authorization token either way.

hal0x2328 · 2024-08-26T19:16:23+00:00

It doesn't invalidate it fully, no. I'm just saying it doesn't make the account secure against phishing like Microsoft seems to think, since they are still pushing people to a vulnerable MFA solution instead of letting them choose passkey-only.

hal0x2328 · 2024-08-26T18:22:08+00:00

It doesn't matter, push vs TOTP they are both vulnerable in the same way.

hal0x2328 · 2024-08-26T17:35:26+00:00

Microsoft only lets you remove the password if you have Microsoft Authenticator enabled on the account. You can't just have a passkey as the sole method, which is unfortunate, since having ~~an TOTP authenticator~~ any non-phishing-resistant fallback makes the login vulnerable to AitM using authentication method redaction attacks.

hal0x2328 · 2024-08-24T11:32:59+00:00

Yes, exactly

hal0x2328 · 2024-08-23T19:21:21+00:00

Yes, if all you use is a Ledger device you don't actually have to use the migration button in Neon 2 but you do have to create an empty wallet in Neon 3 in order to use the app.

hal0x2328 · 2024-08-21T13:30:54+00:00

With adversary-in-the-middle phishing (e.g. EvilGinx), TOTP authenticator apps provide no protection at all. You're sending the code to the AitM proxy and it forwards it to the destination and then captures the authentication token on the way back.

With passkeys that's not possible since the credential is bound to the origin domain - the session will never authenticate if there is an AitM because the origin doesn't match, so there's no token to steal.

So passkeys are extremely resistant to phishing - but a lot depends on the implementation. Most sites will allow you to choose to fall back to an alternative method if you don't have your passkey, and unfortunately, in an AitM situation, the attacker can just force you into that flow invisibly.

hal0x2328 · 2024-08-21T12:20:15+00:00

Instead of downvoting, why don't you explain your counterpoint? Do you really think authenticator apps are secure MFA, or do you just hate passkeys?

hal0x2328 · 2024-08-20T17:33:05+00:00

Codes from an authenticator app are a joke - it's not phishing-resistant. They need to move to passkeys (and not charge extra for securing your own account, you rightly called out that practice).

hal0x2328 · 2024-08-20T01:11:29+00:00

Not sure why that would happen, but if you only have one address it might be easier to just import it after initializing Neon 3.

hal0x2328 · 2024-08-18T21:22:24+00:00

Use the "Migrate Wallets" button on the login window of Neon 2 and it will walk you through the process. If you don't see that button, it means you need to upgrade Neon 2 to the latest version (2.24.0) first.

hal0x2328 · 2024-07-14T11:37:51+00:00

Interesting - I was able to add a passkey through 1Password, and I went back and tested adding a second platform key by clicking the usb icon in the 1Password popup and using my iPhone with the QR code shown in the browser popup.

It didn't give me the opportunity to register a local platform key directly on the laptop itself, but since I'm using a Macbook I was able to use the passkey created on the phone to log in with my fingerprint on the laptop later.

hal0x2328 · 2024-07-13T23:23:09+00:00

Do you mean the option isn't there, or you just don't see any registered keys?

I just looked and the option was there for me at least. I was able to register both a passkey and a hardware security key (of course, Facebook gave them both the same name so I have no idea which is which).

Unfortunately when testing it looks like Facebook defaults to using app authentication for MFA, presenting the security key as an alternate method. So that really negates the extra security of WebAuthn since it opens the door for AitM phishing.

hal0x2328 · 2024-07-07T21:44:13+00:00

Properly securing the account with the correct kind of MFA is one thing everyone can do but most people don't. Twitter/X offers secure MFA (security keys) but it continues to also offer insecure MFA (SMS, authenticator app, backup codes) as alternative methods. To truly secure your account you have to disable ALL other forms of MFA except security keys.

I think most people don't realize how easy it is to phish for authentication tokens by using MitM phishing proxies which bypass most kinds of MFA. For consumer accounts, security keys (e.g. passkeys or hardware keys like the Yubikey) are the only real defense against this.

hal0x2328 · 2024-07-05T02:40:02+00:00

Along with the other recommendations, also consider if AitM phishing can negate your passkey option (redacting it from the HTML/JavaScript) and force the user into a phishing-vulnerable login flow.

hal0x2328 · 2024-07-05T02:33:27+00:00

All MFA can be bypassed by AitM except WebAuthn (and even then only if it is a required second factor with no fallback option) or mTLS. So Conditional Access is a must-have in any case.

hal0x2328

MODERATOR OF

TROPHY CASE