go to settings\passwords and security and then type in your master password at the top.

Scroll to the bottom of the page and there is a link called "alternative logins". If you have completely switched across to both imap.fastmail.com and smtp.fastmail.com, you should delete these alternative passwords and ionly use the app-specific password for both IMAP and SMTP.

Alternative passwords still work for loging in, but the session is not limited as it used to be (for example: now I can permanently delete using an "empty link" when logged in with an altaernative password that used to not allow permanent deletion).

What I'd like to see is that in addition to SMS, TOTP, U2F and YubiKey OTP, the "Set up Two-Step Verification" section would have an additional option of "Print list of OTPs". then this would be used just like the TOTP option (after the username and master password are entered, a prompt for and additional unused password from the list, or 3 fields in the login screen, for username, main password and OTP in the classic login page).

This shouldn't be too difficult to implement.

Has this been considered? Other providers (gmail) have this kind of "2nd factor".

I ordered a Yubikey about a month ago, but it still haven't arrived, and I really don't like that the "thing I have" would be the same device that stores my master password (that is, my phone that runs the Fastmail app). I also prefer the reliability of paper...

Google’s Chrome browser has long been the lone platform for U2F, but that has changed. The Opera browser (version 40) began supporting U2F in late September 2016. In addition, Mozilla hopes to wrap up in late 2016 U2F support in the Firefox browser with features on parity with Google’s U2F implementation. In fact, the two have been consulting on this work with each other and the Yubico engineering team. In addition, Mozilla plans to eventually support the WebAuthn APIs being developed by the World Wide Web Consortium (W3C) for secure browser log in. Those APIs also factor into a more complete FIDO strong authentication ecosystem. Microsoft’s Edge browser also will support those APIs when they are finalized (projected early 2017).

I've been meaning to post about this for quite a while but the new system really seems to be a security downgrade for some perfectly good use cases.

First, as others have mentioned, SMS is no longer considered a secure authentication channel. So Fastmail's suggestion of registering a phone number for purposes of password reset just opens an attack vector. Anyone who finds out the phone number can request a reset, intercept the incoming SMS message, and pwn my Fastmail account. SMS is useless and enrolling a phone number sounds like a bad idea.

TOTP is reasonable except that the smartphones running most TOTP apps are themselves bundles of malware (I don't use a smartphone and hopefully never will). The Yubikey is yet another electronic gadget containing secrets, and requires a USB port, something absent from many devices like tablets and phones. Also it claims to implement TOTP but I don't see any evidence that it has a hardware RTC (e.g. the nano version looks too small to have a battery inside). If it's getting the time from a remote server, it can be fooled into giving a future authentication code, and (if it requires the remotely supplied times to increase monotonically) it can be bricked by a malicious remote server. Plus it's expensive.

The old, printed OTP system worked really well. 99% of the time I use Fastmail from my personal laptop with hopefully ok security, logging in with a password. The other 1% is from totally untrusted devices: e.g. I'm travelling and need to check a message from a kiosk, somebody's phone, or something like that. The printed OTP was great for that. I never had to give up a re-usable secret. Yubikey (if I were willing to buy it) often wouldn't work in that situation (USB....) and it would only be usable as a second factor one time. Because the master password must be considered compromised as soon as you enter it in an untrusted device, the only factor left is the Yubikey or TOTP, which means you're back to 1-factor authentication.

The printed OTP was also good because I don't like travelling with electronics due to airport security, customs, etc. liking to examine the contents. The printed OTP on a slip of paper (Post-it sized) is much less likely to get examined, and before check-in for a return flight I could rip it up and throw it away, removing the possibility of interception. No way I want to do that with a $50 yubikey or a smart phone.

I tried to concoct some scheme with app passwords where the application would auto-disable its own password after being used once, but that seems to require the master password.

The security page seems to allude to a challenge-response scheme in the Fastmail mobile app. Is that documented so I can implement it in my own app? (That app would run on a server since I don't use mobiles).

Another idea is to have an automated IMAP client with an app password pulling my email off of Fastmail every few minutes, but if I'm reading mail from my own server, Fastmail isn't doing that much for me.

Most of all I'm bothered by Fastmail calling something a security improvement when it's actually a regression. When they got rid of SMS they straightforwardly said it wasn't worth supporting any more, which was ok (except maybe for Premier account holders who had paid for a lot of SMS expecting to use it). They didn't say "we've increased our capabilities by getting rid of SMS".

Anyway I guess I'll research how the 2-factor stuff works. TOTP is very simple but I don't know about U2F and so on.

That's a cute idea, using the google backup code, but it still involves compromising your fastmail master password as discussed. Also it means sending the fastmail code by SMS so it can be intercepted. I think I might set up TOTP on a few different servers that I use, with printed access codes and maybe using random ipv6 addresses (from the servers' /64 spaces) so they should be very hard to find by port scanning.

Another silly thing I see: before you can even activate 2FA, fastmail wants to send you a recovery code by (insecure) SMS and they advise you to write it down. But of course you have to treat it as compromised the minute they send it to you, so it's better to log in, delete the recovery code right away, and generate a new one.

I notice also that U2F uses elliptic curve signatures with the NIST P256 curve, which some people think might be backdoored by the NSA (there's no concrete evidence for this, but no way to disprove it either). The NIST curves are also very difficult to implement properly so I'd hope there's been an external code audit of the Yubikey device. And the low cost Yubikey ($18, still not that cheap) is a big unit like a memory stick that you can't just leave in the port when transporting a laptop. I might go for a software implementation.

I don't understand why they got rid of the printed OTP that worked perfectly well with much less technical complexity everywhere in the system.

I don't understand why they got rid of the printed OTP that worked perfectly well with much less technical complexity everywhere in the system.

Probably the usual reason many software companies remove good features in upgraded releases -- low usage of the removed feature, so not worth their effort/time/resources to continue upgrading and maintaining the feature in the context of an upgraded platform.

I tried to concoct some scheme with app passwords where the application would auto-disable its own password after being used once, but that seems to require the master password.

The security page seems to allude to a challenge-response scheme in the Fastmail mobile app. Is that documented so I can implement it in my own app? (That app would run on a server since I don't use mobiles).

If you want to go to the development effort, it would be possible to have a Selenium script on your home server that uses browser automation to generate and revoke app passwords. It might be difficult to do this in a way that would ensure full security if your home server was seized.

If you want to go to the development effort, it would be possible to have a Selenium script on your home server that uses browser automation to generate and revoke app passwords. It might be difficult to do this in a way that would ensure full security if your home server was seized.

I don't currently have any home servers--I might set one up, but I don't trust my home internet to stay connected while I'm away anyway (router occasionally gets wedged and needs power cycling). So I'm talking about remote servers (vps's in some instances). There'd necessarily be some obscurity involved, but at the end of the day I have to trust Fastmail's servers so it's not that much worse if I also have to trust my own.

I don't want to do complex development for this--too much work and too many parts to go wrong. I'm thinking of a simple web app (20 line python cgi) that accepts a one-time password from a printed list like Fastmail used to, and sends back a TOTP code. Do you know you can get a dedicated server in France for 3 euro a month (scaleway.com)? I have one of those for unrelated purposes, so it might be a reasonable place to host this thing since it could be sure of keeping the TOTP key in ram instead of it possibly getting written to disk and leaking from there. There'd have to be a secondary server as well. I'll think about this.