Let's ignore the rather awkward self promotion, and the fact that 2FA would have prevented this specific incident.

This is the important part, which everyone should think about:

> What would have been way worse — immeasurably worse — is if our team had used Slack for anything other than what we did use it for, which was discussing outages of our own product. Had my cofounder and I discussed our company's cap table, or business partnerships, or compensation agreements, or ongoing legal matters over Slack; or had our team traded API keys, or security-sensitive matters; or had we controlled mission-critical infrastructure via Slack-powered "bots"; we'd be sweating bullets to this day that our important company secrets were out in the open, about to resurface at the worst possible time.

I see Slack being used for everything at a lot of companies.

There are a lot of interesting things in the chat history everywhere: SSH/API keys, logins and passwords, sensitive internal documents, chatops bots that would let one take control of the infrastructure, and worst of all - juicy office affair gossip.

Combine this with often lax user management (forgetting to disable old accounts, inviting people to channels they shouldn't be in, ...).

Most companies overlook this and don't even have a policy for what's OK to post on Slack, and what isn't. Not even to dream of any kind of enforcement.

I'ts a big security problem, even without Slack getting compromised, and should be on the radar for CTOs.

The author would have done well by refraining from using this as an opportunity to make a sales pitch for their startup, as it detracts from an otherwise important message.

Let me see if I have this right:

Slack had a major security breach in 2015. Apparently someone installed malicious code that could even read password inputs in plaintext. They waited 4 years, after growing large and going public, to inform affected users. And in the interim they blamed their users for any related security problems.

Do I have this correct? If so, how is anyone going to defend this situation? And how can anyone put any sensitive data on Slack, or tell their company to do so, and feel good about it now?

I expected some stupid apology note from the CEO on their website if this turns into a bigger issue, which is sort of an anti-pattern at this point...

What makes this even more sad is the extreme difficulty you'll have if you attempt to remove your company data off of the Slack platform. (Disclaimer: I stopped using Slack 2 years ago)

Our company used Slack extensively for multiple years. A couple years ago, we decided to stop using Slack for official company communication. After switching to alternative communication tools, we tried to delete the data in our Slack account and found it to be nearly impossible.

I recall using 3rd party python scripts (opensource on Github) that took hours to run - the script used an API key to fetch and delete messages individually.

We also tried using Slack's Admin panel to delete messages. At the time, I believe it required clicking a checkbox next to every chat message we wanted to delete. Clearly not a realistic way to scrub an account.

The sad reality is that with many services like Slack, once a provider has your data, there's often no easy way to remove it. IMO, this is a major downfall of our reliance on modern SaaS services (companies have no incentive to prioritize features for deleting account data - the only users who would find those features useful are already churned customers).

Wow - for a sales pitch fantastic. Many of these security issues leave you little to actually do. This write up provides an alternative.

What’s super bad here is slack misleading about the cause wasting all the users time.

Quick question, anyone use key base - can u give a quick review? Team currently use slack

The post says "If the attackers inject server code, 2FA or U2F or any Web-based security practice does little." Understandably if the attacker was actively scraping passwords with 2FAs and was using the credentials immediately, that would be an issue.

However, for the issue mentioned in the post, wouldn't 2FA have saved him? Supposedly, the compromised credential is from 2015.

Not only does Keybase not automatically update its client, there is no way to even figure out if your client is out of date and in need of security updates. Even if you look up the exact version of your installed client, which you can find, there is nothing on the website that says what the most recent version is. The only way to even get a hint is to look on GitHub, and even that isn't accurate; version 4.2.1 is the latest release, but when I download the mac app it's still version 4.2.0.

For whatever problems Slack has, at least I know if there is a new version that I need to install.

>By contrast, Keybase currently runs all of its mission critical chat applications over Keybase itself.

Reminds me of the time Amazon learned that using S3 to host status indicators for S3 is a bad idea if S3 goes down.

> Were our Dutch friends sifting through our messages for four years before Slack notified us of a suspicious login?

The author might know this already but the hackers aren't Dutch. They simply bought a cheap NL server from LeaseWeb to mask their real IP.

slack in 2015: "We have no indication that the hackers were able to decrypt stored passwords, as Slack uses a one-way encryption technique called hashing."

slack in 2019: "In 2015, (...) The attackers also inserted code that allowed them to capture plaintext passwords as they were entered by users at the time. "

This reflects poorly on them. Unless they discovered only now that the 2015 hack included capturing plaintext passwords.

Scary, and certainly doesn't reflect well on Slack. But, do keep in mind that the author runs a company that does compete with Slack in some ways.

Encryption for a business chat app limits the potential users rather significantly, as I understand it. A number of sectors (like banking) have strict rules which require keeping a record of company communications. How does Keybase deal with this, or do they choose not to play in that market?

That's a nice sales pitch! A little on the nose, but I think that's ok.

I think one issue keybase still had is it's minimal web presence that sounds to focus too little on what keybase can do for regular users. People need more explaining of the day to day benefits.

I wonder if this affected companies like IBM... I know for a fact IBM uses slack to talk internally about client billing, meaning if IBM was compromised the attacker knows what most of IBM clients bought from IBM.

Same applies to a bunch of other companies...

> Unlike Slack, it is free. And without ads.

How does Keybase make money?

> Keybase messages are end-to-end encrypted, and only our users control their decryption keys.

End-to-end encryption isn't just good for the users because the service can't access the messages and sell them, it's also good for the users as it provides good protection if the service gets hacked: message content can't leak unless the attackers can change client code.

As people are discussing Keybase for teams and whatnot - could anyone comment on Keybase for individuals, families, etc?

My family are debating moving to Matrix (and away from iMessage). I had briefly debates Keybase due to some interesting features. Anyone have experience with Keybase for families and individuals?

The second I read this, I immediately signed up to Keybase today and deleted my Slack account and switched to the Keybase chat system instead which I am setting up right now.

I am confident to say that this incident was the final nail in the coffin for me to abandon Slack. Choosing Keybase was a no brainer.

From the slack post:

> In other words, if you’re one of the approximately 99% who joined Slack after March 2015 or changed your password since then, this announcement does not apply to you.

Hackers compromising plaintext password would seem to apply to everyone using Slack, whether their account was compromised or not??

I’m a little confused here. Isn’t Keybase a slack replacement product? Why is the CEO of Keybase using Slack for any company communication instead of his own service? Am I missing something obvious here?

Slack gates a lot of its exfiltration security features behind enterprise licensing. Expect to double your spend if you want to try to prevent sensitive data floating around in slack.

Is there any indication why did this post drop from the front page?

Does Keybase support chat message search yet? Otherwise claiming to support all important features of Slack is stretching the truth. I use search extensively at work.

Yeah, this is basically marketing material.

The issue looks to be that they thought they had informed all the affected users back in 2015, but underestimated the set of affected users. The breach certainly wasn’t secret until today, they posted it publicly at that time: https://slackhq.com/march-2015-security-incident-and-the-lau....

I think the point was a sales pitch. The post worked well enough to get to the top of the Hacker News front page. I think the effort was rewarded.

Would shareholders have a case to make for fraud here? Slack clearly didn't want this information getting out pre-IPO, as a security disclosure in this case would certainly impact public confidence in the company.

This is the "lite" version of his sales pitch. The real sales pitch was the email that Keybase users just received. It said, basically, that Slack was compromised but if you would have used Keybase instead, you wouldn't have been compromised.

Awkward, indeed.

I cringe when I see companies try to use a competitor's misfortune to their advantage.