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?
> What if I don't want to pay for Bitwarden, or buy a smartphone, or tie my log-ins to my computer?
Even with passwords, you'd still need an application or a device for 2FA, unless you keep a pack of scratch cards with you everywhere. So unless you go out of the way to avoid 2FA or use scratch cards, I don't think this change anything from the status quo, only now you have one less thing to remember.
Well, 2FA was the first step in making devices more entrenched. Passkeys are just the next step. So, it's not exactly passkeys in isolation that is the problem, but the lock-in to technology (and big tech for most people), and passkeys being another discrete but significant step in the process.
On the contrary. Passkeys free us from complete dependence on mobile devices (and the telcos that distribute SIM cards) because passkeys can live on any number of desktop computers.
I said "passkeys free us from complete dependence on mobile devices". Complete dependence means not having other options. Passkeys give us other options - all of us, not just those of us who decide to use those options at any moment time.
If most people use their phone for login that's fine. Many people don't even have another device.
What we should push for is passkey export, migration and backup features. The most likely lever that big tech could use for lock-in is making it near impossible to move those passkeys out of their closed ecosystems.
I'm curious – if open standards such as 2FA (TOTP) and Passkeys are considered locked-in, what would be a solution in your mind for an authentication scheme that doesn't subject to the inherent problems of passwords (phishing, weak passwords, password reuse, database exposure, etc.) that fits your requirement?
If you don't currently depend on a software product for managing your passwords, then you are undoubtedly using weak or reused passwords everywhere. You absolutely should be using a password manager to store unique, complex passwords for everything, and then it's not really a big jump to upgrade to the superior user experience of Passkeys.
> With a password, I don't need to use a software product.
Formally, you still need a computing device with software that allows you to input and transmit the password, as well as any related challenges. (E.g. you may have hard time logging in on a device that doesn't have a physical or full virtual keyboard, like a TV - I literally had to grab a laptop and change password once because there was no character on the virtual keyboard that I needed to "type".)
While public-key cryptography isn't really doable on pen and paper, I don't see anything fundamentally wrong with requiring to perform some computations, as long as every step is documented and end-user fully and completely has access and owns their credentials. "You won't have a calculator^W computer" was the biggest lie from my childhood - everyone does, or can, including full control of ownership of the device if desired.
Of course, this is not the case with how Passkeys are currently implemented, as the corporate is extremely hostile against even idea of letting user to export "their" "own" keys.
> What if I don't want to pay for Bitwarden, or buy a smartphone, or tie my log-ins to my computer?
Then you and the people you influence can continue to enjoy getting phished.
> 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?
For a bunch of companies/gov entities syncable passkeys aren’t secure enough. So they still need to use hardware-bound passkeys on e.g. yubikeys.
Try to read up about a subject next time before you let your imagination go wild and scare equally ignorant people away from more secure alternatives.
Your conspiracy theories even seem to push you to be against using password managers in general. I guess googling around for an offline one like KeePass that’s heavily recommended all around the internet was too hard?
KeePassXC even supports passkeys.
> Then you and the people you influence can continue to enjoy getting phished.
Yes, you are quite right (although I have never been phished). But the spirit of your answer is correct. But that was my point: there is no choice, except to be more tightly integrated into tech, which in my opinion is a horrible thing. Instead, we should lessen our dependence on technology so computer accounts aren't so important after all.
> Try to read up about a subject next time before you let your phantasy go wild and scare equally ignorant people away from more secure alternatives.
I am fully aware that passkeys are MORE secure. If you actually read my post, my argument was not TECHNOLOGICAL, but sociological: I argue merely that the tighter dependence on this technology is a bad thing sociologically, even if it is the RIGHT thing technologically.
My thesis is that passkeys are a symptom of tighter tech integration, perhaps an inevitable one. You are irate because passkeys are the better solution to a technical problem, but I nevertheless maintain that the existence of that technical problem itself is merely a side-effect of a much larger problem for society -- the dependence on a tightly-integrated vertical technology stack. So perhaps YOU should read into the subtelty of my argument before claiming that I am ignorant.
Are you intentionally ignoring the part where I provided reasons for why alternatives to the use of password managers by vendors that (supposedly) cause lock-in won’t go away?
It turns your fear into a hypothetical that you’re more than welcome to discuss but imo it’s disingenuous to frame it as the incredibly big problem you’re framing it as.
I remember when the whole OpenID/OAuth stuff started with a simple input field to login with your domain name. You could selfhost OpenID or delegate it from your homepage.
Today "distributed login" is "login with you preferred feudal lord".
If you don't want (or able) to use the 'app store app' what the options are there? What options would be when Google/Apple make a smartphone (and an app on it) a requirement, in the name of security?
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.
The short answer is our new billing platform (Paddle), which all new users are on and we're moving everyone to, doesn't support it. (We're moving from a home-grown billing solution to simplify our global tax compliance and give us support for more important things like billing in local currency.)
You can hack around it by converting to monthly billing (which will give you a credit), then immediately convert back to 3-year subscription (your credit will be used, so you'll only pay the difference). The end result is essentially identical to an early renewal.
I'd also like to reassure you that we don't immediately delete your account if renewal fails! We have a slow degradation process that gradually disables sending, then receiving, then finally access to anything other than billing if the account continues to go unpaid over several weeks. But our support team can (and do) delay this process if for whatever reason you are having difficulty making a payment and reach out to us.
I will definitely explore the monthly-conversion to re-subscribe. Thanks for the tip.
While not everyone would agree, it would be nice to see if the renewal attempt was made say a month in advance of the expiration date. My paranoid self thinks I am one long vacation + expired credit card away from losing my email.
As a rule, I try not to lean on the good graces of for profit companies. Having expectations for how long my account would be functional were I to miss a payment is a game I care not to play for vital services.
One of the benefits of Fastmail for me was the ability to prepay and be not bothered if the payment would be processed in time, works at all or whatever.
FM had a couple of stumbles for me in the last years (including shadow banning the account without any feedback at all), guess this would be the last nail for it.
Fastmail user here: you get a reminder a week or so ahead of time, and even if the payment doesn't go through, they don't shut down your account instantly. You get a few reminders. I even emailed support to ask for some time to settle my credit card and were okay with extending it.
IIRC, when my payment lapsed due to an expired card, I got plenty of time to fix the issue. In my case, the payment is taken from the card a whole month and a half before the invoice is generated (typically a different fiscal year, smh).
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).
Weeellll… you’d hope so, but some users may try to autofill a password with the right username, which will inadvertently fill the password too. And now your vendor (Quip or whomever) can potentially see your employee’s passwords. You have to trust them to throw away any password they see for someone from your org.
Oh yeah, I'm pretty sure Atlassian used to that, too. So I can understand the reason of "making it easier for users" invoked by people implementing this "two step" login.
But I'd argue this is a different issue than the one of giving out what kind of authentication a given login has.
1. It’s usually for institutions. If my email address is username@bigco.com, an attacker already knows that I use BigCo Inc’s internal SSO.
2. It’s avoids having users type (or autofill) their passwords, so if one of (for example) BigCo’s vendors is compromised, the attackers don’t learn the passwords of BigCo employees.
it would be a larger security issue if they didn’t redirect to the SSO provider and instead threw up a page asking for a password.
In many cases SSO means once you’re logged in then you don’t enter a password again for the session anyway- that only works with a redirect.
and your login might not even be a password anyway, or require more information than just a password (like MFA)- our solution for example takes into consideration what you’re logging in to, what device you have and where you are to determine the secrecy level of the thing you’re authenticating into.
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?
Re replay: No, because once someone has your password they can replay it as many times as they want. If you use your passkey on a compromised computer, the intercepted credentials can’t be reused.
Re DB leak: No, you the concern is reused passwords (or similar passwords) from a different site.
Re phishing: Yes, but one of the FUDs against passkeys is that they lock you in to a vendor. There is no more lockin than if store your passwords in a manager.
Do you manually check every site's SSL certificate before connecting? If not, how can you be sure there's not a MITM/Replay attack ongoing right now?
Very commonly user databases are the one being accessed for some reason, resulting in user data + salted passwords released.
How so? I can social engineer an employee to give me the password for a site they have in the password manager. I can't make them give me the passkey because they can't do that. It's not something you can paste in a chat.
From a security perspective, not being able “paste into chat” is a fundamental feature of passkeys. The whole point is to prevent a static secret which can easily be copied by an attacker, memorized, phished, or re-used across sites.
They sort of solve all these problems with a simpler implementation. But the disadvantage of passkeys is that you are dependent on a tech implementation ecosystem to use them, such as your phone, cloud keychain, etc. In practice, for a lot of people, that will mean tighter dependence on the smartphone, which is rather asinine as people should have the freedom to choose life without a big tech company providing for their needs.
Password managers such as Bitwarden and KeepassXC support creating and using Passkeys for accounts.
Presumably, you are already using a password manager at this point. Memorizing dozens of account passwords is not suitable for maintaining strong passwords.
Also, passwords still exist as a fall back if you need it, such as a situation you don’t have your device available. And not all accounts have to use passkeys.
Passkeys are effectively like ssh keys. Do ssh keys “lock you down” to specific devices? Sure they absolutely do unless you generate more keys or have some key management/sync workflow.
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.
> Password managers are phishing resistant. The browser plugin will not offer to autocomplete passwords on an identical-looking punycode domain.
True … but the reaction to this by the vast majority of users is to go "stupid password manager autofill not working again", and copy and paste their password out of the pw manager and paste it straight into the phishing site…
Well, IME this tends to happen on "let's be super secure and disable or otherwise break the login fields" sites, so I'm not sure these people will bother implementing actually useful security measures.
The phishing resistance isn't that straightforward in practice. It requires using browser extensions, which some people avoid for understandable reasons (poor security track record compared to everything else about password managers, and some of them just aren't very good). Many services use multiple domains (my bank has a .com, a .org, and several third-party vendor domains where you might be expected to enter your credentials), so many people who don't know how to update their password manager entries are probably in the habit of manually copying info into places where it doesn't autofill. And speaking of places where it doesn't autofill, the vast majority of mobile app developers seem to be unaware of things like autofill hints for login fields and apple-app-site-association.
The “database leak” argument is wider, though. It applies to password reuse (or systematic generation) and a leak from another site - which, may be stored in plaintext, or otherwise has a compromised login procedure that leaks passwords regardless of how it’s stored for validation.
You could say - and rightly so - that a person who reuses passwords invited whatever pwnage they get. But these people walk among us, do not use a password manager (often because not tech savvy enough), and passkeys are usable for those people.
Are password managers resistant to social engineering? You can copy & paste a password to a "support chat" from the manager. You can't do that with a passkey.
The password is only resistant if the one storing it is following best practices, which are NOT enforced and you really can't check for from the outside.
Well if we're talking about social engineering, I don't think it will be difficult to convince the support guy at most companies to disable passkeys on the target account altogether. :(
If you can engineer "the support guy" then you can do a lot more than disable one passkey.
I'm talking about engineering on the other side, the person who has the password and uses it to log in. You can't social engineer Miriam from Accounting to give their passkey, you can do it with a password.
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.
And what happens when I need to login to a device I don’t own, or don’t have/want my personal password manager on?
For example, I can’t (and won’t) load my personal password manager on my work computer, but there is 1 site I use my personal account for and had to login when I got a new work laptop a few months ago. Another example is I still bum TurboTax off my dad, since he gets the version where he can do a bunch of returns. To download my data from the bank I need to login on my dad’s computer, and I’m pretty sure even if it was mine the password manager isn’t going to work with TurboTax. Another example I had was needing to login to a site to download and print something on a computer in a business center at a hotel… not something I ever want to make a habit of, but I was in a bind. I could go on.
These things come up. I think the idea that a person will only ever need to login on their own computer is unrealistic. That might be the case 99.9% of the time, but not 100%. That 0.1% does need to be accounted for.
The usual workflow in practice when logging in to an “other” (hotel/work computer) computer is that you will be prompted to complete the authentication using a device with your passkeys (like your phone). The CTAP protocol they mentioned effectively turns your phone into a security key.
Using your phone with passkeys you scan the QR code shown by the website, then CTAP magic happens and you’re authenticated.
The great thing about this is that no reusable credentials are ever revealed to the dodgy computer.
"The other component of FIDO2, Client to Authenticator Protocol (CTAP), is complementary to WebAuthn. It enables an external authenticator, such as a security key or a mobile phone, to work with browsers that support WebAuthn, and also to serve as an authenticator to desktop applications and web services."
"CTAP2 and WebAuthn define an abstraction layer that creates an ecosystem for strongly authenticated credentials. Any interoperable client (such as a native app or browser) running on a given “client device” can use a standardized method to interact with any interoperable authenticator – which could mean a platform authenticator that is built into the client device or a roaming authenticator that is connected to the client device through USB, BLE, or NFC."
What happens is that you can’t do it. Maybe that’s a feature? Passkeys prevent you from logging in using a dodgy hotel computer. It’s protecting you from yourself. I’m not sure that’s appropriate for every account, but there are probably some accounts where it makes sense.
But I expect that businesses will probably like it better than consumers. They probably don’t want their employees logging in using dodgy hotel computers.
I will agree a hotel computer is dodgy. I did try and give it a once over in the OS, and checked for any obvious hardware keyloggers before doing anything. I also changed my password as soon as I was done. The alternative, if I remember correctly, was not making it home. With a password I can evaluate a situation and take a calculated risk to solve a problem. If I had passkeys, I would have been out of luck. Maybe I could have spent hours with some customer service agents to try and figure it out, hopefully before the flight left. If a passkey left someone stranded in another country, any idealistic views they might have would quickly be replaced by frustration and anger.
The other 2 examples I gave were not random public computers. They were either in my control or the control of trusted family members. I still want solutions to those situations that passkeys can’t answer (as far as I know).
There are similar issues with 2FA. I was traveling a few years back and broke my phone. It’s the only time I’ve ever broken a phone. All the info for my flight and my tickets were on the phone. I was able to get to an Apple Store and get a replacement. When I went to set it up I got a 2FA prompt (it was enabled for me without me opting in sometime earlier). The only reason I was actually able to set it up was because I brought an iPad with me, which was just dumb luck. I often only have my phone. On my most recent trip I created a recovery key, wrote it down, and put it in a money belt I wore everyday. I’m really not sure what other option I’d have to recover if my devices were broken/lost/stolen. Of course having the key on me carries its own risk. Yes it was hidden and on my person, but I also felt the need to add a bit of randomness to it, incase someone did somehow get it, somehow figured out what the paper with a bunch of seemingly random letters was, and tried to use it. But this isn’t a normal thing people do, they’re just going to be screwed if something happens. When security starts locking out the owner because it’s too unclear, too complex, or too device restrictive, it can hurt more than it helps.
I understand the issues with passwords and why people want to get rid of them, but this feels like a happy path solution that doesn’t account for edge cases, which is a problem. There will always be edge cases and they can’t be ignored for something as foundational as authentication.
I'm wary of not having backups, too. For passkeys to be more than a niche solution, I think the answer for travellers will be not having just your phone, in case it breaks. This is a hardware-based solution so there needs to be extra hardware.
I have a Yubikey on my keychain and usually have a tablet as well, but it will need to be something more common.
To speculate, credit cards have RFID chips in them now, so maybe there is a possibility to identify yourself well enough to buy a phone and restore backups?
Meanwhile, if you use Google and Apple password managers, they do have systems to get your password manager back on a new device. For Apple, it seems you need to remember your AppleID password and for Google, the pattern you use to unlock your phone.
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).
Doubters gonna doubt, it's shipping to hundreds of millions of people today, and their passkeys are backed up to either iCloud Keychain or Google Password Manager (depending on ecosystem). If you have a password manager, that's great! Most people do not, and this is easier for them.
Do you have examples of a few popular sites that support them?
I honestly don't know that I've seen one, unless the Apple / Google / Github / Gitlab "single sign on" links have all quietly switched to using passkeys under the hood (I thought they were all OAuth 2.0). Would be frustrating if so, because it wouldn't provide for custom / hardware implementations of the standard.
Seems like the overwhelming majority of the listed sites require you to already have an account, then go to a difficult-to-find URL on a settings page, enroll a passkey, and then you can login with the passkey. So granted, a handful of sites support it, but I have trouble believing the Google number. Maybe that's including people using their device to sign into Google itself?
Putting myself in the position of a typical user, passkeys haven't "replaced" passwords until I don't have a password for Home Depot or what have you. Otherwise there's still a password I have to write down or remember somewhere.
I'm not even here as a hater - I do like the idea of cryptographic authentication replacing passwords - but I'm just saying I've seen zero real world uptake of this so far.
Er, Google uses Passkeys and yes is an OAuth2/OIDC IdP for federated sign-in. I think you're missing the point though. I can still login to Google and Tailscale without ever typing a single password, trusting my url bar/eyes, sharing any secret material, etc.
always disappointed to hear “well it’s good because we already built it this way” as a deflection. you will, of course, do what you like but the flippant attitude is a showcase of why the boosters have failed to bring the doubters along. reassuring to hear that I can further offload my login security to an opaque fortune 500 of my “choice”
if, when challenged, one is unwilling to acknowledge the trade offs that indicates that they don’t understand them which suggests that they should not be trusted, in short.
forced passkeys are coming and I do not believe that is a good thing.
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.
How about they fix their long-standing security issues first. Particularly their DMARC is set to "p=none" which is essentially disabled at a time large providers are mandating properly functioning DMARC. Anyone can spoof email account of other Fastmail users (1). Their #1 job is email, yet Fastmail has poor security scores still in 2024 (2). MTA-STS should be enabled for any competent email host.
You cite a 5 year old post. We have improved things since then. You can't spoof other people through Fastmail any more, we verify permission to send as any address - either through your account owning the domain or alias - or by authenticating the specific address by confirming you can receive an email there.
If you have your own domain, you can set whatever DMARC policy you like on it. We'll DKIM sign your email for you if your domain is configured to use the keys we create for you, or do your own outbound email as you want.
Also the whole thing about STARTTLS is bogus - that site says "Unable to determine STARTTLS status" - too right. Because we're not listening on those ports. Because that's less secure that only allowing the SSL/TLS ports.
Today, many email services, including Fastmail, now disable plain text IMAP and POP logins entirely on ports 143 and 110, leaving encrypted connections on ports 993 and 995 as the only option. This makes sure all clients use encrypted SSL/TLS connections to protect sensitive data.
Your summary of the situation is not accurate. You can quibble about their choice of DMARC setting, but IMO it's the correct choice and best for customers. Your link says "Unable to determine STARTTLS status" -- which doesn't mean anything.
Fastmail has an excellent security track record.
(Disclosure -- I'm the founder, but I haven't worked there or had a financial relationship with Fastmail for many years.)
Tangential: Email spamming is out of control. My fucking hair salon wants me to add 2 factor authentication, and still sends me emails with an OTP. Login and guess what? They’ll send you moar emails to fucking confirm it’s me.
Guys, we are destroying the internet in the name of safety and security.
I want no GDPR bullshit, I want a simpler and risky experience. I am OK with losing my hair salon account and its history. Don’t care.
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.