Plaid also relies on entering bank passwords on neobank sites and is widely used.

And considering how most banks are set up, we are talking about the user’s only set of credentials. Which have the user’s permissions.

Then there are all these fintech startups saying that they’re secure because they use Plaid to access all your financial life, all to provide you with centralised analytics or supposed financial advice.

Sure it’s probably (one can hope) more secure than every single one of them rolling out their own hacked together equivalent. But still.

Am I missing something?

I’m not sure how it even works with second factors (I’ve never looked).

https://support-my.plaid.com/hc/en-us/articles/9098915502999...

I don't know for sure how they do it, but it must just be a thousand custom forms and browser automations for each bank they support. And have to be updated whenever the bank updates.

IIRC Yodlee and Mint do (did?) about the same thing, for banks without a formal API.

My credit union doesn’t give a flying fuck about Plaid and it’s a constant cat and mouse game that amuses me to watch. My credit union doesn’t have a path to online banking without per-session MFA.

I think banks should be required to provide a user-opt-in OAuth API for read-only access, but not so that companies like Plaid can pilfer your data.

However Plaid has made in-roads at many large institutions, and now supports OAuth, or OAuth-like, access at all (nearly all?) major US financial institutions.

Plaid never liked working against banks, that just made everything worse for everybody involved.

> My credit union doesn’t have a path to online banking without per-session MFA. This obviously kills async products at Plaid, like continuous transaction data, but doesn't block sync products like Auth (account and routing data).

In fact, Plaid made a huge push to increase the amount of MFA encountered on their platform. When banks or credit unions didn't offer MFA, or didn't allow users to enforce MFA on every login, Plaid would attempt to force it through a variety of mechanisms to ensure a bad actor would encounter MFA on Plaid even if the bank would otherwise let them through their actual website.

They can definitely encrypt the credentials, they just also have to make it simple for their backend to decrypt it when they need access to your bank, which defeats a lot of the security there. (It's still better than just storing it in plaintext).

https://support-my.plaid.com/hc/en-us/articles/4410324401047...

> In other cases, when you link a financial institution to an app via Plaid, you provide your login credentials to us. We store those credentials and use them to collect the data to power the services you’ve chosen and, when requested, securely share it with the app you’re using and establish a secure connection that you control. We then help keep your data safe and private with best-in-class encryption protocols.

And for things like Plaid, I think banks are moving towards OAuth-style permissions, where you login to your bank and authorize the connection. Under the hood, Plaid or other app can connect to the bank with limited permissions using API authorization keys. It's a different problem, I think.

In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that.

For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.

So if the website bundles its domain in the challenge, it can make sure that the client signed the challenge for itself, and the client can verify that it signs the challenge for the current domain.

So now, if the service's domain were to change, it would presumably be aware of it and incorporate it in the new challenge, which the client would sign, since it's browsing the correct domain, with the same private key used before.

Is this not how it works?

The Yubikey can act in HMAC challenge mode, though, but that's not the mode used on the web.

What's inside the cheapest authenticators isn't a private key, after all they present a unique random public key for every single enrolment, so that couldn't work if they held a single private key. Instead it's a symmetric key (e.g. AES-256). Lets see how that's done:

When you enrol at a site, the authenticator mints a completely random new public/private key pair (with Elliptic curve crypto it's really easy to pick random key pairs because with a few bit ops any random bits become a random key) and after signing the enrolment step, the authenticator encrypts its new private key using that secret symmetric key and the DNS name in an authenticated encryption mode and provides that encrypted value too.

The browser, with the authenticator's help, puts together the final enrolment document, with a signature and it includes that encrypted private key as a Unique Identifier. All the Unique Identifiers in the protocol are huge random looking numbers, so the encrypted key blends right in with that.

For a web site, you need to store the public key (obviously) and this unique unique identifier value. You have to do that for everybody, anyway, it's mandatory. You can't decrypt the identifier even if you were sure it's encrypted, you don't know the key, so all you can do is play it back when you want a user to authenticate.

When it's played back, the authenticator takes the web site's DNS name, plus its own secret key, and decrypts the identifier to get back its private key, which it can now use to sign authentication messages. Of course if the DNS name is wrong, the decryption fails, which is exactly the same thing as happens if you try to use the wrong authenticator, or you're being phished, or a dozen other things - the authentication can't succeed.

The credentials are scoped to a relying party, which must be equal to the domain or registrable domain suffix:

https://www.w3.org/TR/webauthn-2/#scope

If this wasn't the case and it was old-school public-key verification, it would still be vulnerable to phishing, since the phishing site could just forward the challenges.

If authentication systems, like customers, think New Brand is just pointlessly confusing because it's different from Old Brand for no good reason, that undermines Big Boss's amazing strategy and makes it look like something a toddler would try, and that's not OK.

However the nice thing when you have players like Google is that their technical people have got license from above to say "Fuck off" on technical issues without somebody who doesn't know the first thing about it overruling them because their golf buddy asked them to. So you're not going to see a way to override this behaviour and thus allow phishing even though I'm sure HBO execs would think that's fine.

In terms of practical effect, what that means is that when they use WebAuthn outfits like HBO end up needing to keep login.old-brand.example working, even though supposedly old-brand.example was a completely different product and is now dead, because that's how users actually log into new-brand.example as they are in reality the exact same product.

https://www.w3.org/TR/secure-payment-confirmation/ https://github.com/w3c/webauthn/issues/1667

This is an anti-pattern, and is not worth supporting in new tech that's supposed to be "secure first".

We already have tech for delegating authorization.

It's still an attack scenario to keep in mind. If a server can be tricked into storing the wrong public key, authentication is defeated.

Many focus too much on the (potential) MFA use case rather than the idea that we can use effectively the same tech as in Yubikeys (etc) to make phishing resistant authenticators everywhere.

The (IMO) messy rollout by the major platforms really doesn’t help either. They absolutely could have spent a little more time baking the UX and designing edge case mitigations, but they didn’t.

On the flipside, that early lead also led to so many of the misconceptions about Passkeys that people have. People think it by nature has to be a locked, walled garden, because Apple has the lead and loves walled gardens when it has the lead.

I think that's why this newest rollout announcement is such great news (which we knew was coming, but wasn't obvious to some of those misconceptions from Apple being in the lead): complete integration with the larger ecosystem of password apps already in the App Store wild (use your 1Password passkeys just like you can use 1Password passwords), and a UX for grouping passkeys and sharing those groups with other contacts (that also helps with all the misconceptions about passkeys being some sort of crack down on password sharing).

These UX flows would have been great to have seen in the initial rollout to assuage a lot of fears about Passkeys. It is great to see them happening right now while it is still early enough to stop most of the FUD before it starts to get outside of the HN paranoia bubbles and into average consumer ears.

From the page:

> What’s new

> Now people can share passwords and passkeys from iCloud Keychain with their trusted contacts. *Password manager apps can save and offer passkeys on iOS, iPadOS, and macOS*. Enterprises can take advantage of passkeys thanks to Managed Apple ID support for iCloud Keychain. And administrators can manage which devices passkeys sync to using Access Management controls in Apple Business Manager and Apple School Manager.

Emphasis is my own.

Dashlane and 1Password both support passkeys, and you can export your data from both services. I am certain more will follow as more third party support arrives for managing passkeys.

I totally understand a pessimistic reading. In trying to roll out passkeys to everyone at once, and doing a poor job of UX and documentation clarity, all the major players bungled the 2022 launch. Not having some portability out of the gate absolutely caused unnecessary distrust about passkeys.

But I strongly believe this won’t become a vendor lock-in playground.

I have replied a lot about passkeys. I should disclose a former employer works in this space, but I’m not advocating for any particular company or product here, and I no longer have any inside knowledge relevant to the topic that isn’t already public.

Edit: grammatical typo; disclosure clarification

google.com (never save)

google.com (Jane.Doe)

google.com (Jane.Doe) (Grandma use this one)

google.com (never save)

google.com (Jane.Doe) (password missing)

google.com (Jane.Doe) *Your password may have been exposed in an online breach.

I fully agree with you. Passkeys solve a lot of usability problems, especially for the less technically adept, while solving so many password problems.

Edit: formatting nightmares

That’s not quite true, though. What is true is that the server does not have a plaintext copy of your private keys. That’s a crucial difference.

The server has an encrypted copy of your private key, which your with token decrypts with its private key. That is how a usb key can store an unlimited number of U2F credentials: The USB key isn’t storing them at all. They are stored on the server you are authenticating to.

What this also means is that if there is a backdoor in the crypto algorithm used by your token and an attacker gets a copy of the server’s U2F credentials, then you are at risk of having your private key stolen.

Here's a link to Yubico with a visual diagram of how passkeys work: https://developers.yubico.com/Passkeys/How_passkeys_work.htm...

But fundamentally it's very similar to how all public/private stuff works. You send people the public key and sign stuff with the private key.

If you don't trust a system to encrypt why would you trust it to generate keys with correct random or sign without leaking key data?

The encrypted private key isn't any more likely to be a weak link than the other things a token could do wrong.

First, ask yourself a simple question: How can a Yubikey store an unlimited number of FIDO2/U2F credentials. The official Yubikey documentation literally claims that Yubikeys can do that. Not “a lot”. Not “more than you’ll ever need”. Not 10k. Not 10M. Not 10G. Unlimited.

Gosh, maybe I should use a Yubikey for mass storage on the cheap! I wonder why nobody has done this?

Second, you’ll want to dig into what is the contents of the “key handle” that is passed from the server, through the user agent, to the key. Hint: Despite the HN hive mind, I’m not wrong.

the basic claim about being able to store "infinite" passkeys on a USB is also directly contradicted by the yubikey docs, which say they can store 25: https://www.yubico.com/blog/a-yubico-faq-about-passkeys/

No, that's completely incorrect. I'm not sure where you got that impression, it would be idiotic to design an authentication protocol that way. The server has your public key, you have the private key, and that's how the server knows it's you.

https://security.stackexchange.com/questions/237271/where-ar...

OTOH for resident keys they usually support 50-100.

"non-discoverable" WebAuthn keys aren't part of "passkeys", apparently, but they locally encrypt the per-site data, including the private key, and then give that encrypted data to the server to store.

The private key never leaves your device except to be encrypted and synced to your other devices using iCloud Keychain.

Passkeys are definitely a leap forward in that we are shifting the bulk of the account takeover risk from the end users using weak passwords or clicking on phishing links to: 1) The server side implementation, including any mechanism for account recovery and support for multiple passkeys/auth factors

2) The browser enforcement checks (eg: this is what Chrome does: https://www.slashid.dev/blog/webauthn-antiphishing/)

3) The wallet/keychain/password manager holding the keys (there's a lot of variance here in terms of security guarantees, see recent password managers breaches. We wrote a bit about how Apple does it: https://www.slashid.dev/blog/passkeys-deepdive/#the-technica...)

4) The authenticator itself (again, lots of variance here)

All of which are harder to compromise vs the average end-user.

There are still scenarios where the end-user could be targeted/tricked but they are fewer and harder to pull off (to name some: malware stealing the private keys and account takeovers on the password manager).