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.
