Live data from Hacker News

Passkeys now support external providers

developer.apple.com

41–50 of 185 posts

Re: Passkeys now support external providers

#41
post #33
post #2

Originally seen via https://reddit.com/r/Bitwarden/comments/141uxz1/iosipados_17... This is big news as vendor lock in and inability to use our own sync was one of the biggest issues bought up whenever Passkeys are discussed. Apple are now allowing external sync fabrics such as password managers.

> Apple are *now* allowing external sync There is no guarantee that this will be permanent. It can be revoked citing x number of reasons. Also, lets wait until the implementation details are available. If it requires providers having a native app on the device where Apple has control on who and what to allow, there's only an illusion of choice.

Pretty sure "now" in this context means "starting now".

Once people start relying on this, it will take a lot more than just citing reasons to revoke it without causing massive blowback.

Re: Passkeys now support external providers

#42

Earlier quoted context omitted.

I don’t think you are, plaid is a horrible and completely insecure work around banks not providing programmatic access. I’m not sure how it even works with second factors (I’ve never looked).

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…

As far as I know that’s pretty much what it is yes, a bunch of per-bank scraping systems, which get updated when the bank decides to switch things up.

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

Re: Passkeys now support external providers

#43
post #40

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

And how might this happen?

Re: Passkeys now support external providers

#44
post #11
post #5

Interesting, but can someone tell us what this implies wrt. authorities? If someone gets your iPhone and forces you to press your finger on the TouchID, he gets all your passwords no? While with a general master password you could just pretend to have forgotten it?

Whichever way you look at it, in every sense, password managers are a really bad, bad idea. Besides that, it is not needed to force you to press your finger; the delinquent needs only to have access to the device for to fool the sensor with a brute force, 2 hours in the worse of the cases with the simplest techniques. Although its easier to take your finger prints from a glass or something you used for to avoid the w…

I don't mean this personal, but I find it very very hard to deal with people like you in professional contexts. You focus on a 0.01% problem and make an absolute statement ("in every sense, password managers are a really bad, bad idea"), while completely ignoring that for everybody else, password managers (and even more so passkeys) will prevent real problems like their bank account being emptied.

Re: Passkeys now support external providers

#46
Good news. Lock-in was one of the biggest issues with passkeys. I think we will see a bunch of well known password managers adding passkey support soon.

Is there any standard for this integration/interoperability? What about moving from one provider/app to another?

Re: Passkeys now support external providers

#47
post #19

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…

The last one is a problem for a lot of use cases. Lots of sites have different domains (also for example when HBO max renamed to max). Plaid also relies on entering bank passwords on neobank sites and is widely used.

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

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.

Re: Passkeys now support external providers

#48

That's great to see! I just tried out 1Password's beta browser extension which has passkeys support, and the UX is super seamless. Played around with it on https://www.passkeys.io/ I'm really hopeful about this, a lot more than any of the previous iterations of the FIDO stuff. I worked at a company that was an early adopter/implementer of the original FIDO U2F spec, and it had major UX problems, enough that I couldn'…

> who the heck would carry a USB key with them??

Why not? I do this. It's no different from any other physical key like a door key, and I keep it on the same keychain too...

> The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey).

I don't see how this conflicts with physical tokens like Yubikeys? The tokens help you "remember" the key like how a physical door key helps you "remember" the bitting (which is the real authentication info).*

Just like passkeys, U2F can also be done using a virtual U2F device if you so choose (https://github.com/bulwarkid/virtual-fido). And presumably you could create an off-device portable token to store passkeys...

The real problem at the end of the day is just consistent adoption. There's still a ton of 2FA services that don't accept U2F and only use SMS or email codes...

*: This is a simplified take on things but at a high level that's what's happening.

Re: Passkeys now support external providers

#49
post #48

That's great to see! I just tried out 1Password's beta browser extension which has passkeys support, and the UX is super seamless. Played around with it on https://www.passkeys.io/ I'm really hopeful about this, a lot more than any of the previous iterations of the FIDO stuff. I worked at a company that was an early adopter/implementer of the original FIDO U2F spec, and it had major UX problems, enough that I couldn'…

> who the heck would carry a USB key with them?? Why not? I do this. It's no different from any other physical key like a door key, and I keep it on the same keychain too... > The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey). I don't see how this conflicts with physical tokens like Yubikeys? The tokens help you "remember" the key like how a p…

> Why not? I do this.

Again, you are not the general public. You're a highly technical person. My dad/grandma would never. That's the point.

Re: Passkeys now support external providers

#50

Earlier quoted context omitted.

> AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names assoc…

I may be wrong here, but since the yubikey and similar don't actually store anything site-specific, it means they just respond to a challenge, right? What they prove is that they own a specific private key. 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…

FIDO2 allows for things like resident keys, which the Yubikey can only hold so many of.

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

Post reply on HN