Passkeys now support external providers
developer.apple.com
developer.apple.com
> 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 or website they were created for, so people can never be tricked into using their passkey to sign in to a fraudulent app or website.
Plaid also relies on entering bank passwords on neobank sites and is widely used.
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.
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.
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/
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).
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.
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.
Once people start relying on this, it will take a lot more than just citing reasons to revoke it without causing massive blowback.
We don't know the implementation details yet but if this requires Apple vetting and whitelisting the providers then it can always be revoked for technical, business, political or any other reasons.
charge them random % of revenue, force them to funnel all transactions through apple, let random junior employees disable the 3rd party's bugfixes for reasons(tm), and eventually refuse to license new entrants because there are too many flashlight apps
I'm not worried
No reason to believe this would work differently than the existing affordances for 3rd party apps to offer passwords, which works well today
I would assume that the system passkey interface will handle the receiving app, and the sharing app will register with the system (NOT with the browser or app, although this doesn't preclude doing that as well) to vend passkeys.
Seeing what Bitwarden comes up with and seeing whether or not the process for self-hosted Bitwarden accounts is actually seamless and works on platforms like desktop Linux -- to me, that's going to be a really big test of whether passkeys can credibly be claimed to be actually cross-platform.
[0]: I do think there have been some smaller proof-of-concepts, but... there's a difference of scale here.
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 lives easier by removing the need to remember our banking passwords, it also will bring us further into the realm of technology by making more and more services log-in based.
A greater ease of making a log-in based service means more revenue, more profit for Apple, and a greater integration of technology into our lives. Few people realize this because we have been conditioned to believe that new technology is solely for our benefit.
In reality, Apple is not concerned with our benefit. They are concerned with profit and making technology more efficient to accomplish that end. So although passkeys might seem nice, there is a serious downside to this technology.
Upvoting this because it's a view worth sharing (and I'm sure you'll be downvoted just because of your baseless claim that Apple is concerned about something as dirty as profit /s)
All of their attempts at targeted advertising have been rounding errors at best.
And they know that complete unbreakable privacy is the place where Google (an ad company) can never ever fully follow no matter what kind of lip service they do in their keynotes about privacy.
make no mistake that this is the direction apple is headed. it's been clear for the last 5 years or so, since hardware sales have leveled off. perhaps the goggles will dampen the velocity a bit, but i'm very skeptical that the AR/VR market is mature enough to have that effect in the near future.
Actually, this ease of use may be beneficial to privacy. Sites don’t need user generated/remembered passwords to require a login, they can just use the sign in with Google/Facebook/Apple buttons. Because it is easier than remembering another password, users will typically use those options. Passkeys is more private than signing in with Google/Facebook/Apple, while also providing more privacy than those options.
Passkeys are an origin-bound login mechanism. Worst case is that somebody places a first-party cookie to keep you logged in after you authenticated with a passkey. which they and will already do today without your consent or without logging in. (First-party session cookies don't even need a cookie wall. They're considered "necessary" processing)
If more websites require logins, they can track you more easily, simple as that. It has nothing to do with the engineering aspects of passkeys, and everything to do with the fact that technology which makes logins easier will encourage more login-based services.
You need to step away from the engineering details and look at things sociologically.
Tracking you via your email address is actually better than using cookies (for the advertiser) because it works cross-device and cross-browser.
Any mechanism that makes it easier to login to sites will promote the usage of email addresses for tracking purposes. Think retargeting and conversion tracking (no longer needing to be cookie-based).
Passkeys = quicker and faster to get a user's email address.
Email address = even better than "super cookies"
At least in the EU, you'll need express consent to do this.
From personal experience, businesses I've dealt with in the EU are eager to be compliant as long as it's applied across the board (ie, they aren't losing their competitive advantage).
Using passkeys doesn't give a site your email address. The site would have to still ask for your email separately.
Hacker News, for instance, allows non-logged-in read-only usage. If Hacker News decided that Passkeys were so easy for the user that non-logged-in usage would be eliminated, then some degree of privacy would be lost.
Personally, I don't think it is that much of a risk. I DO worry about putting too much control in the hands of Apple and Google.
Not if you the user generates a new login upon every visit, which should be trivial.
This trend is already in motion thanks to the deprecation of 3rd party cookies and Apple's restriction of device identifiers, etc, on iOS.
For most advertisers these days, the only way to run retargeting campaigns or measure conversions is with 1st party data. That means people are no longer relying on cookies at all for much of their conversion tracking. Instead, email addresses are used.
This is (I think) an unintended side effect of stripping away cookies.
At least with cookies, you could delete them locally. But now so much tracking is done with first party data, cookies are playing much less of a role. And of course there's not an easy "delete all first party data" button in your browser because the data is (obviously) held outside the browser.
Sites already desperately try to get people to log in. I don’t particularly see it as an advantage for Apple if eg the Reddit website or some random online shop makes you log in. If Apple are interested in selling ads, I think they should not want to make it easy to track people on websites through logins as that helps their competitors.
I generally model Apple as preferring that you use (and pay for/in) some app rather than a website, and logins are less necessary for apps where you can store information about your session and don’t need to regularly prompt the user for passwords. I think Apple would rather you don’t have some separate account you can log into on a website to eg pay for a service without in-app-purchases.
I mostly think of passkeys as a better version of the password manager: allowing users to do what they already want in a more secure way. If there is some subtle business advantage it is maybe that users would make new accounts rather than using sign-in with Google/Facebook, though I don’t know to what extent those features are valuable to Google/Facebook.
This also seems to be the polar opposite of most complaints about passkeys. The typical response is that they won't replace passwords because passwords are easy and accessible. Here you are saying that passkeys are easier. It can't be both.
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.
I worry a little about normalizing on fingerprints, but not because tin-foil-hat thinking about tracking.
Those can certainly be ordered/forced by a judge, where passwords/codes are less well defined. I'm not up to anything shady, but I fear an authoritarian government.
Let's consider PINs, too. Those can be used instead. How many of these are people going to memorize? Many passphrases become one relatively easily guessed number on a device you can lose
Implementation details, surely - and I'm really green... but I worry about unintended consequences a lot
https://support.google.com/accounts/answer/13548313?hl=en#zi...
As for what Google does specifically with their implementation, I'm not sure. I personally plan to use KeepassXC's implementation, whenever that comes out, with my own custom database backup strategy.
The WebAuthn specs recommends to register multiple passkeys/credentials per device and assume that once a credential is lost it might not be recoverable.
Apple and other vendors using keychains/wallets are effectively offering the option to delegate the recovery of the passkey to the recovery of the account with them (eg: the iCloud account).
In case it is of interest, we wrote a long blogpost on the topic: https://www.slashid.dev/blog/passkeys-security-implementatio...
It's too early to completely replace all methods with passkeys, but the hope is that as they gain better support and understanding websites will be able to make other methods rare/exceptional. For exceptional cases such as account recovery, as opposed to day-to-day account sign-in, there is room to apply a lot of other abuse signals and other methods to make it harder for attackers.
More here: https://security.googleblog.com/2023/05/so-long-passwords-th....
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? Or do I need an Android phone for that? Can I use an iDevice to authenticate with an Azure AD app? Can I recover the passkeys on a lost iDevice without having to pay Apple for a new device to restore the backup? Etc...
I guarantee many more release notes that could be summarised as: "Now supports a common scenario!"
"Why? Where's the profit for us in that case?"
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.
Also, I use Firefox exclusively.
This is precisely what I mean: common scenarios are not yet supported.
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.
Yes and no, respectively.
"Passkeys can now be synced using external providers..."
so it's hard to say exactly what it will mean for user control and choice. Which external providers? Will users be able to access and store their own private keys in compatible apps of their choosing? If so, aren't we largely back to passwords?
A password is a shared secret. Even if it's hashed on the server side, one could brute force it if a weak algorithm is used, or MiTM the service to get the plaintext when the user logs in.
Passkeys / webauthn utilizes public key cryptography. I'm only ever giving them a (by the spec, unique to the combo of me and the site in question) public key to which I hold the private key pair.
Authentication doesn't involve transmission of these, it's challenge based where you prove you have access to the corresponding private key.
Key based authentication is a huge security improvement over passwords (especially for reducing phishing risks) even without the device-bound restrictions.
I'm strongly opposed to hardware-bound keys as a mass standard for most users, but key based authentication is great. One big advantage is that during the login process, sites "prove" their identity to you.
This is a security improvement that you could previously only really get with browser extensions and password managers, and even there it wasn't great because those extensions didn't work consistently across all sites and often failed at autofill, so a website failing to pull up your password manager might not actually be interpreted as a red flag. And there are other advantages too around account security for service providers, etc... none of which require attestation or hardware-bound keys.
If you've been using a password manager with randomly generated passwords you've already addressed some of these issues so the benefits of using passkeys over passwords is reduced.
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't see it ever being used by the general public (who the heck would carry a USB key with them?? and this only works with desktops/laptops, sure Bluetooth support, but ehhh), but with this, synced to your password manager of choice, that's A LOT better.
The passkey is usable anywhere (signed up on my desktop, hopped over to my laptop and signed in there with the same passkey). I can't use it from my Android phone yet, but that will come soon I'm sure when 1Password adds support to the mobile apps + Google does the same as Apple here with adding proper Android integration.
On Android I can still only use a USB/NFC/Bluetooth security key, or "my lock screen" (i.e. on-device security key, not passkeys) so far. If I click on "Sign in with a passkey" it says I have no passkeys via an Android system dialog, but if I sign in with my email it lets me use my "security key" (i.e. biometric lock screen prompt).
On Windows, I think all browsers handled it centrally with Windows Hello, but even there the WebAuthn devices just kinda disappear into the ether once you register them, and deleting them had to be done through the command-line. There were also weird ass bugs where the UI would behave completely differently depending on whether or not you had Windows Hello login in use, so websites would need to engineer around it.
Haven't played around with passkeys key, but I imagine the only direction to go is up.
> but with this, synced to your password manager of choice, that's A LOT better
While I agree with your general point that passkeys are great, I strongly disagree with these specific points. It's much easier for me to carry a small usb-key everywhere than it is to carry a big-ass phone (I often leave it at home) or my own computer.
With a yubikey on my keychain, I can log into my company's AzureAD from any computer. In a pinch, this also works on a phone if it has an NFC reader. It used to work fine on my iphone 7.
Another use case is specifically not wanting anything company-related on my own computing device. My personal phone isn't enrolled in the company's AzureAD, I don't have their 1passwork vault there, etc.
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.
Again, you are not the general public. You're a highly technical person. My dad/grandma would never. That's the point.
I've found it really easy to teach non-technical people how to use U2F tokens. Just tell them it's like a door key but instead of plugging it in and turning, you plug it in and touch. That's all there is. It's been much more intuitive* to my older family members than SMS codes (that sometimes get lost), authenticator apps (that have a huge list of services from which you need to quickly find the one you want and type the code), or password managers (that either cost money or are difficult to set up across devices).
*: I know this because I've never had to do "tech support" for family members that have accounts set up to use U2F tokens, but I have had plenty of calls related to "not getting the SMS code" or "the (insert brand) password manager isn't filling in the password for my account!"
How can I know that won't happen when I use my USB dongle on a random coffee shop public computer?
How is that different from a password? How can you know that when you type your password into a random coffee shop public computer that the computer isn't running a keylogger and sending your credentials to criminals?
You can actually safely plug U2F tokens into random computers and rest assured that the keys inside cannot be cloned. This provides security guarantees above and beyond that of physical keys! In fact, an untrusted computer can't* even MITM the authentication process of U2F, unlike with SMS codes! (Of course, an untrusted computer could fake the UI to try and exfiltrate other info from you, but that's beyond the scope of authentication itself.)
The worst a malicious client can do to a U2F token is to fry it :-)
*: There's some asterisks here, but if you want to know the details check out the U2F spec or this https://www.yubico.com/blog/creating-unphishable-security-ke... for a more accessible explanation. Banking-grade U2F/similar tokens actually behave like hardware crypto wallets and will show the auth request metadata on an internal screen, in case the device you are plugging into is completely untrustworthy.
Are you sure? https://www.minutekey.com/products/key-copy-kiosk/
U2F tokens are "Trusted Platform Modules" of sorts. The keys themselves are never visible to the devices you plug them in. They are capable of answering challenge/responses, and having the URL part of the challenge prevents phishing[2].
I am much more comfortable not typing any password on a public computer.
[1]: https://www.wired.com/2015/09/lockpickers-3-d-print-tsa-lugg...
[2]: https://en.wikipedia.org/wiki/Universal_2nd_Factor#Advantage...
I need to read up a bit more on passkeys in general tbh.
For anything non-important I actually use sign in with Google, so.
Passkeys in general, especially the focus on a lot of site-specific E2E shared ones, are very much "just like a password", but as the sibling comment points out, the switch to PKI alone is a huge security win and would stop a lot of the haveibeenpwned sorts of leaks and the overall attractiveness to crackers to break into various company's password databases, because only having a public key is a lot less useful than a salted/hashed password that might be broken or found in a rainbow table.
2. it only hints at the UI being open to other apps, approved in the app store of course, using their new undocumented api
3. the sharing features will probably happens over their central control. not over the UI implementers.
so many misconceptions in these comments. specially mixing up passkeys with in device keys
but it creates lock-in, if all your credentials are in a iCloud keychain, you're encouraged to get a phone that can sync with your ipad, laptop, and desktop.
Manually find and re-sync your stuff from firefox-on-desktop to chrome-on-mobile to safari-on-ipad is a major PITA.
Is there any standard for this integration/interoperability? What about moving from one provider/app to another?
the article says nothing to that end. still full locked in.
the UI will allow implementations... via app stores approved apps using their OS apis. for sure.
Users should decide by themselves where they want to store the authenticator: be it a separate device or a password manager running on their computer. Authenticator is just an algorithm that uses key material from elsewhere (biometrics, master password, whatever user prefers) to perform the authentication.
Tying the whole thing to a couple of corps is cringy and creepy at the same time. There must be an open standard where everyone can participate.
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.
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 wait, or directly cut your finger if its a psychopathic criminal.
And in all the cases, once your fingerprint gets public it gets compromised until the end of the times, of course, you can not "change the passw".
This without talking about software infection with a remote attack.
Let's look at password reuse for example. As soon as you have more than a few dozen logins, the possibilities are mostly either reusing one or few passwords, or writing them down.
Reusing is objectively bad, and for writing them down, the password manager makes it easy to use a really long and random password, which would make it tedious to write down.
If that passwords are stored in internet even worst, one can take for sure those passw-managing servers are juicy targets, it is a countdown until the server will get compromised.
If the user is only storing the pass of chat forums, I think then is one thing the attacker probably will ignore, if the reverse engineering of one of those sites using user's name is not in the secondary target list.
Anyway, to use a unique password for every server, account, etc is a must do from the beginning of time, even for the temporal forum one had to register for to use a few minutes. It is the first computing directive. It's just the password managers are not accomplishing the objective of such directive.
Okay, how about, the actual problem they solved: Reusing a single, simple password on every site, shared behind an email login.
That doesn’t sound like a really, really bad idea.
Every body can continue down-voting, but that fact is not going to change.
... and if a copy of the password wallet has been obtained.
They didn't invent the idea.
They just made it useable for people who have a lot of different accounts.
I've got nearly 500 accounts, and based on a comment thread a while back where someone asked here how many accounts people have in their password managers I'm on the low side.
The lottery chances have, however, dramatically changed, from no longer relying on the ongoing security practices of every single website you have ever signed into once being eternally a risk to breaching every single other website you have ever signed into.
Perhaps you alone can remember a cryptographically secure password for every website. But I’d more suspect your downvotes come from the impression you give of apparent inexperience combined with what looks like a child-like propensity to bluster.
I'll just respond to this, as the other commenters are doing a fine job of addressing your other claims.
Your passwords aren't encrypted with biometric data of any kind on Apple devices (and I suspect that's true of Android as well). Simplifying a bit here, but it's broadly accurate: your biometric doesn't unlock your entire password database, it unlocks the stored secrets needed to decrypt your password database. iOS (and, likely, Android) devices have a simple way to force a passcode/password to be entered rather than using biometric data to unlock the device.
On iOS, activating the Emergency SOS feature (without subsequently calling emergency services) and then locking the device as normal (with the power button) will require the first factor (your passcode/password) at the next unlock attempt. No amount of finger-cutting or face-slicing can get past it. It's been that way for six years now, and was famously referred to as "the cop button" when iOS 11 introduced the feature.
update this dev news announcement actually opens the setup a bit more, instead of close it down a bit more. However the whole Apple walled garden and always-on networking is not a happy thing from this desk
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.