We replaced passwords with something worse

I set up a passkey for github at some point, and apparently saved it in Chrome. When I try to "use passkey for auth" with github, I get a popup from Chrome asking me to enter my google password manager's pin. I don't know what that pin is. I have no way of resetting that pin - there's nothing about the pin in my google profile, password manager page, security settings, etc.

The problem is that I can physically show up at my local bank branch or at my job's IT helpdesk to get my account back, but I can't show up at the Googleplex or at Facebook's or Xitter's HQ and do the same. Device bound passkeys are very error prone for the latter scenario, since users will fail to account for that case.

I wish there was a stronger differentiation between syncable and device-bound passkeys. It seems like we're now using the same word for two approaches which are very different when it comes to security and user-friendliness.

And yes, giving granny unsyncable passkeys is a really bad idea, for so many reasons.

No, at least not on its own. Let's not repeat the mistakes.

Password managers are the way to go and ONLY FOR RARE EXCEPTIONS we should use dedicated MFA, such as for email-accounts and financial stuff. And the MFA should ask you to set up at least 3 factors and ask you to use 2 or more. And if it doesn't support more or less all factors like printed codes, OS-independent authenticator apps and hardware keys like yubikey, then it should not be used.

- open website

- if not already logged in, log in to 1Password

- autofill password

- autofill TOTP

Now:

- open website

- if logged in to 1Password the Use Passkey usually shows up

- if not:

  - log in to 1Password 

  - choose use passkey

  - this almost always does nothing

  - choose “use other method”

  - choose “password”

  - autofill that

  - now there is another dialog to choose the 2fa method, choose Authenticator 

  - autofill that

"Click a link in the email" is really bad because it's very difficult to know the mail and the link in it are legitimate. Trusting links in emails opens to door to phishing attacks.

Visiting the bank is fine. But who do you visit to recover your Gmail password?

For a lot of people, dealing with (now mostly digital) bureaucracies is a major stress in life. The biggest one, for some.

Its not just about invonvenience. Its sometimes about losing access to some, and just not having it for a while.

In terms of practical effect, a performance metric for a login system could be "% of users that have access at a given point." There can be a real tradeoff, irl, between legitimate access and security.

On the vendor side.. the one time passwords fallback has become a primary login method for some. Especially government websites.

Customer support is costly and limited in capacity. We are just worse at this than we used to be.

Digital identity is turning out to be a generational problem.

I am waiting for the era when using passkeys is not depending from some big tech company.

Point is, the damage will be likely local to a single or a handful of accounts.

If all the accounts are protected by two factor on my phone and I lose it or it bricks, then I'm done. It will be a total mess with no paths to recover, except restarting literally everything from scratch.

I have Google Auth app on my phone and every few months I consider using it, but then reconsider and stay with passwords.

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 still don’t really understand what recovery looks like for a lost passkey… especially if I lose all of them. Not everything has a physical location where an identity can be validated, like a bank. Even my primary bank isn’t local. I’d have to drive about 6 hours to get to a branch office.

Btw this predates passkeys which should perhaps be the way to go from now on.

> Website: is this Jimbob' phone

> Hardware: yes

And

> Website: I'll give you a dollar if you tell me something juicy about this user

> Hardware: Give this token to Microsoft and ask them

> Microsoft: Jimbob is most likely to click ads involving fancy cheeses, is sympathetic to LGBTQ causes, and attended a protest last week

With passwords and TOTP codes, I am in control of what information is exchanged. Passkeys create a channel that I can't control and which will be used against me.

(I chose Microsoft here because in a few months they're using the windows 10->11 transition to force people into hardware that locks the user out of this conversation, though surely others will also be using passkeys for similarly shady things).

1) User goes to BAD website.

2) BAD website says “Please enter your email and password”.

3) BAD’s bots start a “Log in with email and password” on the GOOD website using the user’s email and password.

4) BAD now has full access to the user’s GOOD account.

There are lots of attack patterns. That is one. I am not certain I believe it is very likely, because (a) I think "sign-in partner" is obvious bullshit, and (b) I don't understand why I would never enter a code into the wrong website. I believe it can be possible, but...

> Passkeys is the way to go. ... I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money.

... I do not agree your story is justification for passkeys, or for letting banks trust passkeys for authentication purposes. I'd rather she not lose access to banking services in the first place: I don't think banks should be allowed to do that, and I do not think it should be possible for someone to "steal all her money" so quickly -- Right now you should have at least several days to fix such a thing with no serious inconvenience beyond a few hours on the phone. I think it is important to keep that, and for banking consumers to demand that from their bank.

A "granny" friend of mine got beekeeper'd last year[1] and her bank reversed/cancelled the transfers when she was able to call the next say and I (local techdude) helped backup/restore her laptop. I do not think passkeys would helped and perhaps made things much worse.

But I don't just disagree with the idea that passkeys are useful, or even the premise of a decision here between losing all their money and choosing passkeys, I also disagree with your priors: Having to visit a bank branch is a huge inconvenience for me because I have to fly to my nearest. I don't know how many people around here keep the kind of cash they would need on-hand if they suddenly lost access to banking services and needed to fly to recover them.

I think passkeys are largely security-theatre and should not be adopted simply if only so it will be harder for banks to convince people that someone should be able to steal all their money/access with the passkey. This is just nonsense.

[1]: seriously: fake antivirus software invoice and everything, and her and her kid who is my age just saw the movie in theatres in like the previous week. bananas.

No, please, not as long as attestation is in the spec. I firmly believe that passkeys are intended to facilitate vendor lock-in and reduce the autonomy of end users.

Frankly, I do not trust any passkey implementation as much as I trust a GPG-encrypted text file.

A bad practice is the shorten the code validity to a few minutes. This cannot really be justified and puts users under stress, which lessens security.

The discussion around passkeys, who is and isn't allowed to store them, almost killed them for me personally. I use them for very, very few services and I don't want to extend it.

My problem with passkeys is that there is no hardware attestation like there is with Yubikeys and similar.

This means for security conscious applications you have no way of knowing if the passkey you are dealing with is from an emulator or the real-deal.

Meanwhile with Yubikeys & Co you have that. And it means that, for example people like Microsoft can (and do) offer you the option to protect your cloudy stuff with AAGUID filtering.

And similar if you're doing PIV e.g. as a basis for SSH keys, you can attest the PIV key was generated on the Yubikey.

You can't do any of that with passkeys.

They’re too opaque for my taste and I don’t like them.

This point means the user is not paying attention: 1) User goes to BAD website and signs up. Steps 2-7 wouldn't be possible without 1.

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?

> 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.”

Does that mean that GOOD must be a 3rd party identity provider like Facebook, Apple, Google etc?

And how do you access your password manager when your computer is locked ?

The prompts that show where the login is coming from are useless, too, because mapping from IP addresses to geographical locations is far from perfect. For example, my legit login attempts showed me all over my country map. If I’m in a corporate VPN already, its exit nodes may also be all over the map, and your legitimate login from, say, Germany may present itself as coming from Cyprus, which is shady as fuck.

If I seek to implement 2fa for my own service and have it be not theater and resistant to such phishing attacks, it gets difficult real fast.

Edit: See first reply, this is not a mitigation at all!

1) User goes to BAD website and signs up (with their user and password). BAD website captures the user and password

2) BAD website shows a fake authentication error, and redirects to GOOD website. Users is not very likely to notice.

3) BAD uses user and password to login to GOOD’s website as the user. BAD now has full access to the user’s GOOD account.

OK, with a password manager the user is more likely to notice they are in BAD website. Is that the advantage?

You can enable it on account.microsoft.com > Account Info > Sign-in preferences > Add email > Add Alias and make it primary. Then click Change Sign-in Preferences, and only enable the alias.

Did I click “Yes” to the attack the fifth time, or was the sixth the attack? Or was it just a “hiccup” in the system?

Do I cancel the migration job and start from the beginning or roll the dice?

It’s beyond idiotic asking a Yes/No question with zero context, but that was the default MFA setup for a few hundred million Microsoft 365 and Azure users for years.

“Peck at this button like a trained parrot! Do it! Now you are ‘secure’ according to our third party audit and we are no longer responsible for your inevitable hack!”

- You are in front of the attacker site that looks like a legitimate site where you have an account (you arrived there in any way: Whatsapp link, SMS, email, whatever). Probably the address bar of your browser shows something like microsoft.minecraft-softwareupdate.com or something alike, but the random user can't tell it's fake. The page asks you to login (in order to steal your account).

- You enter the email address to login. They enter your email address in the legitimate site where you actually have an account.

- Legitimate site (for example Microsoft) sends you an email with a six digit code, you read the code, it looks legit (it is legit) and you enter it in the attacker site. They can now login with your account.

With email pasting the number into a random website is the expected flow and there is basically no protection (some phones have basic protections for SMS auth but even this only works if you are signing in on the same device).

* Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again.

* Some people don’t have their email on the device they want to log in on.

Sending codes solves both of these problems (but then has the issues described in the article, and both share all the problems with sending emails)

Magic links are better than codes, but they don't work well for cross-device sign-in. What Nintendo does is pretty great: If I buy something on my switch, it shows me a QR code I take a picture of with my phone and complete the purchase there.

I agree it is "mostly solved" in that there are good examples out there, but this is a long way from the solution being "best practices" that users can expect the website/company to take security seriously.

> a. This is already the case as long as you have an email-based password reset flow

I hard-disagree:

If I get an email saying "Hi you are resetting your password, follow these directions to continue" and I didn't try to reset my password I will ignore that email.

If I have to type in random numbers from my email every few days, I'm probably going to do that on autopilot.

These things are not the same.

> anyone who possesses and is logged into the user's phone or laptop (the usual prerequisites for a possession-based second factor) can also get their password.

I do not know what kind of mickey-mouse devices you are using, but this is just not true on any device in my house.

Accessing the saved-password list on my computer or phone requires an authentication step, even if I am logged-in.

I also require second-authentication for mail and a most other things (like banking, facebook, chats, etc) since I do like to let my friends just "use my phone" to change something on spotify or look up an address in maps.

> Most websites should not be in the business of trying to use knowledge-based authentication on their users, because they can't know whether the secret really came from the user's memory or was instead stored somewhere

They can't know that anyway, and pretending they do puts people at risk of sophisticated attackers (who can recover the passkey) and unsophisticated incompetence on behalf of the website (who just send reset links without checking).

> Websites should instead authenticate only the device, and delegate to the device's own authentication system

I disagree: Websites have no hope of authenticating the device and are foolishly naive to try.

except I'm a user, not a device

>>I<< want to be authenticated, not my specific device that I'm going to switch at some point

Try multi-account containers so no need to log out? (Or Island on Android?)

It's about email as single factor auth, which has become very trendy of late. You just enter your email address, no password, and the email you a code. Access to your email is the only authentication.

It’s about single factor, password logins, using a one-time-token

This is not good for the user.

A better workflow is to send the user a link where they can set their initial password themselves.

If they actually are passwords, yes, my password manager is a better UX than having to fetch my phone, open SMS, wait for the SMS, like good grief it's all so slow.

(In the 2FA form, I'd prefer TOTP over SMS-OTP, but the difference is less there.)

(I do agree with you about backups being essential, but my conclusion was "the idea is fundamentally flawed," rather than "it's one tweak away from greatness.")

Perhaps there ought to be a well-known, "ACME" password-changing API such that a password manager could hypothetically change every password for every service contained in an automated fashion.

What's missing is a standardized format for the export.

1. You go to evil.example.com, which uses this flow.

2. It prompts you to enter your email. You do so, and you receive a code.

3. You enter the code at evil.example.com.

4. But actually what the evil backend did was automated a login attempt to, like, Shopify or some other site that also uses this pattern. You entered their code on evil.example.com. Now the evil backend has authenticated to Shopify or whatever as you.

* Electronic mail (the technology)

* An email message

* An email address

* An email inbox

In this example they mean email address.

bank.com sends you verification email, which you expect from foo.com as part of the sign-up verification process. For some bat shit crazy reason, you ignore that the email came from bank.com and not foo.com and you type in the secret code from the email into the foo.com to complete the sign up process.

And bam! the foo.com got into your bank account.

A complete nonsense but because it works in 0.000000000000001% of the time for some crazy niche cases in the real world, let's talk about it.