Introducing passkey support to Fastmail
fastmail.com
fastmail.com
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?
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.
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 do remind you that all money transactions are done electronically. You’d have us go back to checks?
I would dismantle big tech first. The banking systems would still exist. But I don't think cheques were too bad.
Not using software doesn't undoubtedly mean weak reused passwords. You can easily have strong unique passwords without 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.
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.
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.
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.
https://github.com/dani-garcia/vaultwarden
I agree with your point though
Today "distributed login" is "login with you preferred feudal lord".
For now. Remember Hashicorp?
> but you have options
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 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.
It’s built-in to how to passkeys work.
https://support.apple.com/guide/iphone/use-passkeys-to-sign-...
https://learn.microsoft.com/en-us/entra/identity/authenticat...
https://support.google.com/chrome/answer/13168025
https://support.apple.com/guide/mac-help/create-a-passkey-mc...
And I don’t think I saw it in a spec as an actual requirement for compliant implementations.
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.
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.
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.
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.
This is ridiculous.
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.
Sad.
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.
If you type in bob@sso.com for your SSO account, the password field will clearly be a throwaway, and you'll be redirected to your IDP.
Being presented with a "wrong password" error would mean the account is local.
But I'd argue this is a different issue than the one of giving out what kind of authentication a given login has.
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.
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.
Can’t do that without control.
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?
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.
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.
this is a fundamental and un-addressable problem with passkeys as currently implemented
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.
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.
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…
This is a huge benefit. There’s no other way to put it.
From the admin side this also means significantly simpler database design
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.
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.
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.
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.
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.
For that there's CTAP2/WebAuthn: https://fidoalliance.org/fido2-2/fido2-web-authentication-we...
"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."
https://techcommunity.microsoft.com/t5/security-compliance-a...
"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."
And for the multiple person needing access to an account thing, password managers that store the passkeys allow sharing: https://support.apple.com/guide/iphone/share-passkeys-passwo...
Or alternatively, you just add a passkey for each of you in your own password manager to the accounts that you both need access to.
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.
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 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.
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
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.
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.
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.
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
Is that true?
(1) https://news.ycombinator.com/item?id=18997054 (2) https://www.hardenize.com/report/fastmail.com/1723612173
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.
We have written about our reasoning here: https://www.fastmail.help/hc/en-us/articles/360058753834-SSL...
The key paragraph is this:
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.
(Disclosure: I'm the CEO at Fastmail)
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.)
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.
There are a lot of words here, this is an SEO bait, rather than a product update.