Live data from Hacker News

Slack Security Incident

keybase.io

51–60 of 110 posts

Re: Slack Security Incident

#51

So why was the Keybase CEO using Slack in the first place?

> We basically just use a #breaking channel in there in case we have Keybase downtime.

The problem wasn't they were using Foo and Foo was compromised.

The problem was that he couldn't be 100% sure whether Foo was compromised or not (when asked, they claimed they weren't).

Now, if Foo is a "random-cheezburger-meme-generator" startup you just try out with a throw-away password, then you can probably assume that it's likely they have been hacked and they are lying to you.

That leaves one alternative scenario: you have been hacked.

You'd expect that Slack (in 2019), while it's still possible they lie to you, has decent security practices and thus makes it less likely to be hacked and thus increasing the odds that you might indeed be hacked.

In a way, it acted as a honeypot. But one that you don't control so you can't be sure whether it caught a hacker or whether the bees are drunk.

Re: Slack Security Incident

#52
post #39

Earlier quoted context omitted.

You know what's better than installing slack? Not installing it and using it in the browser. If there's a website option for any tool, I recommend using that over native. It's usually more performant and is less of a security risk. And it's always up to date.

> It's usually more performant and is less of a security risk. Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert, but a few years ago I'd have thought "no way").

What's the mystery here? It doesn't have access to your file system or the ability to request root access.

Re: Slack Security Incident

#53
post #39

Earlier quoted context omitted.

You know what's better than installing slack? Not installing it and using it in the browser. If there's a website option for any tool, I recommend using that over native. It's usually more performant and is less of a security risk. And it's always up to date.

> It's usually more performant and is less of a security risk. Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert, but a few years ago I'd have thought "no way").

Which do you think is more potentially damaging?

1) Using a website which has had its server code compromised (slack).

2) Installing and using an application which has had its code compromised (maybe also slack).

The installed application is going to have more access and potential to damage your system and to compromise your data. There's not really anything more to it. One's in a browser sandbox and limited by browser capability, the other can do literally anything it wants.

Re: Slack Security Incident

#54

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, o…

Slack has some options to delete all messages over N days old. Unless there is a really good reason not to, turning on this feature generally sounds like a good idea. At least you can drastically limit the length of the archive available to any attacker.

Re: Slack Security Incident

#55
post #7

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…

You know what's better than installing slack? Not installing it and using it in the browser. If there's a website option for any tool, I recommend using that over native. It's usually more performant and is less of a security risk. And it's always up to date.

> You know what's better than installing slack? Not installing it and using it in the browser.

What's sometimes even better than that, is not using Slack at all.

Re: Slack Security Incident

#56
post #33

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…

Sounds like an opportunity for a third party tool!

Re: Slack Security Incident

#57
post #33

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…

I don't understand this. They say that if you delete your workspace, all messages are gone.

https://get.slack.help/hc/en-us/articles/204067366-Delete-a-...

Re: Slack Security Incident

#59

Earlier quoted context omitted.

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.

Every tech IPO filing has a generic statement saying something like "our software may contain bugs, including bugs that we cannot fix blah blah blah." So unless Slack has made fraudulent statements about this specific breach, I doubt they've done anything illegal WRT securities fraud.

I'm sure shareholders will sue, because they try to turn everything into a violation of securities law. But securities law shouldn't be the only way to regulate companies imo

Re: Slack Security Incident

#60
post #50
post #43

Earlier quoted context omitted.

> the fact that 2FA would have prevented it. Is that so? The article states: "If the attackers inject server code, 2FA or U2F or any Web-based security practice does little."

It won’t prevent an attacker from logging in as you at the moment, but it will prevent them from using stolen credentials later on.

If they can inject server code, they can bypass 2FA entirely. They don't need your 2FA code they'll just skip that part of the authentication.

The same goes for passwords, but with passwords there is the potential of additional value on other sites that haven't been compromised so those are always worth collecting.

Post reply on HN