Passage by 1Password: Add passkey support to your app or website
blog.1password.com
blog.1password.com
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.
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.
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"}`
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 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).
1Password supporting them as a relative outsider (i.e. not Apple/Google/Microsoft) is a nice improvement to the system.
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.
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.
So it's not root access per se. But very high.
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.
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.
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.
Although I don’t know how the passkey support in 1Password will work, so I may be wrong on that.
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...
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.
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.
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.
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.
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.
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.
It will take over slowly, especially if they handle the edge cases well. Explaining passwords to people is a pain.
If explaining passwords to people is a pain, just wait until you try to explain a passkey.
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'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)
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
LOL. This is not a serious answer.
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.
https://techcrunch.com/2023/05/03/google-now-lets-you-access...
(managing passkey rollout at a fintech for customer iam)
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.
Passkeys are massively less flexible than passwords as it stands.
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.
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
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.
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.
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.
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.
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.
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...
My understanding was passkeys was just Apple Marketing(tm) around their implementation and integrating it with iCloud/keychain?
> 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...
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.
Well yeah, every single online account you have uses email address as the account recovery mechanism. That isn't going to change.
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.
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.)
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.
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 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.
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.
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.
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.
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.
That's not to disclaim any problems you've had with them. Just saying, they've been solid for us.
That said, Passage is a completely different product-line that helps developers support passkeys in their own apps and websites.
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.
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.
That is untrue. It is a many-to-one relationship.
Edit: Google also shows when each passkey was last used for each device in an audit trail as you describe.
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 [.]"
"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.
This is all just left up to implementations?