If you grok Apple, I wrote up a tutorial on very basic PassKey implementation (for iOS apps), here: https://littlegreenviper.com/series/passkeys/

Very nice, thanks! By the way, the preferred capitalization is "passkeys", like "passwords". It's not supposed to be capitalized like a proper noun.

I prefer all lowercase. Not sure where I got the CamelCase version, but it may have been from the Apple or FIDO docs.

I’d like to write a follow-up that covers authentication apps/devices, but I need to do some research, and find free versions.

Counterpoint: don't use passkeys, they're a confused mess and add limitations while not giving any benefits over a good long password in a password manager.

They prevent you from being one of these, and copy pasting the password from password manager into the wrong input field. Something that still happens often with many websites not properly auto-filling from password managers.

> They just rely on you being busy, or out, or tired, and just not checking closely enough

If you are "copy-pasting" you are not using your password manager correctly.

Password managers rarely are able to autofill 100% of the time. Autofill breaking is not a very strong indicator of a phishing attempt, people are used to manually filling the password in sometimes for totally legit sites.

I'm used to 1Password not being able to autofill, yes. But I'm not used to no account showing up at all when I open the UI panel. If that happens, I immediately know I'm on the wrong domain.

You know you're on a new domain. However, sites change their auth flow much more often than any patitcular person getting phished. So, if you're using a larger variety of site, you'll likely encounter the benign situation at least a dozen times before you ever encounter your first actual phishing attempt, at which point you'll have gotten used to it.

For example, Twitter relatively recently changed from authenticating on twitter.com to redirecting you to x.com to authenticate (interestingly, Firefox somehow still knows to auto fill my password, but not my username on the first page).

It's far too common for websites to redirect to some separate domain for sign in which isn't the one originally used to sign up, getting users used to "oh gotta copy the password again" as a totally normal thing that happens

I keep hearing people say this, but I haven’t found it so: in over a decade, I think I’ve only seen it twice. Looking through my password safe which I’ve been using for about twelve years with over 200 entries, I have nine cases with multiple origin URLs, and most of them I’m confident I added manually because I didn’t like the URL it recorded automatically (e.g. it’s on a different domain from the main site, and the specific path is for signup only, but I want to be able to “visit site” from the password safe and get to the login page or at least the homepage). I think that only two of them have ever actually used more than one origin: a banking one that switched from .com.au to .com at some point as part of a broader global restructuring (and they made a fair bit of noise about it, and you had to partly make a new account anyway), and a Microsoft account. There’s a third that I can’t check (COVID-related, gone) that might have been, but I don’t think so.

Now on a few occasions I’ve had to copy passwords in order to access things in a different browser, and I think I did encounter one site some years ago where autofill didn’t work, but I really do find autofill almost completely reliable.

While you kind of addressed it below, I'm not sure you know how bad state government websites can be here in the US.

In Texas I've had more than one site where create the login on one site, but use that same login on multiple different domains that are NOT directly connected to a singular authentication site (id.me in the example).

go to tax.gov

You'll identify on id.me

People have just gotten used to this sort of thing unfortunately

That’s a different issue, though related.

For password safe users, auth being handled entirely on a different origin is completely fine, so long as the credentials are bound to (only used on, including initial registration) that origin. The hazard is only when login occurs via multiple domains—which in this case would mean if you had <input> elements on both tax.gov and id.me taking the same username and password, which I don’t believe you do. Your password safe won’t care if you started at https://tax.gov, the origin you created the credentials on was https://id.me, and so that’s the origin it will autofill for.

That should only happen once, you should store the password for the second domain too.

As I said in my comment above, sometimes it’s necessary as websites break the auto fill, or mobile apps don’t offer the password manager sheet.

This very story illustrates how people will override their password manager's builtin protections when panic ensues.

If only everyone did everything perfectly all the time, we wouldn't have any issues!

This whole story is about us getting zapped because we relied on a good long password in a password manager!

So what happened exactly? Did Kurt enter his twitter password manually after clicking on that phishing link? Did he not get his sus detector going off after the password manager didn't suggest the password?

Unfortunately, this does not work. I see no end of banks, financial institutions, let alone random companies, who keep their authentication, for some reason, on different domain than main company, and sometimes they would have initial registration (which gets recorded in password manager) on one domain, and consequent logins on another, and sometimes it depends on how you arrived at the site, or which integration are you planning to use, etc. I wish there were a rule "one company - one auth domain" but it's just not true.

Example: Citi bank has citibankonline.com, citi.com, citidirect.com, citientertainment.com, etc. Would you be suspicious of a link to citibankdirect.com? Would you check the certificate for each link going there, and trace it down, or just assume Citi is up to their shenanigans again and paste the password manually? It's jungle out there.

> Would you check the certificate for each link going there, and trace it down, or just assume Citi is up to their shenanigans again and paste the password manually?

What do you get from checking a certificate? Oh yeah, must really be citibank because they have a shitton of SANs? I'd guess most banks do have a cert with an organization name, but organization names can be misleading, and some banks might use LetsEncrypt?

Org certs have pretty much fallen out of favor these days.

That happened to me as well, I put it down to "fucking password manager, it's broken again".

For example, BitWarden has spent the past month refusing to auto fill fields for me. Bugs are really not uncommon at all, I'd think my password manager is broken before I thought I'm getting phished (which is exactly how they get you).

Yeah i could totally see how someone in a bind working off of phone could get p0wned like that

For me it wasn't even a phone, it was on the desktop, I'm just so used to everything being buggy that it didn't trigger any alarms for me.

Luckily the only things I don't use passkeys or hardware keys for are things I don't care about, so I can't even remember what was phished. It goes to show, though, that that's what saved me, not the password manager, not my strong password, nothing.

The ability to autofill by domain is a critical function of a password manager. It sounds like this tool is performing a lot worse than your browser's built-in password manager -- maybe that's enough to encourage a switch?

Yes, that's exactly what happened. The nature of panic is that it overrides people's better judgment.

Yes, PKC authentication is good, but the way passkeys have been implemented is not great. Way too much trust built into the protocol; way too much power granted to relying parties; much harder for users to form a correct mental model.

I mean the problem with Passkeys is that they're unsuitable as the sole login method for an account. They're great as a stronger "keep me logged in" for certain devices but they're something you have and they don't survive a fire. And so every service that offers Passkeys also has to offer a reset mechanism and a backup auth flow if you're on a device without the Passkey.

Any site that wants to phish you will either just not show the passkey flow and hope you forget or show it and make it look like it failed and pop up a helpful message about being able to register a new Passkey once you're logged in. And Passkeys are so finicky in browsers that I'd buy it.

You can do Passkeys entirely in software with KeePassXC.

Let me preface this by saying I use passkeys with KeepassXC.

According to WebAuthn, this is not true. Such passkeys are considered "synced passkeys" which are distinct from "device bound" passkeys, which are supposed to be stored in an HSM. WebAuthn allows for an RP to "require" (scare quotes) that the passkey be device bound. Furthermore, the RP can "require" that a specific key store be used. Microsoft enterprise for example requires use of Microsoft Authenticator.

You might ask, how is this enforced? For example, can't KeepassXC simply report that it is a hardware device, or that it is Microsoft Authenticator?

The answer is, there are no mechanisms to enforce this. Yes, KeepassXC can do this. So while you are actually correct that it's possible, the protocol itself pretends that it isn't, which is just one of the many issues with passkeys.

Hmm, I thought there was some form of attestation involved? Is it really as simple as spoofing the device ID? Do you have any more info/links on the spoofing?

What’s the solution for preventing this kind of phishing attack?

TLS client certificates. Unfortunately, the browser UI for them ranges from godawful to removed-because-nobody-used-them.

So the solution for this isn’t actually usable?

>I realized that anyone can get phished

A few years ago, I managed to get our InfoSec head phished (as a test). No one is safe :)