It's good to have options but... I hate passkeys. Here is why:
1. Passkeys are device dependent. That means you need to have more devices and be tied to your existing devices. For a lot of people, that means even tighter phone dependence.
2. Even if you don't use a phone to store your passkeys, they promote vendor lock-in, because you need to rely on Apple, Google, or some other cloud-keychain system to store your passkeys.
Tech companies love passkeys, not because it makes your life better, but because it entrenches people further into relying on their systems. People will love passkeys because it appears simple and makes passwords a thing of the past.
But there's a tradeoff: more dependence on advanced technology are major tech corps. Let me ask you this: suppose you want to go phone-free and big-tech company free. Or you lose your phone and computer overseas. If you only use a passkey, then you'll have to grovel back to Apple or Google to log into your fastmail. Tech corps love that.
This is just one step to make people tied to big tech, and so it seems harmless. But it is part of an overall procedure to integrate us so tightly (free Google docs, log in with Google/Apple/X is another of many), so that we can't function on our own any more, or choose any company we like any more.
I still haven't reckoned the security implications, but Bitwarden supports passkeys, you can mostly use them the same way as you do a username/password across devices.
That still means dependence on some software product to log-in to basic services. With a password, I don't need to use a software product.
What if I don't want to pay for Bitwarden, or buy a smartphone, or tie my log-ins to my computer? What happens when the WebAuthn standard evolves and only the big-tech companies have solutions for storing passkeys because little software vendors or open-source vendors don't support the standard as well?
What happens when password-based login is phased out because passkeys are SO much simpler...assuming the user acquiesces and signs up for a big tech company's service? Who will be able to choose then?
I like passkeys. I'm not able to be all in on them yet but I feel like they simplify my life. I have hardware keys and register all of them with sites that support them. Bitwarden for everything else.
I don't feel like that makes me dependant on any of the big tech cos, but I do recognize everyone won't be able to pull off such a setup.
My argument was never that tech-savvy individuals won't find a way not to be dependent on big tech. There will always be a few people from the previous era who find a way to be more independent. My argument was only about the majority, about the future of society, and how eventually people won't have much of a choice, because there will be future steps by big tech to integrate more and more people.
I share your concerns, but you can store passkeys in the password manager of your choice, which syncs them across all your devices. As long as device attestation remains optional (and that's a big if), passkeys are strictly better than passwords.
Until the mandatory requirement (SHOULD-level at the minimum) for compliant password^W passkey managers is that passkeys' keypairs must be user-accessible - it's just a pinky swear from corporate that "it's going to work" while they're effectively holding your credentials hostage. I can promise you that it's NOT really going to work as soon as you'll need to do something just slightly outside of the happiest path. Like logging in from an untrusted machine in a Internet Cafe.
Exceptions for hardware-based solutions (like Yubikey) are acceptable and reasonable, as long as there is a ban on implementing any attestation anti-features.
Current spec and official demo sites doesn't even require or suggest that multiple Passkeys must be a thing. A significant number of actual real-world implementations are extremely user-hostile (check BestBuy for an example).
How is that any different from a password manager? Instead of being beholden to LastPass I'm beholden to the manufacturer of my laptop and my phone, until I get a new one at which point I just transfer the passkey over to that. I don't see the problem.
Use a 3rd party password manager with Passkey support like 1Password or Bitwarden for the most broad cross-platform support. You can't currently export and import passkeys between different implementations, so if you wanted to switch from Apple iCloud to Google, for example, then you'd have to go to each site and register a new passkey on each of them with your new password manager.
The FIDO alliance as supposedly working on a way to securely transfer passkeys between different password managers, but that's not here yet.
I recently had to use somebody else's computer to access my Google Mail account.
I was able to login securely, without typing my password into the untrusted computer, by selecting "Try another way", then "Use your passkey". I scanned the QR code with my phone's Camera app, I tapped "Use passkey", my phone used Face ID to verify it was me, and then attested to Google that it was me logging in via an automatically-established Bluetooth connection between my phone and the browser.
It was GREAT, and way better than typing in my password (no worry about keyloggers) and having to do a 2FA dance.
You are selectively ignoring the features of passkeys that don't fit your chosen conclusion. Yes of course passkeys come with some lock-in risk. Most technologies do. But compared to the status quo they give us new freedoms and less lock-in.
We don't live in world of memorable passwords ("abc123") or post-it notes or even password managers. That world has long been replaced by a dependence on SIM cards, big tech OTP apps, proprietary banking apps and worst of all social logins. And all of it is tied to oppressive mobile platforms.
You portray passkeys as another brick in the big tech lock-in wall. I totally disagree with that. Anything that frees us from dependence on mobile platforms and phone numbers is a net win.
It is annoying that passkeys are by definition discoverable passkeys, which make older Yubikeys useless because they can only hold like 25 passkeys or so. WebAuthn non-discoverable keys are so much better as just a second factor of authentication (after putting in your username/email for key lookup).
Your two arguments are actually arguments against using any password/passkey manager at all. So it seems like you are actually arguing that people should not be using password managers, which is pretty bad advice given how we've seen how that turns out for the world: most people using weak, reused passwords, falling prey to phishing attacks, and all of the above resulting in tons of compromised user accounts.
Passwords are not device dependent. Save for some user-hostile enterprise environments that try to implement passwords without letting user "see" them, you can store passwords on any medium, with as many copies as you deem necessary, and use them however you want.
Passwords are vendor independent. They're just a shared secret piece of information, there is nothing whatsoever that can even theoretically tie them to any provider. My "hunter2" secret is not and cannot be held hostage by Apple or Google or 1Password or anyone else.
Passkeys in their current state lack both of those properties. If the Passkey committee would've explicitly made it in the spec that: 1) any compliant non-HSM-backed Passkeys SHOULD be exportable in a standardized text-based container format; 2) any compliant Passkey implementation MUST be capable of importing passkeys in the same standardized container format; 3) any compliant Passkey accepting service MUST provide means to authenticate via a QR code, Bluetooth connection, or, in absence of either, MUST provide a way for a manual fido:/ URI input as a last-resort measure; and lastly 4) there must be no way to distinguish between a hardware and software based Passkey - all those issues would be solved. But that's not happening.
Once your next step is not necessarily a password, having just the single username input up front becomes necessary to avoid confusion. To support non-resident passkeys (passkeys on devices that can't store the username with the cryptographic key), we need to be able to prompt for the username, then offer them their passkeys to log in.
This does have the effect of making it slightly less ergonomic for just username/password input, but we did everything we could to mitigate this:
> First, I can’t do username <tab> password <enter>.
True, but we made it so you can do username <enter> password <enter>.
> Secondly, with auto fill, it requires two clicks to sign in.
True, but the way we've set it up should ensure the autofill did both immediately, so you don't have to activate your password manager twice.
The flip side is if you do use passkeys, it can be much quicker than any username/password input. For example, 1Password will show you your list of accounts as soon as the login page loads, and it's just one click to sign in.
Sorry to corner you here on unrelated topic, but I will take a chance on asking…
Why can I not pre pay my FastMail account? I have a three year subscription which ends in another 14 months. The UI indicates I will be auto renewed two days before my subscription ends. That is not a comforting margin for error in the event there is a billing issue for something as vital as email.
I can understand you do not want to let people pre-purchase infinite time, but you already offer the three year plan. Let me top it off well in advance of the expiration date, so I have ample time to resolve issues if they occur. Let me subscribe to an annual renewal, always maintaining a two year balance.
Coincidentally, checking my account now, I see my credit card on file is expired.
Thanks for the detailed response, I wasn’t expecting an official reply. I can understand the reasoning.
The mitigation is good, though I did like pressing tab and having @fastmail.com autocomplete, which doesn’t happen now unless the input box loses focus (so enter alone doesn’t work). However I’ll just get used to pressing <tab> <enter>. I am nitpicking. The implementation is excellent (particularly onboarding).
Most sites that implement it this way do indeed have something similar to what you describe for Microsoft.
e.g. many sites these days allow for "magic link" login where you just enter your email and they send a link to login. There is no password to login with.
The problem from there is that users are dumb. If you have multiple login methods, many users will not remember which method they used to login last time. So if you show them (by default) a username/password form, they will try to "remember" a password that might not exist if they used any method that was not username/password. Much better for that user if you make them enter their email, you do a quick lookup in the backend to determine which method they used to login last time, then you proceed with that method in the frontend.
Yeah, I used to consider that a PITA for the same reason. Now, 1password at least can autofill those most of the time. Sure, it takes a bit longer, but it's only annoying at this point since I don't have to click several times anymore.
I like and use fastmail but I'm yet to hear any sort of convincing argument why passkeys are better for me in any way, shape or form than passwords (with a password manager)?
The announcement post from Fastmail does a good job at listing the advantages of Passkeys over passwords: replay resistant, database-leak resistant and fishing proof.
- database-leak resistant: if i'm understanding this correctly, this means a leaked database on the Fastmail side wouldn't compromise your Fastmail account? It's hard for me to imagine a situation where a compromise is serious enough that passwords are leaked, but nothing else?
- phishing proof: don't password managers already do this?
Password managers are phishing resistant. The browser plugin will not offer to autocomplete passwords on an identical-looking punycode domain.
A sufficiently long, randomly generated password is also database-leak resistant. Good luck brute-forcing a 128-bit random string, hashed with scrypt or whatever.
So the only significant advantage is replay resistance. Which might or might not be a big deal, but let's not overplay the advantages.
They're not mutually authenticating, they're origin-bound (making them non-forwardable on the remote side) and channel-bound (meaning the authenticating action is guaranteed to be for the same device as the user action).
However, there's no particular reason a FIDO key couldn't sign a login statement to a phishing site---it's just that statement wouldn't then be usable as a valid credential for the true site, regardless of if the signature from the FIDO key was valid or not.
Passkeys are basically a protocol upgrade for password managers. A limitation is that you have to use a password manager, but the protocol is more secure.
If you have a password manager you like, maybe it’s for the best?
Maybe use more than one password manager, just in case.
I have been using a password manager for 16 years, and as much as I always want to use autofill, there are still situations where I need to either copy/paste the password, or reveal the password and type it in.
I don’t think we’re at a point where I can 100% trust that the password manager will be able to handle every situation I run into from now until forever, and that’s what passkeys are asking for. I don’t see it.
Besides what others have said, I think non-tech savvy users get a huge benefit from passkeys. Imagine the people that aren’t already using password managers (probably most people). With passkeys there’s no way they can reuse or leak a password. Passkeys are quite easy to use.
So far, non-tech-savvyy I know in real life who have interacted with passkeys have been more confused than helped by how they were implemented. Most likely as a result of blindly clicking yes/ok/accept/etc when asked to migrate to passkeys (e.g. on Google).
Long time Fastmail customer. Not sure why all the hate on here. More options is never a bad thing and great to see you're still making product improvements.
Seeing as Fastmail peeps are reading this, can we _please_ have a native android app. The function I really need is to be able to rely on quickly showing emailed pdf tickets knowing the app won't try and reload and stall waiting on data connection. I try and load in advance but generally switching back results in a page reload. This is my far my greatest annoyance.
- a password, which still can be brute forced if done authentication service doesn’t play nice
- resets still need to work somehow
The only good thing about it is that you will know which auth device is used for a session and that you don’t need 2fa afaict. Unfortunately most information about sessions and attempts isn’t communicated by 99% of the services
Could someone point to a description of how the passkey protocol actually works? I mean for example at the level of, here's how you would implement it using a crypto library in Python or some other language.
Readit News
1. Passkeys are device dependent. That means you need to have more devices and be tied to your existing devices. For a lot of people, that means even tighter phone dependence.
2. Even if you don't use a phone to store your passkeys, they promote vendor lock-in, because you need to rely on Apple, Google, or some other cloud-keychain system to store your passkeys.
Tech companies love passkeys, not because it makes your life better, but because it entrenches people further into relying on their systems. People will love passkeys because it appears simple and makes passwords a thing of the past.
But there's a tradeoff: more dependence on advanced technology are major tech corps. Let me ask you this: suppose you want to go phone-free and big-tech company free. Or you lose your phone and computer overseas. If you only use a passkey, then you'll have to grovel back to Apple or Google to log into your fastmail. Tech corps love that.
This is just one step to make people tied to big tech, and so it seems harmless. But it is part of an overall procedure to integrate us so tightly (free Google docs, log in with Google/Apple/X is another of many), so that we can't function on our own any more, or choose any company we like any more.
What if I don't want to pay for Bitwarden, or buy a smartphone, or tie my log-ins to my computer? What happens when the WebAuthn standard evolves and only the big-tech companies have solutions for storing passkeys because little software vendors or open-source vendors don't support the standard as well?
What happens when password-based login is phased out because passkeys are SO much simpler...assuming the user acquiesces and signs up for a big tech company's service? Who will be able to choose then?
I don't feel like that makes me dependant on any of the big tech cos, but I do recognize everyone won't be able to pull off such a setup.
Exceptions for hardware-based solutions (like Yubikey) are acceptable and reasonable, as long as there is a ban on implementing any attestation anti-features.
Current spec and official demo sites doesn't even require or suggest that multiple Passkeys must be a thing. A significant number of actual real-world implementations are extremely user-hostile (check BestBuy for an example).
The FIDO alliance as supposedly working on a way to securely transfer passkeys between different password managers, but that's not here yet.
I recently had to use somebody else's computer to access my Google Mail account.
I was able to login securely, without typing my password into the untrusted computer, by selecting "Try another way", then "Use your passkey". I scanned the QR code with my phone's Camera app, I tapped "Use passkey", my phone used Face ID to verify it was me, and then attested to Google that it was me logging in via an automatically-established Bluetooth connection between my phone and the browser.
It was GREAT, and way better than typing in my password (no worry about keyloggers) and having to do a 2FA dance.
We don't live in world of memorable passwords ("abc123") or post-it notes or even password managers. That world has long been replaced by a dependence on SIM cards, big tech OTP apps, proprietary banking apps and worst of all social logins. And all of it is tied to oppressive mobile platforms.
You portray passkeys as another brick in the big tech lock-in wall. I totally disagree with that. Anything that frees us from dependence on mobile platforms and phone numbers is a net win.
Deleted Comment
Passwords are not device dependent. Save for some user-hostile enterprise environments that try to implement passwords without letting user "see" them, you can store passwords on any medium, with as many copies as you deem necessary, and use them however you want.
Passwords are vendor independent. They're just a shared secret piece of information, there is nothing whatsoever that can even theoretically tie them to any provider. My "hunter2" secret is not and cannot be held hostage by Apple or Google or 1Password or anyone else.
Passkeys in their current state lack both of those properties. If the Passkey committee would've explicitly made it in the spec that: 1) any compliant non-HSM-backed Passkeys SHOULD be exportable in a standardized text-based container format; 2) any compliant Passkey implementation MUST be capable of importing passkeys in the same standardized container format; 3) any compliant Passkey accepting service MUST provide means to authenticate via a QR code, Bluetooth connection, or, in absence of either, MUST provide a way for a manual fido:/ URI input as a last-resort measure; and lastly 4) there must be no way to distinguish between a hardware and software based Passkey - all those issues would be solved. But that's not happening.
In my view, it is a backwards step. First, I can’t do username <tab> password <enter>. Secondly, with auto fill, it requires two clicks to sign in.
I can understand it for Microsoft login where push notification login is an option. Otherwise, I’m not sure it is a great design pattern.
I would prefer a regular sign in page, with a button to sign in with passkey (which also does not require username input).
Once your next step is not necessarily a password, having just the single username input up front becomes necessary to avoid confusion. To support non-resident passkeys (passkeys on devices that can't store the username with the cryptographic key), we need to be able to prompt for the username, then offer them their passkeys to log in.
This does have the effect of making it slightly less ergonomic for just username/password input, but we did everything we could to mitigate this:
> First, I can’t do username <tab> password <enter>.
True, but we made it so you can do username <enter> password <enter>.
> Secondly, with auto fill, it requires two clicks to sign in.
True, but the way we've set it up should ensure the autofill did both immediately, so you don't have to activate your password manager twice.
The flip side is if you do use passkeys, it can be much quicker than any username/password input. For example, 1Password will show you your list of accounts as soon as the login page loads, and it's just one click to sign in.
Why can I not pre pay my FastMail account? I have a three year subscription which ends in another 14 months. The UI indicates I will be auto renewed two days before my subscription ends. That is not a comforting margin for error in the event there is a billing issue for something as vital as email.
I can understand you do not want to let people pre-purchase infinite time, but you already offer the three year plan. Let me top it off well in advance of the expiration date, so I have ample time to resolve issues if they occur. Let me subscribe to an annual renewal, always maintaining a two year balance.
Coincidentally, checking my account now, I see my credit card on file is expired.
The mitigation is good, though I did like pressing tab and having @fastmail.com autocomplete, which doesn’t happen now unless the input box loses focus (so enter alone doesn’t work). However I’ll just get used to pressing <tab> <enter>. I am nitpicking. The implementation is excellent (particularly onboarding).
Why not remember how a user logs in with localstorage?
If the user is configured to use SSO it can redirect to the identity provider. If it’s password auth it can ask for the password, etc.
e.g. many sites these days allow for "magic link" login where you just enter your email and they send a link to login. There is no password to login with.
The problem from there is that users are dumb. If you have multiple login methods, many users will not remember which method they used to login last time. So if you show them (by default) a username/password form, they will try to "remember" a password that might not exist if they used any method that was not username/password. Much better for that user if you make them enter their email, you do a quick lookup in the backend to determine which method they used to login last time, then you proceed with that method in the frontend.
Then there's the absolute dogshit of Bitwarden with SSO.
- replay resistant: doesn't ssl already ensure this?
- database-leak resistant: if i'm understanding this correctly, this means a leaked database on the Fastmail side wouldn't compromise your Fastmail account? It's hard for me to imagine a situation where a compromise is serious enough that passwords are leaked, but nothing else?
- phishing proof: don't password managers already do this?
A sufficiently long, randomly generated password is also database-leak resistant. Good luck brute-forcing a 128-bit random string, hashed with scrypt or whatever.
So the only significant advantage is replay resistance. Which might or might not be a big deal, but let's not overplay the advantages.
However, there's no particular reason a FIDO key couldn't sign a login statement to a phishing site---it's just that statement wouldn't then be usable as a valid credential for the true site, regardless of if the signature from the FIDO key was valid or not.
If you have a password manager you like, maybe it’s for the best?
Maybe use more than one password manager, just in case.
I don’t think we’re at a point where I can 100% trust that the password manager will be able to handle every situation I run into from now until forever, and that’s what passkeys are asking for. I don’t see it.
https://1password.com/product/passkeys
https://coderoasis.com/passkeys-will-replace-passwords/
https://developer.apple.com/videos/play/wwdc2022/10092/
https://arstechnica.com/information-technology/2023/05/passk...
TLDR Replaces secret strings with crypto primitives mostly automatically managed.
boosters have yet to address this particular elephant to doubters’ satisfaction
Seeing as Fastmail peeps are reading this, can we _please_ have a native android app. The function I really need is to be able to rely on quickly showing emailed pdf tickets knowing the app won't try and reload and stall waiting on data connection. I try and load in advance but generally switching back results in a page reload. This is my far my greatest annoyance.
- a password, which still can be brute forced if done authentication service doesn’t play nice
- resets still need to work somehow
The only good thing about it is that you will know which auth device is used for a session and that you don’t need 2fa afaict. Unfortunately most information about sessions and attempts isn’t communicated by 99% of the services
Deleted Comment
Is that true?