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

271–280 of 301 posts

Re: The FastMail Security Mindset

#271

Post by brongondwana »

distances wrote: post #263
brongondwana wrote: post #195

Earlier quoted context omitted.

FastMail.com can send via a forwarding email address. You'll need to set up authentication at FastMail so it can authenticate to the forwarding service of course.

I don't use the forwarding service to send. I use it to forward incoming mail to FastMail, and in FastMail I just fake the sender address when sending e-mail.

Sadly your use-case is dying. Asymmetric mail flows are becoming harder and harder to support, as DKIM/DMARC alignment and SPF become stronger anti-spam signals, we're going to have to lock down on egress for domains which we don't have proof of control for.

Re: The FastMail Security Mindset

#272

Post by bogomipz »

lvh wrote: post #212
bogomipz wrote: post #211

Earlier quoted context omitted.

>"Whatsapp's fine too. But they solve a very different security problem than the one you need e-mail to solve," Can you elaborate on this? What security problem are they trying to solve?

Sure! Signal and WhatsApp are good at having private conversations. Email is very tough to add private conversation capability to, for a variety of reasons. What you do need your mail provider (and by extension your DNS provider) to do is to not give up access to an attacker who asks nicely, because for most services, email access is account takeover. This makes discussions about email security confusing, because mos…

Yes, thanks for the clarification on that point. Cheers.

Re: The FastMail Security Mindset

#273

Post by arghwhat »

carussell wrote: post #164
arghwhat wrote: post #103

Earlier quoted context omitted.

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…

Not to endorse the argument that a local app written in JS is inherently any more worrisome than one written for, say, .NET or GTK+ (because it's not), but this statement really sticks out: > It is relatively easy to find JavaScript execution points Have you ever been tasked with actually trying to guard against these things in security-critical situations? Because even with a deep understanding of the ECMA/W3C/WHATW…

Yes, I have. The list is not very long, and it is comprehensive.

At a previous place of employment, we implemented a full in-JS sandbox. The project was nasty, but as it hooked all JS execution, I do in fact have the fairly short list—what was not hooked would fail, so we were 100% sure that the list was comprehensive. Some of the entries do surprise slightly, mainly due to arcane APIs accepting both strings and function objects. New ECMAScript revisions didn't result in new execution points, although they did complicate the project in other ways.

The project also means that I could whine for ages about browser engine quirks, terrible APIs, awful specs and the likes, and will absolutely never look positively on browsers ever again.

Re: The FastMail Security Mindset

#274

Post by arghwhat »

danenania wrote: post #179
arghwhat wrote: post #103

Earlier quoted context omitted.

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.

That will break the app if it wasn't written for it.

It doesn't change the argument, though. I'm arguing that it is relatively easy to deal with within the limits of what can be dealt with. If a strict content security policy can be applied, it just gets even easier.

Re: The FastMail Security Mindset

#275

Post by arghwhat »

tptacek wrote: post #109
arghwhat wrote: post #103

Earlier quoted context omitted.

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…

I don't follow, since you said none of those things --- eval, script elements, DOM attributes --- in any previous post. I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.

They were implied as "execution of server-side content" in the sentence: "It is relatively easy to look for and identify any execution of server-side content."

It is correct that it would be complicated to do for an arbitrary hosted app that may inject server-side rendered content with scripts in them, but this is not the case here.

There are very few places where "external" content is inserted into the DOM (decrypted mailbox content that may be HTML, account info), and those should all employ proper script stripping techniques. Finding DOM append or assignment (including attribute assignment) points is relatively easy.

With the DOM out of the way, you only have places where the application intentionally executes JavaScript through eval and new Function (potentially wrapped in whatever frameworks they use).

It really isn't very hard. And yes, I have done it before—and no, I couldn't have missed something when I did it, as only interaction I had found would succeed in my sandbox.

Re: The FastMail Security Mindset

#276

Post by rahimnathwani »

brongondwana wrote: post #232
rahimnathwani wrote: post #223

Earlier quoted context omitted.

'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.' According the page you linked, a birth certificate and bank statement (or even a 'Document issued by or registered corporations.') would be enough. So if I get your birth certificate and have an Australian corporation, I can issue a letter saying you're a customer for a year…

We don't use the 100 points of ID system of course, because we're an online service. The 100 points of ID is something that's used in person to decide whether you can open a new bank account using that name. The concept behind the 100 points of ID is that there's a fixed standard and it's not a per-time decision made by a human, it's a consistent set of rules applied without fear or favour.

"We don't use the 100 points of ID system of course, because we're an online service.

Right, but you said you're a 'great fan' of it. My reading of the wikipedia description that you linked suggests that the system is wholly inadequate (mainly as you can satisfy the 100 points without photo ID).

So I'd like to know: are you really a fan of that system (the particulars of its rules), or just a fan of the idea behind it (that there exists a consistent set of rules)?

Re: The FastMail Security Mindset

#277

Post by dannysu »

brongondwana wrote: post #257
dvcrn wrote: post #231

Earlier quoted context omitted.

Please consider adding a option to never ever allow recovering of the account without password, similar to how gandi does it. My email account / domain is my central hub for all my accounts. All of them can be taken over through fastmail (with the exception of my domain and other extremely crucial services) if an attacker happens to obtain access to it. I want to have the security that this attack can not happen to m…

I'm assuming you have 2FA turned on already. It sounds from what you're saying like you (and at least a few other hacker news posters) want is an even stricter "no seriously, I promise I won't ever screw up" mode. We try not to have those kinds of modes, because (for example): https://ianix.com/pub/dnssec-outages.html It turns out, black and white security models lead to massive losses of availability when people scr…

Bron, I think your concerns are justified and understandable. Thanks for entertaining the idea.

I am one of those advocates and would enable such option if given. That said, I did have an instance when I had to call AWS support because of their own screw-up. I closed the AWS portion of my account but not the Amazon.com shopping portion. I later found out that I can no longer remove 2fa on the AWS portion because I no longer have it. I no longer have it because I already closed the account and thought it was safe to remove. However, because of their faulty system design, a closed account was enforcing 2fa on my Amazon.com portion preventing me from accessing it. In this case, the support agent helped me to regain access.

That support agent's ability to fix their faulty system design is both good and a potential liability. I wouldn't want a "I won't ever screw up" mode there.

In the case of email though, when certain conditions are met, it becomes a safer thing to do compared to getting screwed over by support staff.

The pre-conditions are: 1) The user is using custom domains only 2) The user has past emails backed up on his/her own devices

When these conditions are met, the user has complete control of their email destiny. In the case of losing FastMail account access, they can continue to receive email because they control the domain. They also have complete email history because they back it up.

That said, I believe your clearer response elsewhere in this thread is good enough for me personally. I was concerned before because of the vague responses. I think for FastMail, the risk perhaps outweighs the better security for me personally even if I would welcome it.

Re: The FastMail Security Mindset

#278

Post by tptacek »

pvg wrote: post #238
mythz wrote: post #230

Earlier quoted context omitted.

I was hoping there was a quick resource of someone having done a deep analysis dive into advanced techniques Gmail does that makes it more secure than everyone else but judging by tptacek's response it sounds like it's because they have the best security team and by extension all products they make are naturally more secure. If all we have are the same claim being repeated with the only way to learn about what makes…

trawl through 1000's of comments. It means Gmail is always going to perceived as more secure even when they may not be, because relatively no-one is going to trawl through 1000's of comments to make an informed assessment otherwise. 60ish is not 1000s. 69ish if you add the 9 about Protonmail. The guy posts on HN so much you can fairly safely go to https://hn.algolia.com and type author:tptacek [topic of interest] and…

If there was, inexplicably, a comic universe about HN mutants, he'd be The Citation.

This is getting weird. But I'll allow it.

Re: The FastMail Security Mindset

#279

Post by ehPReth »

dvcrn wrote: post #233
ehPReth wrote: post #30

Earlier quoted context omitted.

Indeed - but replying from an arbitrary address is one big downside of G Suite’s implementation. In FastMail you can add [0]@example.com as an identity. Selecting this when composing an email allows you to edit the localpart entirely. Similarly, when replying to an email sent to your catch-all and you have an @ identity for the hostname FastMail will automatically set your from address for you. In Gmail (with G Suite…

Speaking of which, do you know of any mail client (on iOS or Mac) that supports this? I am using the web interface for replying on most emails because of exactly this feature

Unsure, sorry. I use their iOS app (https://itunes.apple.com/us/app/fastmail-email-calendar/id93...) for mobile and their web interface elsewhere

Re: The FastMail Security Mindset

#280

Post by whamlastxmas »

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…

It's not really clear to me. As a paying fastmail customer, can someone still contact your support and get the recovery email address changed?
Post reply on HN