Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The FastMail Security Mindset

blog.fastmail.com

Post reply on HN
Print view View original

171–180 of 301 posts

Re: The FastMail Security Mindset

#171

Post by bad_user »

dannysu wrote: post #166
bad_user wrote: post #162

Earlier quoted context omitted.

At a minimum, normally when speaking of the other big mail providers, you wouldn’t get an explanation on a public forum at all. Especially because technical folks like us don’t know to communicate well, words can be misinterpreted, etc. It’s actually not a good strategy to respond to such concerns in public. Also in my opinion, people that make threats of leaving in public unless certain demands are met usually have…

I understand what you're saying, but I think perhaps we can agree that the current response is insufficient? Have you taken a look at the link I supplied above where FastMail wrote about how 2fa protection could be bypassed at Gandi? They were very specific and clear about the recommendations being implemented. Now, compare that to their current response. I think definitely the difference can be seen. This is serious…

For what is worth, I’d also like a toggle in the settings to never involve human assistance.

But we technical folks are very odd and I’m assuming they have users that really need human assistance.

I do agree the response is insufficient, my point is that such discussions in public are dangerous for the company and it’s not the norm for company reps to give detailed explanations without prior preparations.

Re: The FastMail Security Mindset

#172

Post by blahshaw »

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…

How recently was this?

Re: The FastMail Security Mindset

#173

Post by eridius »

carussell wrote: post #71
333c wrote: post #10

Earlier quoted context omitted.

I'm considering switching (in fact I just registered for the FastMail trial). I'm especially interested in the ability to use catchall addresses with a custom domain, which would allow me to give out an address like , and thus determine who shared my email address if I start receiving spam at that address. This is partly possible with Gmail, as you can use addresses like , but not all sites support emails with a + in…

I used Fastmail for a few years. I switched last spring due to two interactions through support channels that left me really despising the apparent company culture, attitudes about intellectual honesty, and general jerkishness. You're probably considering switching based on your mail needs, so this might not apply to you, however: In addition to mail, Fastmail also advertises[1] their plans come with their FastMail F…

> However, I learned from the CEO's comments in my support ticket that they're apparently overprovisioned and don't expect everyone to actually use the storage included with their plans.

Isn't that true for every file hosting service everywhere? Most people only use a fraction of their available storage, so there's no need to actually provision enough space for everyone to use 100% of their quota. Doing so would be a waste of space.

Re: The FastMail Security Mindset

#174

Post by ZoF »

tptacek wrote: post #118
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…

This is death. Your email provider absolutely cannot under any circumstances have this vulnerability. Wow. Just the idea that there's a human in the process making subjective decisions about security questions and answers that can, on their own recognizance, change a recovery email address. Forget the immediate mistake that one rep made, and go down a couple levels deeper into the company policy design mistakes at pl…

You're aware this is how the vast majority of email providers legacy operated right? (And sadly a few still do)

E.g. in this case likely a 2 point auth system (security question and e.g. payment details (last four of latest payment meth/etc))

Seems you're shocked that a lower tier support agent can auth this kind of request when the reality for most email hosts is that they can.

They(likely a new employee) got socialed.

Yes, they should have systems in place to prevent this from being possible in the first place; no, I do not find your incredulity genuine, albeit rational.

Re: The FastMail Security Mindset

#175

Post by adrianratnapala »

xmodem wrote: post #148
brongondwana wrote: post #143

Earlier quoted context omitted.

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 cust…

For an attacker to exploit this, they will have to know that you are going on such a trip. This means that attackers who don't know much about you already are less likely to bother, and also raises the bar for even the focus attackers.

Nothing is foolproof, but many things can be useful.

Re: The FastMail Security Mindset

#176

Post by chrismorgan »

kareemm wrote: post #52
news_to_me wrote: post #7

Wow what a coincidence — I switched from Gmail to Fastmail exactly 1 year ago today. I couldn't be happier. I mostly use native clients, but the Web client is a joy to use, and everything I've observed about Fastmail gives me confidence in their service. I never used the Gmail-exclusive features like labels, so switching was pretty easy. I highly recommend it to anyone considering it. Keep up the good work, guys.

Interesting. I switched a little over a year ago too. I like not being the product but find the web client painful. Specifically: 1. No Send and Archive 2. Sending is slooow. E.g. compose email, hit Send, wait several seconds, go back to Inbox. Gmail is instantaneous. 3. Hitting Reply is SLOOOOW to bring up the Reply pane. Fastmail does a POST that takes from 500ms to 5000ms (usually on the lower end but even that is…

I whipped up a quick implementation of Send & Archive for fun which you can hook up with something like Greasemonkey:

  O.require(['mail', 'compose'], function () {
    const composeController = FastMail.mail.screens.compose;
    const mailActions = FastMail.mail.actions;
    const mailToolbar = FastMail.views.mailToolbar;
    mailToolbar.registerView('sendArchive', new O.ButtonView({
      type: 's-send',
      icon: 'icon-paper-plane',
      _isSending: O.bind(composeController, 'instance.isSending'),
      _mayMove: O.bind(mailActions, 'mayMove'),
      isDisabled: function () {
        return this.get('_isSending') || !this.get('_mayMove');
      }.property('_isSending', '_mayMove'),
      label: O.loc('Send & Archive'),
      target: {
        doIt: function () {
          composeController.fire('send');
          mailActions.archive();
        }
      },
      method: 'doIt',
      shortcut: 'cmd-shift-enter',  // (Fairly arbitrarily chosen.)
    }));
    const config = O.clone(mailToolbar._configs.compose);
    config.left.splice(config.left.indexOf('send'), 0, 'sendArchive', '-');
    mailToolbar.registerConfig('compose', config);
  });
It’s not elegant, but it works. It’ll probably break when the web UI switches to JMAP some time next year.

Re: The FastMail Security Mindset

#177

Post by hitekker »

brongondwana wrote: post #163
tptacek wrote: post #153

Earlier quoted context omitted.

Which of these questions can you not answer without creating security risks? I didn't ask you anything about your automated system. Is it possible under any set of circumstances for your human employees to alter accounts? If the automated system fails, are accountholders out of luck?

If the automated system fails and you have 2fa, then it gets escalated to the two most senior members of the security team. In some cases we haven't had sufficient information on the account to ever verify that account's owner, and they never got their account back. Some users refuse to give us enough information to allow us to later positively identify them - so yes, those people will be out of luck if they lose the…

At this point, you should write a blog post to address the myriad of concerns popping up in this thread.

Re: The FastMail Security Mindset

#178

Post by jf »

brongondwana wrote: post #163
tptacek wrote: post #153

Earlier quoted context omitted.

Which of these questions can you not answer without creating security risks? I didn't ask you anything about your automated system. Is it possible under any set of circumstances for your human employees to alter accounts? If the automated system fails, are accountholders out of luck?

If the automated system fails and you have 2fa, then it gets escalated to the two most senior members of the security team. In some cases we haven't had sufficient information on the account to ever verify that account's owner, and they never got their account back. Some users refuse to give us enough information to allow us to later positively identify them - so yes, those people will be out of luck if they lose the…

I agree with hitekker, I'm feeling pretty nervous about being a FastMail customer right now and will start looking for a more secure alternative now. The main reason I moved to FastMail is because I stopped trusting Google to keep my mail secure.

Re: The FastMail Security Mindset

#179

Post by danenania »

arghwhat wrote: post #103
tptacek wrote: post #58

Earlier quoted context omitted.

No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.

You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment. It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (i…

A strict content security policy in an http-equiv meta tag is a much simpler and more effective way to accomplish this.

Re: The FastMail Security Mindset

#180

Post by brongondwana »

tptacek wrote: post #161
brongondwana wrote: post #160

Earlier quoted context omitted.

You can't even get to the 24 hour lockout unless you've successfully passed the security checks. We add the 24 hour lockout as an additional level of protection for 2fa accounts (even though they've given two factors of recovery by then) or if we can't confirm that you are resetting from a computer which has successfully logged in to that account before.

It sounds like if I use Fastmail, and I go on vacation (and thus go a day without checking my email), someone can max out the automated system and then get a human being at Fastmail to potentially reset my recovery email. Is this the case?

You can't max out the automated system.

Our procedures have to balance the concerns of very different groups of people.

Some people have explicitly directed us to enforce stringent account security requirements by enabling multi factor authentication. For those people, we assume that they have their own security practices and are diligent in maintaining them. Those people are aware of the risk of losing access to their mail if they lose their credentials.

The other, much larger group of our customers, come to use because they want email that has support. Many of these customers forget their passwords and still need to get to their email (which is more common than you might imagine if you are surrounded by a hacker-news demographic!)

Our procedures have to balance between those two sets of needs, and they evolve over time. This incident came up in a period of transition. It should never had happened, and it's a great object lesson to us about how to do better in future transitions.

Having said that, based on this conversation today we are reviewing all our processes around re-establishing access for regular people who haven't requested additional security by enabling second factors. We absolutely can and will do better than we did in 2016.

Post reply on HN