Earlier quoted context omitted.
> 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…
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.
The FastMail Security Mindset
161–170 of 301 posts
Re: The FastMail Security Mindset
#162Earlier 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…
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 their mind set already and can’t be swayed.
As for never needing human assistance, never say never — if relying solely on your password manager, I hope you have a digital last will for your spouse or children.
Re: The FastMail Security Mindset
#163Earlier quoted context omitted.
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 acco…
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?
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 their credentials.
Re: The FastMail Security Mindset
#164Earlier 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…
> 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/WHATWG specs, years of experience with the arcane internals of a specific browser and JS engine, those engines' quirks wrt the way those specs are implemented, and the way they extend the specs, this was really tough even 5 years ago. The fact that JS is now an even faster moving target with yearly updates to the spec means that it's harder now. I don't think anyone who's worked on browsers would get behind the statement you made there.
Re: The FastMail Security Mindset
#165Earlier quoted context omitted.
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 acco…
I would like FM to provide something akin to Google's advanced protection program. Those of us who are careful not to lose our login credentials should not have to suffer a weak recovery process for the convenience of those who do. I personally would rather opt my account into a stronger recovery process even if I can't access my account for several days or a week or more.
Re: The FastMail Security Mindset
#166Earlier quoted context omitted.
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…
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…
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 stuff.
And, I'm absolutely serious about never needing human assistance. I already have mechanism setup for my family to retrieve my digital assets should I disappear tomorrow. I worked on this together with my wife. I know most people have not thought about this and you're right in your skepticism, but I'm serious.
Re: The FastMail Security Mindset
#167Earlier 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…
Hi Bron. I'm a customer of both Fastmail and GSuite, and I have enjoyed your service for a few years now. I still use Fastmail for some things, like sieve, and very much will continue paying just for the ongoing development of open-standard email like JMAP. But there are definitely a few things that I can't shake when I learned about them that very much pertains to the security mindset that prevents me from moving my…
I’ve worked in companies with liberal BYOD policies for portable devices, but also tasted really restricted environments and such environments are basically highly regulated security theaters.
Users do stupid things of course and in corporations it’s worth it to restrict their devices, but restricting developers on what they can install and do on their own devices has a negative ROI and doesn’t go well. If you can’t trust a dev to manage his own phone, you can’t trust him to build your infrastructure either.
And yes, we make mistakes as we are only human, which is why a phone should not be enough to compromise that infrastructure anyway.
PS: your mention of that Twitter account is creepy.
Re: The FastMail Security Mindset
#168Earlier 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…
Hi Bron. I'm a customer of both Fastmail and GSuite, and I have enjoyed your service for a few years now. I still use Fastmail for some things, like sieve, and very much will continue paying just for the ongoing development of open-standard email like JMAP. But there are definitely a few things that I can't shake when I learned about them that very much pertains to the security mindset that prevents me from moving my…
You're right that security is a process. We're always working to harden and segment our internal services, as is best practice these days.
Ongoing professional development and training is important for our security staff (indeed, all our staff, because everyone matters for security). The security landscape is always changing, and it's not something that's ever "solved" - it's a situation to stay on top of.
Re: The FastMail Security Mindset
#169Earlier quoted context omitted.
Hi Bron. I'm a customer of both Fastmail and GSuite, and I have enjoyed your service for a few years now. I still use Fastmail for some things, like sieve, and very much will continue paying just for the ongoing development of open-standard email like JMAP. But there are definitely a few things that I can't shake when I learned about them that very much pertains to the security mindset that prevents me from moving my…
If an Android phone connecting to the company’s WiFi or the user’s email and whatnot is enough to compromise the infrastructure, then the company has bigger problems. I’ve worked in companies with liberal BYOD policies for portable devices, but also tasted really restricted environments and such environments are basically highly regulated security theaters. Users do stupid things of course and in corporations it’s wo…
Re: The FastMail Security Mindset
#170Wow 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.
How's the spam filter compared to Gmail?
I wager I get one, maybe two spam messages in my inbox per month (out of hundreds captured), and maybe one or two false positives in my entire couple years of having mail there.
In any case, that's a better record than Gmail - they've got a huge issue with directing legitimate mail into the spam can.