I am personally not switching to passkeys unless I see a clear description of all possible failure modes. I.e. Google blocks you, you loose your phone, you want to migrate from one provider to another, when passkeys offer more security and when less.
I feel with authentication, it's always those special cases that determine the usefulness and security, but when passkeys are discussed I never have seen a proper discussion a pros and cons and special cases. At least with regular passwords + 1password I kind'a understand what i am protected against and how to restore from disasters.
1. If I can fully physically own some of my authenticators. Aka if Yubikeys or similar hardware tokens are supported, so I don't have to long-term trust any corporation to correctly and securely store my credentials - with Yubikeys the only trust is that hardware is free of vulnerabilities or backdoors.
2. If I'm guaranteed to be not bound to any single specific authenticator. Aka if I'm safe if I lose a Yubikey, assuming that I've prepared ahead of time (also see the next point).
3. If I can enroll an authenticator without having it physically present. Aka if I can sign up with one Yubikey and then tell the website "here is my phone, here's the public key of the Yubikey I keep in a safe, and here's a public key of a keypair I've generated on an airgapped machine, etched onto a titanium plate and buried in a secret stash, accept those for me as my alternative authenticators even though I don't have my private keys present". Aka if I don't have to run around the house (or worse) to just sign up for a website.
4. If I'm guaranteed to be able to use a software authenticator of my own development, shall I want it (despite whatever site owners may think of it). Aka if there are no attestation requirements that force me to use authenticators I don't trust.
If it's "yes" to all four, then I'm in and advertising this to everyone I know about, because this is much better than a password manager. If 1, 2 and 4 are "yes" then I'm probably in with a mix of one HSM and one software authenticator with exportable private keys (so I have a guaranteed way out), but voicing my displeasure wherever I can as the system is inconvenient. If not, then I'm probably sticking with passwords for the time being.
1, 2, and 4) Yes, that's already possible. Look into Solo Keys for open source hardware and firmware. The standard allows for key manufacturer attestation but seems like the way it is going (especially with the proliferation of software authenticators) it likely won't be relevant in practice. You can also enroll many authenticators to the same account (provided the service allows it, which most do).
3) This is pretty hard/impossible, I think. The authenticators don't use the same key-pair for all websites (a la SSH through Yubikey), but rather create a per-service, per-credential key-pair, and encrypt it with the main key-pair. The encrypted credential key-pair is then handed off to the server for storage, and the service sends it back for the authenticator to decrypt and use during a challenge. Clever trick to not depend on local hardware memory and be able to have unlimited per-credential key-pairs, but afaik prevents you from just "adding lists of public keys".
I'm also not mentioning the resident keys aspect of the standard but that won't fix it as they're still service and credential based.
A simple proof of possession (pop), signed ahead of time, solves #3.
The message:
`{"pay":{"alg":"ES256","msg":"I own this key","tmb":"9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk"},"sig":"eXuV0_HYCM-WnS2CbOnGXdce-9M8AzivCw23Hihtp1h69Ix6HwWCA79FR6cs3Nym2bWJoKajtnIY0xcTnuRnNQ"}`
The public key:
`{"alg":"ES256","kid":"Zami Mobile 2","x":"PZpmb3CI_2LTWcxopqjliqohPpmxFmNwKLb52wJgMg-4Xd0hTRKn7OruUMa3LvHmuTA9pHidocLHnEdOcQ04OA","tmb":"9PcBWntvjAktwfiPp8WxgOyQOwc1h6Lo1UnB_gkWXKk"}`
I see passkeys as a convenience, particularly for low value accounts. They feel more like a more universal implementation of a password manager, because that's really what they are.
What I don't like is this push to have passkeys replace everything. I very much like the 2FA with Security Keys of Google Advanced Protection.
Much of the current security shift seems aimed at minimizing MITM and phishing attacks. These were great low-skill attacks that relied mostly on social engineering. As those attack vectors shrink with better 2FA and things like passkeys, people adapt. I'm already seeing it. Now the focus seems to be on session hijacking and other most sophisticated malware. Nastier stuff, really.
I'm with you though. It's becoming harder and harder to figure out what to do and how to manage things. And the biggest risk seems to be the company you are relying on. If your account IS compromised, they are more likely to ban you than help you.
In this case, 1P would be the password manager for your passkeys as well which means even if Google blocks you, you would still have your passkeys to log into your bank, facebook, etc.
Google blocking you doesn't affect passkeys; you must be thinking of things like "Sign in with Google" where you must sign into Google to sign into another website.
The best thing about passkeys that's not available to traditional passwords is that you can have multiple passkeys that are equally valid, unlike the case with passwords where you can have but one single valid password. As someone who uses both Android and iOS frequently, I can set up passkeys on an Android and then an iPhone without needing to trust anyone (not Google, not Apple) to sync them. With that understanding I can address your concerns:
* If one phone is lost, I can use the other passkey to revoke that particular passkey.
* Even if Google blocks me so completely that my Android is remotely bricked by them, the other passkey still works.
* Migrating from one provider to another is trivial: I might be belaboring the point but you do not need the exact key material to be migrated, you only need a new equally valid passkey.
Passkeys strike me as a solution to a problem that security professionals have—not users.
When I log into a site via Passkeys with Safari on macOS, it shows me a QR code that I have to scan with my phone.
This alone is a huge assumption. My dad can’t stand his phone and will not want to use the thing to login to websites.
Then there’s other problems: what happens if the phone is lost, the battery is dead, or the person doesn’t want to get up and get it? Are they denied access?
That doesn’t even get to what happens if the Passkeys are somehow lost, then I bet where back to something that looks like a username and password.
I know there’s other Passkey UX’s, but of all the implementations I’ve seen to date, they all seem to be built by people in tech for other people in tech. Consideration for non-technical users seems to be lacking.
The MacOS situation has been the most confusing. Neither Safari nor Chrome can use passkeys, which makes me think Apple either doesn't allow/support syncing them directly to the MacOS keychain, or the (windows hello-esque) APIs to access them are just not there.
What I’d expect from Apple is the Passkeys are stored in iCloud Keychain. To use it would ask for Touch ID authentication on that same device, then provide the key to the website after a successful auth.
The “go find your phone and take a picture of this QR code” seems like insanity, even if they’re trying to require two devices to authenticate.
Windows exposes APIs for "windows hello" - which is an easy way for apps to authenticate via usb authenticators or windows' built-in authenticator (when available via TPM). I imagine that, on macOS, such an API would allow apps to authenticate using any passkeys in iCloud Keychain directly, of course with an OS-based user presence requirement like entering system password or using touch ID.
You can just create a new passkey on the device from the new provider and register it with whatever service you are using. You can have multiple keys registered for a single service, like one unique key per device.
In this case, you can use a non-google key manager such as this 1password password manager to manage your keys.
Even when using a Google related app, your key is still on your device, it just won't be synced to your google account anymore in the case that google terminates your account.
Our website is already using public key authentication using Coze. https://github.com/Cyphrme/Coze. We've been doing public key authentication for around 2 years now. No passwords needed, just public key auth.
I really don't know how I feel about this shift in passwords. I have long preferred the use of a password manager knowing that if they do something shady I don't like (like when I moved from lastpass to 1password) I could just pick up and move and I was not locked into that platform.
That doesn't mean I have not used SSO before with my Apple ID, but it was not my preferred way to log in.
My primary worry is being locked into a specific provider of login (like 1password) and not able to ever leave them. I ditched google long ago but I still have some accounts I have to log in with Google.
Is there a part of Passkey that makes this a non issue that I am unaware of or are we kinda just doing another version of SSO with a biometric component?
Also related, what about devices without biometrics? Does it fall back to your phone or something?
I also don't love the idea of the provider of the passkey authentication having data about where I go, where I login and when.
At the end of the day passkeys are a public/private key pair. While now they're new and it seems everybody's doing some sort of lock in, I would expect standards to emerge soon to export the private keys and reimport them in a different apps.
Unlike passwords, passkeys protect against phishing and are not shared with the server (the server knows the public key, not the private one).
Biometrics on phone are used to unlock password manager/passkeys, but they're not sent to the server (thanks god!) for verification. So they can't really be used for remote authentication.
You hit it right. It's not much different than saving your HOTP/TOTP key into your password manager. Instead you'd save the WebAuthn private key and nobody could impersonate you without gaining access to your private key from your password manager (1Password, Android, iOS, Chrome, etc.). At least that is how I have come to understand the inner workings of it all. People rely on PKI for encrypting messages, signing messages, secure remote access, etc., so I think it only makes logical sense to extend it to web application authentication.
It’s not really a new standard, it’s FIDO2, it’s been around for a while using security keys (yubikeys, solokeys…).
Passkeys used to be called non-resident keys.
In the world of hardware security keys there was no backup/share of private keys.
In this new wave of software authenticators (typically backed by the hw coprocessor that’s now available in phones & laptops), they called them passkeys, added sharing across devices, and a few debatable features like interactions with servers that may lead to lock in/tracking/etc (or may not).
Correct. Nothing is centralized about Passkey (other than where you may choose to store your authenticators). Each site gets a unique keypair. If your keypair is compromised you can delete it on that given site.
Passkeys is more or less just a more convenient implementation of FIDO2 or the like, as you'd traditionally have with a Yubikey token. Instead you move it to a supported password manager or mobile device.
If you want to try it out go to https://passkeys.io on your Android or iOS device. I do believe Passage is more or less what Passkeys is/already was.
I'm patiently waiting for Bitwarden to implement passkey support. The ability to self-host the key synchronisation/generation mechanism is the biggest blocker for me right now.
1Password supporting them as a relative outsider (i.e. not Apple/Google/Microsoft) is a nice improvement to the system.
Passkey folks - can someone explain to me how this makes things more secure?
For example, let’s take Apple. Apple Passkey support is great - I can store a passkey and it syncs through iCloud to all my devices. So my phone can login, my macbook can login. Neat.
But thinking about this a little more, Passkeys on iPhones are secured with FaceID, so to login I have to use FaceID or other biometrics. But on iPhone you can skip the FaceID check if you know the device passcode as fallback. So now, if someone has access to my iPhone and knows my passcode, they have access to ALL my accounts that have Passkeys stored on my iCloud.
Previously, even if an attacker had access to my iPhone, they still wouldn’t be able to login because they don’t know my password. And 1Password itself uses a separate unique password and can’t be skipped with device passphrase.
I’m honestly surprised that we can’t lockdown passkeys on iOS with a separate password/key that’s used to encrypt those. It just seems like I’m giving up on security by switching to passkeys, away from randomly generated passwords. IMHO it should be: FaceID, and if you can’t use biometrics, you HAVE to specify that unique passkey-only encryption phrase to unlock it. Not device passcode.
If not that, then I would have expected passkeys to be factor 1 authentication to directly replace passwords, and then have something else as second factor, such as TOTP/yubikey/SMS auth. But current implementations on any website I’ve seen so far treat Passkey as “ok you’re in”, while going the password route usually triggers a second-factor check.
Your iOS device passcode also gives root access to your entire iCloud account, including the ability to reset your account password. This was highlighted a couple months ago by the Wall Street Journal in relation to a recent wave of thefts & account takeovers which were exploiting this: https://www.wsj.com/articles/apple-iphone-security-theft-pas...
It seems we all need to treat our iOS device passcodes with as much importance & sensitivity as the password to our password manager—essentially root on your digital life.
I think you're misunderstanding the intent of this. It's meant to stop the theft of text authenticators, from breached databases. It shifts from "something you know" to "something you have." The problem with "something you have" to this point is that your average consumer doesn't want to buy and use a Yubikey. It's making PKI (which the DoD still uses for authentication) much more accessible, available, and convenient, for the average user.
> It just seems like I’m giving up on security by switching to passkeys, away from randomly generated passwords.
This is true for you, but the majority of people reuse poor passwords all over the place and do not have mfa setup.
For the average user, the risk of a breach on some poorly secured third party site is significantly higher than someone stealing their phone and cracking their passcode somehow.
If I conceptualise it as "your device unlock code is now also your master password but instead of randomly generated passwords we're using a key system actually designed for what we're doing with it" it makes a lot of sense.
Is it less secure than a Fully Correctly Implemented set of current best practices for sufficiently* paranoid geeks? Arguably, yes.
Is it more secure than what almost everybody was currently doing while also having the absolute bare minimum of friction to get the benefits it does provide? I strongly suspect so.
* I really do mean 'sufficiently' rather than 'excessively' here.
Most attacks are remote, not involving physical access to a specific (compromised) device. Think a compromised website exposing 1000s of peoples passwords, and trying those passwords against other services. For that threat vector, it is more secure.
The way I would look at it is if that threat concerns you, don't use it for high-value accounts (email, bank, etc). Still is probably worth using for all those other low-value accounts; if an attacker has your phone, and has broken in to it, them having access to your Netflix account is probably the least of your worries.
There are hundreds of phones stolen by the youth with hoods and stolen e-bikes in London each day. If they grab your phone in the seconds before it locks your screwed. That’s my biggest concern!
The passkey provider should require either a PIN or biometrics each time it is authenticating you against a service. So it won’t matter if your device was unlocked when it was stolen
Using Apple's Passkeys is just like using Apple's Password Manager. If you were using that you'd already be in that situation where your device unlocks all your passwords and all an attacker may need is your device passphrase. Passkeys from that perspective is no worse than existing iCloud passwords.
You mention 1Password, and 1Password has just released their first steps into Passkey support and being a Passkey provider. You can download updated extensions for a number of browsers and use passkeys stored in 1Password, if you trust 1Password and like that flow of a secondary vault.
The current rub is that you can't yet use passkeys from 1Password on iOS. That's hopefully a gap that Apple will fix soon enough in a similar fashion to how iOS supports multiple password providers.
I’m neither here nor there on passkeys, but I think in this scenario if you stored your passkeys in 1Password at least - then when biometrics fail, it would require your 1…password.
Although I don’t know how the passkey support in 1Password will work, so I may be wrong on that.
The passcode fallback isn't available for passwords, just for unlocking the device. In fact, IIRC I don't think you can set up iCloud Keychain without FaceID being enabled...
Interesting, but weird pricing. "Contact us" for 1,000+ MAU, which is every useful app out there. Compare this with Supabase, which is $25 for 100,000 MAUs.
Or Bitwarden's Passwordless.dev which is free for 10,000 users. The pro plan is $0.05 per user/month for the first 10,000 users and $0.01/user for users above 10,000.
Hey there! We expect to add more pricing details to the page in the coming weeks. The ambiguity is just because the products are currently in early beta.
Hey there. The Passage products are in early beta, so some of the details are being worked out. We expect to be able to add more specific pricing info in the coming weeks. Stay tuned!
This isn’t free?! Feels like 1Password is the main beneficiary in this relationship.
Consider: 1pass owns the auth, and who knows how they’ll wield that power (need to deliver a return on their massive $920m VC round!), the burden to educate users about “passkeys” is on web developers, not 1pass, and guess who gets stuck providing customer support when a passkey doesn’t work?
I’m a 1Password user and constantly run into edge-case bugs (for example there’s a UI flow that suggests a new password to use during google’s password reset, then doesn’t save the password - really!).
I get that they don’t have the full support of OS developers, so there will be edge cases. But these problems keep e.g. my parents from sticking with password managers. It’s just easier for them to keep a password journal. At least they don’t reuse passwords in the event of a leak.
After 1Password moved to subscription only, I’m never recommending them to anyone. How does it make sense to surrender your authentication credentials to a subscription service?
> How does it make sense to surrender your authentication credentials to a subscription service?
You're paying for cloud sync. 1Password don't get your credentials, they're encrypted client-side, and 1Password doesn't see your master password.
If you don't want to pay for the service, that's fine, there are plenty of local-only alternatives for which you can presumably build your own syncing solution, but it's disingenuous to say that it doesn't "make sense" when you misrepresent a product which a lot of people obviously feel is worth the price - including me.
Looking at the site, I may have worded my reply too strongly since you can still export your passwords even if your subscription ends. But nonetheless, 1Password used to make a great product where I could choose to sync my password to any cloud service of my choice without subscription.
They discontinued their standalone product because they knew they could make a lot more money by selling subscriptions. That’s their prerogative, but it’s also mine to point potential customers to Bitwarden, which can be used free of charge, can be self-hosted, and is open source.
Interesting concept. I like the idea of being able to easily leverage Biometrics for auth, but am reluctant to be tied to a third-party to support authentication. I'm sure it could be switched out quickly for something else, but that could be a shock to less tech savvy etc. users.
Disclosure, I work for FusionAuth, an auth provider.
There are other options out there that let you self host WebAuthn. I was on a python podcast[0] and found some python libraries. It's public key management and a JS API that you need to carefully implement, not rocket science.
I've written elsewhere about the tradeoffs of using an in-house auth solution vs an outsource auth provider[1], so I won't say more about that here.
Apple’s push is enough to convince me that this will be a default soon. Adoption has been slow because it takes some effort and the payoff isn’t immediately obvious. This new service from 1Password might start to change that. I expect others will follow with similar ideas.
I think once the account recovery problems, aka "oh no, dropped my phone in a pond, now I can't login", are resolved, it'll take off.
I've used it for some sites and it is pretty cool to not have to remember anything. Fingerprint readers are a bit touchy, but seem to be getting better.
I also think that it is far far easier than a password manager, the current go-to secure solution today.
> I think once the account recovery problems, aka "oh no, dropped my phone in a pond, now I can't login", are resolved, it'll take off.
The same recovery methods used for passwords also work for passkeys, e.g. as sending a link in an email or text message to create a new passkey.
In the "oh no, dropped my phone in a pond" scenario, my passkeys are already synced across devices via the cloud, so I would not have to create new passkeys.
> The same recovery methods used for passwords also work for passkeys, e.g. as sending a link in an email or text message to create a new passkey.
How does a site have your email address if you registered and logged in with a passkey? They only have that if you gave it to them. Maybe there's an Apple specific extension, but the WebAuthn spec (which is what passkeys are based on) doesn't require any contact info to be provided.
>In the "oh no, dropped my phone in a pond" scenario, my passkeys are already synced across devices via the cloud, so I would not have to create new passkeys.
That is not true for every set of passkeys/WebAuthn credentials, only for people using certain providers like Apple. But yes, if you have that set up, that handles it.
> but the WebAuthn spec (which is what passkeys are based on) doesn't require any contact info to be provided.
This isn't an issue with the spec, it's an issue with account creation, account information, and recovery flow on part of the operators of the website. Those operators are already familiar with this dance. They will use information that is required for registration in order to provide account recovery, and yes, this will include an optional, or possibly mandatory, email address/phone number/whatever to do so.
Existing registration flows that already work and ask for this information will barely need to change, and most users of Passkeys will be adding them to these already existing flows, so it's practically a non-issue. Or at least no more than it already was.
Big tech is salivating over the vendor lock this will enable, so there will be a big push for it. I’m just hoping password managers will allow us to store the key material in them so that cross-platform can work.
> Big tech is salivating over the vendor lock this will enable…
This enables vendor lock-in as much as passwords do. That is to say, not at all.
Example: Chrome supports passkeys, but uses a Chrome-only passkey store instead of the OS one. So I have one passkey for Chrome, and another for macOS/iOS.
> That's literally describing vendor lock in meaning you need manage multiple vendor locked passkeys for the same service which is ridiculous.
It makes more sense if you don't think of passkeys as passwords and more like "SSH keys for muggles". Passkeys are definitely not vendor-locked — they're a standard, and so Google Account passkeys work with anything that supports passkeys.
If you're unhappy that Chrome doesn't leverage the macOS passkey store, that's completely valid and you can point your frustration in their direction. In practice, taking 30 seconds to create an additional passkey wasn't onorous.
When 1Password supports passkeys, I'll generate another passkey for it and then use that globally.
> In practice, taking 30 seconds to create an additional passkey wasn't onorous.
Almost every site requires an account these days. I am quite fed up with the number of accounts I need to have, in general. Now you are telling me I have to go through a process of creating passkeys for each site for each browser/mobile os? 30 seconds times 100 is pretty onerous.
Oh, you mean you reuse the same passkey for all services that require accounts? I'm sorry to tell you, that's impossible. You didn't understand how this works.
> If the user does not have their old device or a security key, then the RP can treat sign-in from the new device (which might be from a different vendor) as a normal account recovery situation and take appropriate steps to get the user signed in.
> I'd argue within 5-ish years you'll start encountering people who have never used a username + password combo at all.
But can one register apple/google account without password with fresh phone on setup screen? What would happen if that phone would die? Apple often asks for icloud password in various places (which really surprises me, I mean it's Apple app on Apple device which logged in, why ask me about it).
It still looks to me like master password (which is google/icloud password) and other accounts are accessible with this master password. Just less friction: no need to copy random passwords around.
I went to check it out for interest in a personal project, and potentially even for my company's identity stack. Lack of pricing makes building on it uncomfortable though. <1000 MAUs: free. 1000+ MAUs: contact us. Enterprise: contact us for bulk pricing.
I need to know what kind of pricing ballpark we are talking about, and I'm not going to deal with some lame sales engagement to find out.
> Say I initially created an account with my computer. If a passkey is tied to a device, what do I do when I want to login with my phone?
You create an additional passkey for that device, or use a password/passkey manager that syncs your passkeys across devices.
(Note: I've actually done the former with my Google account. I'm waiting for passkey support in 1Password to test the latter scenario, but believe this is how it'll work.)
I do not believe this is true. Passkey is only a 1 user, 1 key system. This means that to login on a second device, the 1. key must be exported from the first device, 2. encrypted, and 3. transferred to the second device. Each device needs a copy of the private key.
You can add multiple passkeys on your Google account today. If a website is dumb enough that they only allow a single passkey per account, they have misunderstood passkeys profoundly.
Google != passkeys. Google may allow multiple keys, but that is outside of what FIDO specifies for passkeys.
Here's a source saying that passkeys expect one and only one key:
"Passkeys are designed to [...] allow the FIDO credential to roam across multiple devices. This [means that there's ] no need to repeat enrollment on each device [.]"
> If a website is dumb enough that they only allow a single passkey per account
TBH, I don't get how "normal" users without a roaming authenticator are going to do this.
Let's say I'm a layman person, nothing fancy, my password is my cat's birthday and I have a home desktop PC for gaming and laptop for my work. My desktop Windows computer can authenticate to a website, and is currently have it open and me logged in as "Alice". Now, I want to access the site from my Mac laptop. I go to the website, but I assume that to add an additional passkey to account "Alice" I must somehow authenticate.
I cannot do this on my laptop - only my desktop has a valid passkey so far. Let's assume it's not removable, and I don't have any fancy password manager that syncs across my computers - again, our Alice is completely non-technical. So we must either: a) somehow create a passkey on laptop, transfer its public key to desktop, register it there, then be able to log in from the laptop; or b) initialize login flow on laptop, but transfer the request to desktop, make it generate a valid authentication response, transfer it back to laptop, get logged in, then proceed with registering a new passkey. Are we going to have fun with waving laptop camera, or there's some BLE protocol, or we're ditching all our fancy cryptography-protected authenticators and going straight for access recovery aka "code over email/sms" lowest-common-denominator? (Which possibly implies spam^W contact methods are mandatory?)
All the demos I've found online seem to completely disregard this aspect, they just show me "start over" after I log in with the first device, and I haven't found any showcase of how can I enroll a second device. Their FAQs sorta imply I'm either all-Apple or all-Google or all-Microsoft person because all they say is that software providers will sync keys across devices. Which - I hope to be wrong - but I find unlikely.
> or we're ditching all our fancy cryptography-protected authenticators and going straight for access recovery aka "code over email/sms" lowest-common-denominator
Well yeah, every single online account you have uses email address as the account recovery mechanism. That isn't going to change.
> every single online account you have uses email address
No, not every single one. This is provably false.
I can prove it right on this very website, where we all have usernames, rather than email addresses. Going over my password manager, while the majority of records has an email address for a credential, a fair share of records has usernames instead.
That has nothing to do with anything. Think of this as a password, except the password is autogenerated and stored on the device itself. And you can have multiple passwords for the same account.
Who is allowed to add an additional password and how are they authenticated? The answer has to be simple enough for me to understand if I'm to consider using passkeys.
This is the primary issue with passkeys. When FusionAuth implemented WebAuthn/passkeys last year[0], we decided to have passkeys be a separate, additional login method, just like social sign-on or magic links, for this exact reason.
My understanding is that there is some work in the next version of WebAuthn[1] to allow sharing of passkeys across devices, addressing this user experience issue.
Does there need to be work on webauthn for it? (maybe some wording sugggestions around "resident keys" which I think are meant to be persistent and within a singleTPM or such, but no technical constraints beyond that afaik).
My understanding was passkeys was just Apple Marketing(tm) around their implementation and integrating it with iCloud/keychain?
Looks like they have had a section on key loss since at least webauthn 2[0], and explicitly rule out backing up keys. The suggested answer is "use multiple devices" which doesn't work great with platform authenticators (which are tied to a device). From the spec:
> This specification defines no protocol for backing up credential private keys, or for sharing them between authenticators. In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering multiple credentials for the same user. For example, a user might register platform credentials on frequently used client devices, and one or more roaming credentials for use as backup and with new or rarely used client devices.
So I guess you are right, it is on the vendors to handle backing up the keys from devices.
So am I the only one who's noticed that average non-tech users are absolutely horrible with managing passwords and passkeys would be a huge improvement over reusing "ddccbbaa!" across every login they have?
Everyone I know about 40 years old use <name><year in range 1960-2000><special character to pass check, usually exclamation point> as the formula for their passwords. Capital letters are the first letter of the name, of course.
The only exceptions are passwords generated for them with change password pages that are more than two clicks away.
I applaud passkeys, despite their obvious problems surrounding their centralisation in Apple's or Google's account. The probability of your account being banned is much lower than the probability of Steven1971! getting guessed (or leaked in any hack).
My personal preference is for it not to be tied to a device that can be lost, stolen, broken. That way I don't need multiple backup devices to login to one service or multiple passkeys for the same service.
My password manager generates unique strong passwords, is offline and no big multinational advertising company controls it. The only thing I need to worry about is individual company's security practices. Passkeys offer me nothing of an improvement over this and only more obstacles and hoops to jump through.
Until I can use passkeys like I can my open source offline password manager I'm not using them.
Hey there. Passage products are in early beta, so some of the details are being worked out. We expect more specifics to be added to the pricing page in the coming weeks. Stay tuned!
The question I have with something like this is essentially “does it support SSO”? If I’m building software for end users, at least some subset of those users will want SSO.
I think you can think about passkeys as an equivalent to username + password. Supporting usernames + passwords on your site does not prevent you from also supporting SSO - it's just a auth mechanism you might use to grant access to an account, on top of SSO, Passkeys, email sign-up link, etc
I haven't looked deeply at what 1password offers, but I know that "does it support SSO" is a question other providers that started with passkeys only had to answer "yes" to relatively quickly. (Stytch comes to mind.)
The honest truth is that auth is the front door to your application. For most applications, you want a secure door, but also one that lets in as many people as possible. So social sign-on, federation/SSO, passkeys, magic links, and even username/passwords are all methods you want to support asap.
Curious about how Passkeys work at the website level. Passkeys strikes me as essentially an authentication method.
1. Signing up or logging in to a website today you'd expect your password to be hashed, stored, and protected. (I understand some are stored in plain text, but that isn't part of this question.) Assuming you want to change over, or create a new account, to passkeys, how do they store and protect that account?
2. Assuming you're still using a password manager for the foreseeable future, does it make sense to use passkeys to access that? IIRC, most password managers will use your password/passphrase (plus a lot of processing) to encrypt your vault. Even if you authenticate with passkeys and gain access, how do you decrypt your vault without your password/passphrase? It's clear that authentication does no good if your vault is already sitting on the black hat's desktop, as LastPass discovered, so a basis for encryption is still required. It appears to me that anything that requires an encrypted holding will still require passwords/passphrases.
Passkeys require the cloud to be ever present. Maybe on Venus where the clouds never go away, but on Earth all it takes is some rain, and suddenly you have clear skies.
I'll stick with keepassxc on my personal laptop, rather than put it in the hands of Google et al. and their sunset happy ways.
Atleast there's no segue into the blockchain and/or crypto as a 'benefit'. Small mercies and all that.
They also have 1Password Connect, which allows you to bridge an API into your data for automation workflows, Terraform, syncing with Kubernetes, HashiCorp Vault, etc.
Good to know, thanks. From looking around, current options are all tied to some proprietary tools, so not something interesting on Linux I suppose. Keepassxc implementing it would be nice.
As a CTO / dev, I'm sure I'm 1Password's target market for this. As a 1Password customer though, I'm painfully aware of how they treat their customers, so I'd rather use almost any other provider than 1Password.
That's not been my experience. I work for a small company and we have less than 100 1Password licenses, but I still have an account rep emailing me to set up a quarterly check-in. They've escalated technical questions to engineers for us and everything.
That's not to disclaim any problems you've had with them. Just saying, they've been solid for us.
I've been a 1Password customer for as long as they've existed - every major version release is worse than the last with features we rely on removed. I haven't dared try the latest electron version, but 1P7 managed to even kill keyboard navigation (try editing a login and see if you can generate a new password without moving your hands from the keyboard, or tab between fields to enter new information).
There is always a housing or real estate crisis in many parts of the world. So what?
And yet, people still need tools and services to purchase real estate, so it is good that they are built and promoted so people find them and can use them. How does hiding the existence of these tools help anyone?
I'm not sure why a tech service company should concern themselves with catering to the emotional whims of people "triggered" after seeing software tools that enable real estate deals. These people don't sound like a valuable market segment.
And these people should follow the advice of Tyler the creator [0]
Except what you might think is not a valuable market segment is growing steadily every year. Newer generations of consumers are increasingly becoming hyper aware of the situations around them. It's not necessarily a good idea to poke the bear if you can avoid it in the first place. I know all this sounds absurd and this is coming from a developer myself. The companies that are just developing tooling or protocols should not have to worry about silly things like this and focus on improving their platform or the quality of it.
I am personally aware of what people are facing as I moderate one of the biggest housing activist forums out there and even highly paid software engineers are suffering allegedly according to a very popular post. This is why I think companies like 1passwd should be wary with what kind of content they are promoting as it might come back to bite them in the future. As I am writing this, there is a petition that was started by a 13 year old girl to stop our housing minister from profiting off the real estate market as many people think it's a conflict of interest.
But yes mistakes do happen and sometimes you wonder how something could get passed or if something had any oversight at all. Take a look at with what's going on with the .zip domain that was released by Google domains, a portion of the infosec community is furious because their work got doubled this week, there are blocklists such as blocklist.zip passing around so that people can remediate actions that is happening in that space with the ongoing phishing campaigns or the potentials of it.
Part of this is letting go of your ego and realizing that you might have made a mistake and owning upto it and taking the action. In this case its a non-issue from 1passwd, because they are providing a tool to make authentication easier, but if companies keep promoting real estate content excessively in the future or a pattern forms it might become an issue to the point of losing subscribers.
However, I think this is an opportunity for companies like 1passwd to be involved in the future by appealing to the newer generations as it might net them subscribers in the long term as well as positive mindshare from the community.
If a company embodied the values you profess here, I would boycott them.
I'm part of a much bigger potential customer segment than resentful bitter people that get mad at real estate companies and real estate markets for existing.
Tech cos would do well to completely reject this mentality described above. Consider mine a counter argument to yours, we'll let the market decide.
I think actually it would be prudent to completely write off the type of (non) customer you describe here, and save oneself the trouble of dealing with them.
It's not triggering. It's not even "I'm offended" meaning of triggering that college students may use.
You've taken a term that was used by people to indicate a serious gutteral negative reaction and used it to mean something so watered down and vaguely possibly less than positive.
The Eddie Izzard joke of "awesome like a packet of hot dogs" but now it's "triggering like a real estate search site".
WebAuthn is an open standard that anyone can use to implement support for passkeys. That said, there is significant complexity around building a solution that can handle edge cases (devices that don't support passkeys), account recovery, etc. Not to mention the need to build out UI elements and back-end infrastructure.
Passage is a solution that handles all of this for developers, so they can implement with just a few lines of code instead of building from scratch.
I think a per-user blockchain with many user keys and a Merkle root representing current account state, synced individually to websites, would be a superior option to "passkeys". Websites would have to track a Merkle root on a per user basis.
User A: Merkle root AA
User B: Merkle root BB
Edit: A problem with passkeys is a one (key) to one (user) relationship, which means device keys must be retrievable and transferred to other devices via encryption. It also means that if any device has weak security, your whole account is vulnerable.
A multikey system would allow each device to have their own key, and an audit trail of what devices are logged into what services.
I currently have 5 passkeys linked to my Google account for 5 separate devices allowing me to login to Google on any of them with the passkey created for that device.
Edit: Google also shows when each passkey was last used for each device in an audit trail as you describe.
Google != passkeys. Google may allow multiple keys, but that is outside of what FIDO specifies for passkeys.
Here's a source saying that passkeys expect one and only one key:
"Passkeys are designed to [...] allow the FIDO credential to roam across multiple devices. This [means that there's] no need to repeat enrollment on each device [.]"
Not sure what you mean, I have passkeys enrolled from Apple, Windows and Android devices on my Google account and all trigger the same passkey prompt based on the platform implementation.
"Device-bound passkeys that do not support syncing are an option for organizations that require additional proof of provenance of a user’s passkeys".
Apple supports what sounds like roaming passkeys but device specific passkeys like you are wanting are already supported by the FIDO spec.
I think you're interpreting "no need" here as a if that's a hard requirement. Multiple FIDO hardware keys are already supported on many websites so the idea that the passkey standard mandates a 1:1 relationship doesn't make sense.
I feel with authentication, it's always those special cases that determine the usefulness and security, but when passkeys are discussed I never have seen a proper discussion a pros and cons and special cases. At least with regular passwords + 1password I kind'a understand what i am protected against and how to restore from disasters.