Passage by 1Password: Add passkey support to your app or website(blog.1password.com)
blog.1password.com
Passage by 1Password: Add passkey support to your app or website
https://blog.1password.com/passage-by-1password/
140 comments
Here's what I care about:
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. 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.
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"}`
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"}`
Sorry, I should've specified that it's impossible as the standard is written, not necessarily cryptographically impossible.
A scheme could definitely be devised to add authenticator "stubs", but I don't think it's possible right now.
Unless you're saying the above is already available in the spec.
A scheme could definitely be devised to add authenticator "stubs", but I don't think it's possible right now.
Unless you're saying the above is already available in the spec.
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.
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.
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.
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.
Yeah. It doesn’t make sense.
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.
How does Windows work?
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.
How does Windows work?
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.
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.
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.
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.
So this really isn't just an updated SSO implementation its an entirely different mechanism. I did not realize that.
I am a bit worried that the standards and ability to move around is not just part of the implantation right out the gate.
I do worry what this will mean for the more average user, this is a major shift in how things work.
I am a bit worried that the standards and ability to move around is not just part of the implantation right out the gate.
I do worry what this will mean for the more average user, this is a major shift in how things work.
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).
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.
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.
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.
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.
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.
Access to your icloud account will ask again your password to change things like subscription, credit cards and so on.
So it's not root access per se. But very high.
So it's not root access per se. But very high.
So we're back to using old fashioned keys to unlock our residential/digital space. The more things change.....
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.
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.
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.
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.
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.
Although I don’t know how the passkey support in 1Password will work, so I may be wrong on that.
Google considers that passkey with biometric authentication as multi-factor.
The device in your hand being the first factor, and the biometric value as the second factor.
Whether you consider that strong enough is a question for each of us individually I suppose!
https://android-developers.googleblog.com/2022/10/bringing-p...
The device in your hand being the first factor, and the biometric value as the second factor.
Whether you consider that strong enough is a question for each of us individually I suppose!
https://android-developers.googleblog.com/2022/10/bringing-p...
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...
Not for passwords, but it is for Passkeys
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.
Yeah, this "contact sales" threshold is pretty absurd. Presumably this is targeting B2C apps but who is going to bother with such a low number?
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.
[deleted]
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.
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.
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.
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.
0: https://realpython.com/podcasts/rpp/133/
1: https://news.ycombinator.com/item?id=35814332
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.
0: https://realpython.com/podcasts/rpp/133/
1: https://news.ycombinator.com/item?id=35814332
Does the crowd on HN expect passkey support to become more ubiquitous in the future, similar to Google OAuth today?
I’ve been surprised at how few sites seem to be adopting rapidly since there are UX gains, but I suppose Google had a fairly slow trajectory as well.
I’ve been surprised at how few sites seem to be adopting rapidly since there are UX gains, but I suppose Google had a fairly slow trajectory as well.
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.
Apple Pay but for passwords!
It will take over slowly, especially if they handle the edge cases well. Explaining passwords to people is a pain.
It will take over slowly, especially if they handle the edge cases well. Explaining passwords to people is a pain.
Apple Pay definitely hasn't taken over. I've heard of it, but never used it. I don't understand exactly what it does.
If explaining passwords to people is a pain, just wait until you try to explain a passkey.
If explaining passwords to people is a pain, just wait until you try to explain a passkey.
The passkey needs to work like faceID does on apps, quietly, quickly, and without anyone even really noticing.
Apple Pay is nice when a website supports it AND it works, but those two are sadly vanishingly rare.
Works well on Apple's store, however.
Apple Pay is nice when a website supports it AND it works, but those two are sadly vanishingly rare.
Works well on Apple's store, however.
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'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.
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.
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.
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.
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.
Passkeys are massively less flexible than passwords as it stands.
Passkeys are massively less flexible than passwords as it stands.
> 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.
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.
"The same passkey is never used with more than one site." from here https://developers.google.com/identity/passkeys
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.
"The same passkey is never used with more than one site." from here https://developers.google.com/identity/passkeys
Yes. To enable in Auth0, it's two checkboxes. For something more bespoke it's a few days of engineering time.
https://techcrunch.com/2023/05/03/google-now-lets-you-access...
https://passkeys.directory/
(managing passkey rollout at a fintech for customer iam)
https://techcrunch.com/2023/05/03/google-now-lets-you-access...
https://passkeys.directory/
(managing passkey rollout at a fintech for customer iam)
Once Apple and Google have pushed it out with their mobile devices, things will move along fast.
I'd argue within 5-ish years you'll start encountering people who have never used a username + password combo at all.
Passkeys are the future - but how they will work across ecosystems remains to be seen (without a subscription)
I'd argue within 5-ish years you'll start encountering people who have never used a username + password combo at all.
Passkeys are the future - but how they will work across ecosystems remains to be seen (without a subscription)
Passkey support has been on iOS since the release of iOS 16 -- so more than a half-year!
Google has actually had support for passkey for many many months now, but for whatever reason, waited to formally announce it until just recently.
Cross-platform is also already solved. See the FAQ directly from the FIDO Alliance: https://fidoalliance.org/passkeys/#faq
Google has actually had support for passkey for many many months now, but for whatever reason, waited to formally announce it until just recently.
Cross-platform is also already solved. See the FAQ directly from the FIDO Alliance: https://fidoalliance.org/passkeys/#faq
> 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.
LOL. This is not a serious answer.
LOL. This is not a serious answer.
> 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.
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.
[deleted]
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.
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?
> 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.)
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:
https://auth0.com/blog/our-take-on-passkeys/
"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
And that's exactly my point.
https://auth0.com/blog/our-take-on-passkeys/
"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
And that's exactly my point.
You create another passkey on your phone, and the site accepts both of them.
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.
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.
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.
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.
[deleted]
But what if I want to be able to use the same account, but I don't want other people to be able to use my account?
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.
Disclosure, I work for FusionAuth.
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.
0: https://fusionauth.io/docs/v1/tech/premium-features/webauthn...
1: https://www.w3.org/TR/webauthn-3/
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.
0: https://fusionauth.io/docs/v1/tech/premium-features/webauthn...
1: https://www.w3.org/TR/webauthn-3/
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?
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.
0: https://www.w3.org/TR/webauthn-2/#sctn-credential-loss-key-m...
> 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.
0: https://www.w3.org/TR/webauthn-2/#sctn-credential-loss-key-m...
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).
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.
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.
Interesting but I dislike the opaque pricing. Free for 1000 MAUs, beyond that it's "contact sales"
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
Correct! Your IdP would be where the passkeys would be supported. From there, auth is federated to other systems.
Disclosure, I work at an auth provider.
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.
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.
Passkeys are just the authentication mechanism. They have nothing to do with SSO.
You can use a passkey to log in to randomsite.com, OR you can use a passkey to log in to okta.com which then forwards your session to randomsite.com.
You can use a passkey to log in to randomsite.com, OR you can use a passkey to log in to okta.com which then forwards your session to randomsite.com.
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.
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.
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.
It's weird that they would launch this before the 1Password password manager actually supports PassKey.
Bitwarden also just launched a similar offering: https://passwordless.dev
Is this 1Password's first server-side product? I think of them only as having the consumer password agent (and related IT management stuff)
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.
[deleted]
I do not understand how the demo is different from just using webauthn normally.
The difference is 1Password not pocketing their share in the latter case.
How do you prevent someone from squatting on an account with your email address, and an initial passkey they control?
So passkeys are just private / public key authentication, right? So can it work with keepassxc for example?
https://github.com/keepassxreboot/keepassxc/pull/8825 (https://news.ycombinator.com/item?id=35859877) may interest you, although the PR is still open, so likely not something someone could use right now
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.
That's not to disclaim any problems you've had with them. Just saying, they've been solid for us.
Can you expand on that? We are 1Password customers and have one had good experience.
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).
Wouldn't it make more sense if they allowed us to store WebAuthn private keys in 1password, and then have a browser plugin that'd implement that?
Hello there! 1Password will soon support saving and using passkeys from the 1Password app. Keep an eye out for an announcement in the coming weeks.
That said, Passage is a completely different product-line that helps developers support passkeys in their own apps and websites.
That said, Passage is a completely different product-line that helps developers support passkeys in their own apps and websites.
That's great to hear! Looking forward to it.
appleaday1(1)
Surely passkey support is an open source kinda thing we would want to build on, rather than paying 1Password?
Hey there,
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.
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.
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.
> A problem with passkeys is a one (key) to one (user) relationship
That is untrue. It is a many-to-one relationship.
That is untrue. It is a many-to-one relationship.
I do not believe that is the case. Do you have a source showing that multiple keys for a single user on per a single service basis is supported?
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.
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:
https://auth0.com/blog/our-take-on-passkeys/
"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 [.]"
https://auth0.com/blog/our-take-on-passkeys/
"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.
"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.
How are websites going to implement multi-key user accounts?
This is all just left up to implementations?
This is all just left up to implementations?
[deleted]
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.