Passkeys now support external providers • Hacker News Board

Re: Passkeys now support external providers

#141

Post by cco » Tue, Jun 06, 2023, 8:15 PM UTC

TheNewsIsHere wrote: post #100

squeaky-clean wrote: post #27

Earlier quoted context omitted.

If you have 2 factor enabled for each login you get told your account settings are incompatible with Plaid and have to disable 2fah. If it's only enabled for first time logins on a new browser/client Plaid ask you for the code. 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 sup…

This is one of my (numerous) top complaints about Plaid. From the start they’ve been more about working against than working with banks, and that’s sort of obvious still today. 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…

> From the start they’ve been more about working against than working with banks... At the very beginning sure, but very quickly Plaid built out a team to try and work with banks. Banks were the biggest roadblock to OAuth, most banks have (had) zero appetite to provide a good experience for users to delegate programmatic access to their own user data. Banks see user financial data as their own and _not_ belonging to their users (as it legally does).

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.

Re: Passkeys now support external providers

#142

Post by DANmode » Tue, Jun 06, 2023, 8:22 PM UTC

labcomputer wrote: post #133

ckastner wrote: post #10

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app…

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers 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 U2…

https://en.m.wikipedia.org/wiki/FIDO2_Project

Re: Passkeys now support external providers

#143

Post by notatoad » Tue, Jun 06, 2023, 8:36 PM UTC

labcomputer wrote: post #133

ckastner wrote: post #10

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app…

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers 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 U2…

i'm pretty sure you're wrong. or at least, you're directly contradicted by the apple docs, which say "The other key is private, and is what is needed to actually sign in. The server never learns what the private key is." https://support.apple.com/en-ca/HT213305

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/

Re: Passkeys now support external providers

#144

Post by [deleted] » Tue, Jun 06, 2023, 8:40 PM UTC

labcomputer wrote: post #133

ckastner wrote: post #10

Of all the recent publications with regards to passkeys, FIDO2, WebAuthn, etc., finally there's one with a simple and concise summary of the benefits: > Strong credentials. Every passkey is strong. They’re never guessable, reused, or weak. > Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers. > Safe from phishing. Passkeys are intrinsically linked with the app…

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers 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 U2…

[deleted]

Re: Passkeys now support external providers

#145

Post by anderspitman » Tue, Jun 06, 2023, 8:47 PM UTC

withinboredom wrote: post #89

dan-robertson wrote: post #74

Earlier quoted context omitted.

But Apple offer this service where they make a fresh proxy email for you which is unique to the service. Why would they do that if they want to enable cross-service tracking via email address?

I use 1password + fastmail for exactly this. The integration is better than Apple IMHO.

Do 1password/fastmail have functionality built in for this or do you just manually generate your emails based off a wildcard?

Re: Passkeys now support external providers

#146

Post by anderspitman » Tue, Jun 06, 2023, 8:57 PM UTC

goalieca wrote: post #61

vouaobrasil wrote: post #52

So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing…

Each website gets a unique key. They are not signed or rooted in any trust. You can still pick any username you want for the account. What passkeys do is replace OTP and MFA. They live along SSO and do not replace it.

I think the first use cases of WebAuthn were targeted at MFA, but passkeys are definitely being advertised as replacing passwords as the primary/only factor (with the caveat that you'll also be expected to perform some sort of pin/bio authentication on the local device).

Re: Passkeys now support external providers

#147

Post by danShumway » Tue, Jun 06, 2023, 9:04 PM UTC

I still want to see more details. That being said, extremely positive news. Vendor lock-in is one of the biggest issues with passkeys and one of the biggest reasons I haven't been able to get on board with them and why I usually end up advocating against them whenever they come up.

Between this and Apple blocking attestation efforts for mobile passkeys, it gives me more confidence that this could turn into a standard that I want to use. I criticize the passkey standard pretty consistently, I would be very happy to eat crow on that.

I will say that it would go a long way to make this stuff part of the standard, I don't like how much these really critical pieces of passkey functionality are boiling down to "wait and see what vendors do." But I'm cautiously optimistic to see where things go. It is a really big deal for Apple to support 3rd-party providers and an even bigger deal for Apple to support sync with 3rd-party providers.

Re: Passkeys now support external providers

#148

Post by danShumway » Tue, Jun 06, 2023, 9:14 PM UTC

vouaobrasil wrote: post #52

So far, no one has commented on this large downside of passkeys: that it will promote the ease of sites to require login since it's much easier to generate a passkey than to remember a new password or even store it. Thus, passkeys lubricate the path towards an ever-increasing login-based society where it becomes much easier to track and monitor your online behaviour. Although it has the benefit of making our existing…

This is not high on my list of concerns about passkeys.

I worry about attestation, vendor lock-in, the spec process, etc... but (if attestation isn't a huge issue) easier account creation is not a huge deal because multiple-account creation will also get a lot easier.

If a system is requiring your passkey plus a metric to verify your identity (again, assuming attestation doesn't become a problem), then they're already in a position where asking for your email is not a big deal. So I don't see how passkeys change anything for them.

On the other hand, any account that would have asked for my email before now doesn't have to. And if attestation goes well and Apple continues rejecting it for roaming providers, they won't get any information other than my login credentials. I have disposable email addresses, but most people don't. Getting rid of a factor that essentially forces them to only have a single account with a service and makes it easier to track them across services -- getting rid of that is a good thing.

There's tons to be worried about with passkeys, but this is not something that worries me. What worries me is if attestation pushes its way into the roaming provider implementations and suddenly I can't create an account on a rooted phone anymore. But getting rid of extra verification/identity steps would be good for users and good for privacy. It would be great if I could sign up for a service just with a key and without an email address.

Re: Passkeys now support external providers

#149

Post by danShumway » Tue, Jun 06, 2023, 9:23 PM UTC

echeese wrote: post #118

jiggawatts wrote: post #37

My method for judging the quality of software: Read the latest release notes, negate every statement, and think to yourself: "They were fine with it being like this until now." Passkeys have been advertised as a superior replacement to passwords, but really fundamental issues remain unaddressed. I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Will both be able to log me in to a Google Account?…

> I have one (1) Windows PC and one (1) iDevice. Can I get these to sync? Or do I need an Android phone for that? Yes. In Chromium-based browsers, at least. Your browser will display a QR code which you scan with your phone. Your phone will display a list of accounts you can sign in with, you select one, authenticate, and you're logged in. Firefox support isn't here yet.

Passkey proponents have played really fast and loose with the word "sync" in my experience. No reasonable outside observer would call this syncing, it's cross-device sign-in.

It's like saying you can sync your OTP-provider to your desktop computer because when you go to log into a website you manually copy the code into a form. That's not how most people understand the word "sync."

What people are excited about here (assuming the details are good) is actual sync -- the ability to take your iCloud passkeys and literally move them to a new device outside of Apple's ecosystem as a mass operation rather than site-by-site. And that's really good and I'm excited about it and I hope that it addresses all of my issues. But its frustrating to see people still misrepresenting what's capable with the ecosystem today even under a positive announcement that signals that the actual concerns are getting addressed.

It's so weird, I don't know of any other open standard I've seen where the proponents are so creative about acting like the ecosystem already supports things that aren't supported yet, and it's a huge reason why I remain skeptical of the passkey ecosystem -- because there are good-faith actors telling me to trust them but they're surrounded by people who are straight-up giving incorrect answers to basic questions like "is sync supported." I don't get it. If the limitations are going to be addressed, what is the value in pretending that they don't exist? How does the ecosystem benefit from that? All it does is decrease trust, to the point where I feel like I need to double-check every assurance I get from FIDO advocates to make sure that they're not redefining words.

Re: Passkeys now support external providers

#150

Post by danShumway » Tue, Jun 06, 2023, 9:30 PM UTC

yomlica8 wrote: post #54

garganzol wrote: post #45

I'm totally in if passkeys come without middle men, especially like Google and Apple. Otherwise I'm totally out. No trust in these guys, they are as capricious as Roman emperors and will eventually do their usual stuff: lock in and collusion.

I've got a big problem with the attestation feature even existing in the spec. I know Apple plans to "zero it out" but if that changed sites could lock out non approved devices. I'd vastly prefer it wasn't part of the spec at all rather than relying upon the whims of a single megacorporation. If they ever drop that cover things will gradually become defacto locked to middlemen anyway.

This is a great point. I'm really happy about Apple's plans, but I have a hard time taking it at face value that there's nothing to worry about here if there's resistance to putting that plan into the spec itself.

Because I start to get suspicious any time a company says, "we're not going to do X, but we absolutely refuse to commit in any meaningful way to not doing X."

There's an implication there. I feel the same way about syncing, honestly:

"Everyone is going to support 3rd-pary sync."

"Can we put it in the spec that they have to?"

"Well, that would be overreaching..."

I think there are a lot of people who have genuinely good intentions, but it still makes me pretty nervous. If we could just trust every company to magically work things out and be compatible with everyone, we wouldn't need industry specifications in the first place. I think it's appropriate to try and standardize the baseline mechanisms users should have to control their keys and preserve their privacy.