Fastmail are also greedy: they monetize 2fa via sms to the tune of $0.12 (!!!) per text, and for the cherry on top, they expire your credits after a year. It's just skeevy cheap.
This doesn't really bother me because you can use Google Authenticator-style TOTP codes instead, which are free, and I don't expect Fastmail to run their own SMS infrastructure, so they presumably have to pay someone. It would be nice not to have to manually append the code to your password though, as the set-up page suggests, because this would mess up password managers. Why not detect when someone's logging in with 2-factor authentication and present an additional panel for the verification code, like most websites do?
Also agreed that it's not 'true' 2-factor authentication if you can get product support or log in with only a master password. That opens up a lot of social engineering attacks. But then, true 2-factor authentication is also a support nightmare when people lose their passwords, so I'm sympathetic, but it doesn't change the fact it's not ideal.
I can promise you that we make no money on those SMSes, we just haven't updated the pricing since it really cost that much - and we're actually paying a minimum per-month rate that means it's costing us more than that for how rarely it's used.
Since you work there.. why did you guys choose that approach for 2fa? Reading what's written on the help page about the master password, it sounds like you want the master password to serve as a recovery code. So why not just have recovery codes instead?
Also, since you would generate the recovery codes, there wouldn't be a need to explain why the master password should be long & random; and it would reduce the risk of customers using an easy master password (either from failing to change it, or failing to use sufficient length/randomness).
> Since you work there.. why did you guys choose that approach for 2fa? Reading what's written on the help page about the master password, it sounds like you want the master password to serve as a recovery code. So why not just have recovery codes instead?
History, mostly. Ten years ago 2FA wasn't really a thing for most sites. We built an "alternative login" system, where you could create secondary passwords for your account and optionally set that password to be a "restricted" login. This was when using FastMail on untrusted machines (eg public libraries) was not at all uncommon, and HTTPS and even cookie-based login wasn't widespread and being able to create a throwaway password was very useful!
Over time we added paper-based OTP, Yubikey, SMS and so on but at its core its still just for secondary passwords.
We have started work on a rewriting the whole way this system works, which will work like more "conventional" 2FA systems, and will allow a second-factor on the master password. We're expecting it to be available later this year.
I'm a disappointed subscriber.