The FastMail Security Mindset • Hacker News Board

Re: The FastMail Security Mindset

#141

Post by tptacek » Tue, Dec 05, 2017, 10:41 PM UTC

brongondwana wrote: post #134

ghouse wrote: post #64

I was a very happy FastMail customer until a hacker asked them to reset my password. After _incorrectly_ answering a handful of questions asked by the FastMail support, the recovery email address was changed and a password reset link sent. From there, the hacker attempted password resets on other services. Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7…

Good morning. I'm going to be here to answer specific questions, and I owe you a personal response to this as well, which I'm about to start working on! There is no doubt that in this specific case our human factor screwed up, and I'm really sorry about that. First I'm going to post the standard response that our team has written for any new support tickets that come in about this today, then write my own personal ap…

Exactly which employees in your organization have the ability to alter recovery email settings?

How many of those employees are there?

In what fashion do you audit and track the activities of those employees?

What training are these employees given to avoid social engineering? What firm provides the courseware?

What's the escalation process for complicated, non-no-brainer reset situations? If a support person isn't absolutely sure whether they should reset something, how do they get a second opinion?

Are the support people who are entitled and able to make these changes incentivized to close tickets as quickly as possible?

Do you monitor "out-of-process" changes to recovery email and password settings, so that you can see trends over time and by particular staff members?

Has any third party security firm assessed your service recently specifically for this attack vector, for instance by conducting social engineering testing against your support staff? What's the firm?

How are you MINIMIZING, rather than just improving, the "human factors" involved in assessing whether accounts can be altered based on anonymous incoming callers and requesters?

This is a HUGE, TERRIFYING vulnerability. Email providers are the single most important security service people use; if your email is compromised, many (most!) of your other services are compromised as well.

Re: The FastMail Security Mindset

#142

Post by carussell » Tue, Dec 05, 2017, 10:45 PM UTC

distances wrote: post #136

bartbutler wrote: post #131

Earlier quoted context omitted.

We have never used RoundCube in the project's history. You must be thinking of someone else.

Thanks for the clarification, must indeed be mixing you up with another service!

You might be thinking up riseup.net. They use Roundcube, they target a similar audience, and both have a cryptopunk-ish slant.

Re: The FastMail Security Mindset

#143

Post by brongondwana » Tue, Dec 05, 2017, 10:46 PM UTC

ghouse wrote: post #64

I was a very happy FastMail customer until a hacker asked them to reset my password. After _incorrectly_ answering a handful of questions asked by the FastMail support, the recovery email address was changed and a password reset link sent. From there, the hacker attempted password resets on other services. Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7…

Now to write a more detailed response. If this winds up out of order later, I first posted: https://news.ycombinator.com/item?id=15856609

Again, ghouse, I'm really really sorry about what happened to your account. It was wrong and we screwed up. As other comments have already noted, it was during the transition to a new security system which was designed precisely to remove the human factor from decision making.

I'm an Australian, and I'm a great fan of our "100 points of ID" system, which is designed to remove the human factor from identifying people.

https://en.wikipedia.org/wiki/100_point_check

While I wasn't aware of your account's issue at the time (and we'll be having some discussions internally about why not!), FastMail management were all aware that we needed to get the human factor out of decision making about account access, particularly since somebody tried to pull a similar swindle on our domains!

https://blog.fastmail.com/2014/04/10/when-two-factor-authent...

We spent a lot of 2016 and 2017 working on an automated account recovery system which allows recovery of locked accounts via a carefully audited set of automated steps, which includes a 24 hour lockout to allow the owner to notice an attempt on their account.

If this had existed in 2016 then we would have sent you there rather than having a human make a (poor in this case) judgement call!

https://www.fastmail.com/help/account/icantlogin.html

Re: The FastMail Security Mindset

#144

Post by ilikepi » Tue, Dec 05, 2017, 10:50 PM UTC

dannysu wrote: post #139

brongondwana wrote: post #134

Earlier quoted context omitted.

Good morning. I'm going to be here to answer specific questions, and I owe you a personal response to this as well, which I'm about to start working on! There is no doubt that in this specific case our human factor screwed up, and I'm really sorry about that. First I'm going to post the standard response that our team has written for any new support tickets that come in about this today, then write my own personal ap…

This can be enough for me to consider leaving depending on how it's fixed. This response says absolutely nothing about how the vulnerability is prevented in the future. It's just a bunch of vague promises and mumbo jumbo. What specific procedures are in place to prevent it? At a minimum, I expect to see something specific like when you guys almost lost your domain because of Gandi [1]. And even then, can I have an op…

> And even then, can I have an option to select absolutely no human intervention possible?

> I already have multiple ways of recovering my account, and I never, ever want human assistance on this.

Yep, I'll second this feature request. Put as many disclaimers and confirmation mechanisms on it as you need to in order to keep people from accidentally enabling it. I will happily assume responsibility for it.

Re: The FastMail Security Mindset

#145

Post by dewey » Tue, Dec 05, 2017, 10:51 PM UTC

mike-cardwell wrote: post #126

They should do PGP on the way in, for people who want it. It's trivial to set up. All they need to do is let people paste in a public PGP key and encrypt all incoming email with that key. Here's how I've been doing it for the last 7 years: https://www.grepular.com/Automatically_Encrypting_all_Incomi...

If it would be "trivial to set up" don't you think they would've already done it and offer it as an option?

Re: The FastMail Security Mindset

#146

Post by tptacek » Tue, Dec 05, 2017, 10:51 PM UTC

brongondwana wrote: post #143

ghouse wrote: post #64

I was a very happy FastMail customer until a hacker asked them to reset my password. After _incorrectly_ answering a handful of questions asked by the FastMail support, the recovery email address was changed and a password reset link sent. From there, the hacker attempted password resets on other services. Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7…

Now to write a more detailed response. If this winds up out of order later, I first posted: https://news.ycombinator.com/item?id=15856609 Again, ghouse, I'm really really sorry about what happened to your account. It was wrong and we screwed up. As other comments have already noted, it was during the transition to a new security system which was designed precisely to remove the human factor from decision making. I'm…

I don't understand this response. I'm glad you're working to minimize human factors. Can you explain how exactly you're doing that? I asked some specific questions here:

https://news.ycombinator.com/item?id=15856755

Re: The FastMail Security Mindset

#147

Post by ghouse » Tue, Dec 05, 2017, 10:51 PM UTC

brongondwana wrote: post #143

ghouse wrote: post #64

I was a very happy FastMail customer until a hacker asked them to reset my password. After _incorrectly_ answering a handful of questions asked by the FastMail support, the recovery email address was changed and a password reset link sent. From there, the hacker attempted password resets on other services. Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7…

Now to write a more detailed response. If this winds up out of order later, I first posted: https://news.ycombinator.com/item?id=15856609 Again, ghouse, I'm really really sorry about what happened to your account. It was wrong and we screwed up. As other comments have already noted, it was during the transition to a new security system which was designed precisely to remove the human factor from decision making. I'm…

Thank you. I appreciate your response and understand that you've made improvements since this incident in 2016.

Re: The FastMail Security Mindset

#148

Post by xmodem » Tue, Dec 05, 2017, 10:54 PM UTC

brongondwana wrote: post #143

ghouse wrote: post #64

I was a very happy FastMail customer until a hacker asked them to reset my password. After _incorrectly_ answering a handful of questions asked by the FastMail support, the recovery email address was changed and a password reset link sent. From there, the hacker attempted password resets on other services. Initially, FastMail was dismissive that this was a simple "mix-up" and didn't disable access to the hacker for 7…

Now to write a more detailed response. If this winds up out of order later, I first posted: https://news.ycombinator.com/item?id=15856609 Again, ghouse, I'm really really sorry about what happened to your account. It was wrong and we screwed up. As other comments have already noted, it was during the transition to a new security system which was designed precisely to remove the human factor from decision making. I'm…

> a 24 hour lockout to allow the owner to notice an attempt on their account.

I've been pretty careful to ensure that I don't lock myself out of my account (multiple U2F keys, strong password saved in password manager with backups)

But if a determined attacker kicks this off just as I'm stepping on a flight from Sydney to London, 24 hours isn't going to be enough.

(I should add also - I'm a mostly happy Fastmail customer)

Re: The FastMail Security Mindset

#149

Post by carussell » Tue, Dec 05, 2017, 10:55 PM UTC

gst wrote: post #8

BCM43 wrote: post #3

Earlier quoted context omitted.

For most providers, like Protonmail, the decryption password is the same as your login password. I'm curious what scenario you see allowing someone other than the provider to get access to your mailbox but not also your decryption key.

ProtonMail doesn't have access to the decryption password as it is not transferred to the server. Instead the client sends a password that's derived from it: https://protonmail.com/blog/encrypted_email_authentication/

The "client" is a webpage that exists as one of many assets delivered to your browser by the ProtonMail webmail server. The server has access to the password at any time if it wants it.

Re: The FastMail Security Mindset

#150

Post by brongondwana » Tue, Dec 05, 2017, 10:56 PM UTC

tptacek wrote: post #141

brongondwana wrote: post #134

Earlier quoted context omitted.

Good morning. I'm going to be here to answer specific questions, and I owe you a personal response to this as well, which I'm about to start working on! There is no doubt that in this specific case our human factor screwed up, and I'm really sorry about that. First I'm going to post the standard response that our team has written for any new support tickets that come in about this today, then write my own personal ap…

Exactly which employees in your organization have the ability to alter recovery email settings? How many of those employees are there? In what fashion do you audit and track the activities of those employees? What training are these employees given to avoid social engineering? What firm provides the courseware? What's the escalation process for complicated, non-no-brainer reset situations? If a support person isn't a…

Wow, that's a lot of questions, and I can't answer all of them without creating security risks!

Our absolute focus is on minimizing the human factors.

In the past year and a bit since that incident, we have improved our escalation policies and support training, as well as let some support staff go.

But more importantly, we now have an automated account recovery system which can be used to verify ownership of the account using a number of different factors (not all of which I'd like to talk about in public - again, if an attacker knows the full algorithm it helps them game it).