Live data from Hacker News

Slack Security Incident

keybase.io

81–90 of 110 posts

Re: Slack Security Incident

#81
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-...

It says they're "irretrievable", which isn't necessarily the same thing. That you can't get that data back doesn't mean it's no longer stored by Slack in a way that a sufficiently severe compromise of their infrastructure might reveal.

Re: Slack Security Incident

#82
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-...

At the time, there were reasons we couldn't completely delete the workspace. I believe there was certain data we wanted retained, and other data we wanted removed.

Re: Slack Security Incident

#83
post #43

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…

> 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."

I don’t quite understand that bit, the attackers could at the time steal plaintext passwords - however how does that affect 2FA benefits several years after the attack?

It sounds like he’s mixing a couple of things up there unless anyone can explain otherwise?

Re: Slack Security Incident

#85
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.

Re: Slack Security Incident

#86

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…

At my last job, I wrote a little tool to download hipchat chat logs and scrape them for anything that looks like a password. There were tons!! I raised it to the CTO/CIO, and while they sounded interested in it, they never enacted any policies, etc, to prevent the sort of password sharing that anyone can apparently easily take advantage of.

In fact, the CIO asked me to send him a spreadsheet of when/where passwords were shared -- and then never did anything with it, despite the file essentially being a password map of the infrastructure. When I asked him if he deleted it, he told me he couldn't because the company's lawyers wouldn't allow him to. Lol.

It's insane out there.

Re: Slack Security Incident

#88

Earlier quoted context omitted.

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-...

It says they're "irretrievable", which isn't necessarily the same thing. That you can't get that data back doesn't mean it's no longer stored by Slack in a way that a sufficiently severe compromise of their infrastructure might reveal.

I doubt they keep customer data after you're not a customer anymore. Sure, they could be lying but we don't have information pointing to that, do we?

They are subject (or have subjected themselves) to various security standards: https://slack.com/intl/en-ie/security

And their security whitepaper [0] mentions:

Customer data is removed immediately upon deletion by the end user or upon expiration of message retention as configured by the customer administrator

It would be a stretch to say a message is deleted permanently but a workspace is kept forever, for unknown reasons. Occam's razor and stuff.

0 - https://a.slack-edge.com/78b2/marketing/downloads/security/S...

Re: Slack Security Incident

#89
post #10

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

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.

It's not using competitors misfortune if they didn't reasonably disclose the breach

Re: Slack Security Incident

#90

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…

Do Keybase folks use Keybase for literally all their communications, document sharing? That's a bit hard to imagine. I'd wager that some of those important comms were on email and pretty much all the scary arguments about server/account hacking would apply to the involved email accounts too?

And a naive interpretation of the posting also raises the question of what secret deals, etc could Keybase be doing that would be disastrous if it were to come out later, that, as a Keybase user, I should be concerned about? A secret backdoor in the keys embedded for the NSA?

(Keybase user here)

Post reply on HN