New features to keep your FastMail account even more secure - Page 19

gardenweed · 1 Sep 2016, 06:35 PM

1) yes scanner emails scans, thus the App p/w.
2) The specific message in my case was not SMTP. It was specifically an IMAP login, unlike the previous poster that had the SMTP login notice.

Anyhow, thanks for your suggestions.
But I am fine regarding finding the cause.

JamesHenderson · 1 Sep 2016, 06:36 PM

Quote:

Originally Posted by gardenweed

...I am fine regarding finding the cause.

great! ...what was it?

gardenweed · 1 Sep 2016, 07:06 PM

Quote:

Originally Posted by JamesHenderson

great! ...what was it?

Well I'll certainly post back when I've found it!

JamesHenderson · 1 Sep 2016, 07:10 PM

Quote:

Originally Posted by gardenweed

Well I'll certainly post back when I've found it!

cool. ...just a thought though, at the bottom of the passwords screen you can see all logins (success and failed, I think) for the last 2 weeks and which password was used. ...might be helpful.

John Denison · 1 Sep 2016, 07:20 PM

Quote:

Originally Posted by JamesHenderson

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.

Thanks, done that.
John

hadaso · 18 Sep 2016, 07:15 AM

Quote:

Originally Posted by Terry

Its the end of September now...

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).

hadaso · 6 Oct 2016, 07:42 AM

Quote:

Originally Posted by hadaso

.....

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...

pjwalsh · 12 Oct 2016, 05:07 AM

Some encouraging 2FA news on the browser front, via Yubico:

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).

https://www.yubico.com/2016/07/over-...rce=newsletter
October 10 update

BritTim · 12 Oct 2016, 05:43 AM

The big question: can Apple finally be persuaded to join the FIDO initiative? Up until now, they seem determined to try to push their proprietary security solutions instead.

paul29 · 12 Oct 2016, 01:03 PM

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.

DumbGuy · 12 Oct 2016, 03:16 PM

@paul29 - Thanks for chiming in on this topic.

Because the master password must be considered compromised as soon as you enter it in an untrusted device

Yes, this particularly bothers me as well.

Regarding printed OTP... What do you think of this workaround I suggested?

paul29 · 12 Oct 2016, 03:56 PM

Quote:

Originally Posted by DumbGuy

Regarding printed OTP... What do you think of this workaround I suggested?

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.

DumbGuy · 12 Oct 2016, 04:14 PM

Quote:

Originally Posted by paul29

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.

BritTim · 12 Oct 2016, 04:15 PM

Quote:

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.

paul29 · 12 Oct 2016, 05:47 PM

Quote:

Originally Posted by BritTim

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.

12 Oct 2016, 05:07 AM	#278
pjwalsh Essential Contributor Join Date: Dec 2008 Location: Canada Posts: 312	U2F for Firefox close at hand Some encouraging 2FA news on the browser front, via Yubico: 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). https://www.yubico.com/2016/07/over-...rce=newsletter October 10 update

12 Oct 2016, 01:03 PM	#280
paul29 Senior Member Join Date: Apr 2014 Posts: 166	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. Last edited by paul29 : 12 Oct 2016 at 04:01 PM.

1 Sep 2016, 06:35 PM	#271
gardenweed Cornerstone of the Community Join Date: Jun 2008 Location: Perth Posts: 664	1) yes scanner emails scans, thus the App p/w. 2) The specific message in my case was not SMTP. It was specifically an IMAP login, unlike the previous poster that had the SMTP login notice. Anyhow, thanks for your suggestions. But I am fine regarding finding the cause.

12 Oct 2016, 05:43 AM	#279
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,090	The big question: can Apple finally be persuaded to join the FIDO initiative? Up until now, they seem determined to try to push their proprietary security solutions instead.

12 Oct 2016, 03:16 PM	#281
DumbGuy Essential Contributor Join Date: Oct 2008 Posts: 212	@paul29 - Thanks for chiming in on this topic. Because the master password must be considered compromised as soon as you enter it in an untrusted device Yes, this particularly bothers me as well. Regarding printed OTP... What do you think of this workaround I suggested?