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.
Is that so? The article states: "If the attackers inject server code, 2FA or U2F or any Web-based security practice does little."
It sounds like he’s mixing a couple of things up there unless anyone can explain otherwise?
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.
Given the massive and escalating fines over customer data hacks and leaks I suspect we will see laws requiring data retention going head to head with consumer privacy laws. Given that even Jeff Bezos can’t keep his communications secure, the outlook for infosec consultants is fantastic. If anti-encryption laws start appearing on top of all of this, it’s going to be an absolute bonanza.
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)
If I succeeded in making the process easy & less time consuming than it is now, do you think it's a product you would pay for?
That's why I always strongly recommend having a https://privatebin.info/ . In fact, in every startup I have been, I setup an instance of that forcing "burn after reading" and as a policy all credentials and sensitive info goes there when sharing.
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...
With that said, I wish he'd have gone into more of a pitch - specifically why Keybase might be unable to suffer from this specific problem. Or at least, why the attack surface area is smaller with Keybase, etc etc. He goes into a bit, but not a ton, I could have used more.
I like their products a lot; I wish they were a bit less self-promoting, as it is in fact the case here.
Awkward, indeed.
I cringe when I see companies try to use a competitor's misfortune to their advantage.
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).
https://get.slack.help/hc/en-us/articles/204067366-Delete-a-...
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
I cannot imagine replacing Slack with it for all company or team communication though. It's not remotely polished enough.
Yes, but:
1. We always have to combine the likelihood and incidence rate of threats with the magnitude of damage. I do not personally subscribe to this thinking, but some bloodless financial types will suggest that you can compensate harassment victims, but a major security incident could cost you the entire company.
2. Insert animated gif of a little girl asking, "Why not both?" Companies can and must address threats like sexual harassment AND exfiltration of sensitive data.
If you end up signing-up, follow me @ https://keybase.io/jbales
However, for the issue mentioned in the post, wouldn't 2FA have saved him? Supposedly, the compromised credential is from 2015.
If the bad guys are dumb and just were there to passively steal passwords then almost anything works. But if the bad guys are paying attention and stealing authentication secrets then it breaks down like this:
Passwords: Stolen if used while bad guys could watch
TOTP/MOTP/ similar software one time codes: Seed gets stolen by bad guys, they can generate the same codes as you now.
SecurID/ similar key fob type one time codes: Seed gets stolen by bad guys, they can generate the same codes as you now.
SMS: Now bad guys know your phone number. In a targeted attack they will "jack" the number and cause even more havoc, but you might be safe against script kiddies
U2F (or WebAuthn): The server doesn't know any secrets. It knows a cookie (meaningless gibberish except to one FIDO device) and a public key (public). Stealing these is futile and cannot be used to impersonate the user.
TOTP and SecurID surprise people because they forget that although the credential transmitted is just a one-time code, the _server_ (which bad guys broke into here) needs to know the same seed as the user does to get the same codes.
For whatever problems Slack has, at least I know if there is a new version that I need to install.
4.2.1 was a bugfix release that only affected Linux and BSD, so we didn't push out Mac or Windows releases for it.
Interesting, is this relatively recent? It didn't update for me, but I hadn't opened it in at least six months.
Also, that CLI command should probably be wrapped in a "Check for update" menu option.
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.
What's sometimes even better than that, is not using Slack at all.
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").
Reminds me of the time Amazon learned that using S3 to host status indicators for S3 is a bad idea if S3 goes down.
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.
.. or exploited/hacked a random cheap server to use to proxy their requests and have access to high speed 100Mbit/1Gbit downloads/uploads of Slack data.
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.
Poor security practices are poor security practices despite conflicts of interests, and Slack's are certainly extremely poor.
They have a lot of high quality security features and you can see they actually work because they alerted Max that his account was compromised.
Saying their security practices are extremely poor based on an incident they had in 2015 when their company was 1/20th the size it is today is ridiculous
Regardless of the issue, that still reflects very poorly on him.
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.
Same applies to a bunch of other companies...
How does Keybase make money?
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.
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?
disclaimer: I work for Keybase
Do you have any insight on why I shouldn't be concerned?
[1]: since I don't have clear funding motivations I'm referring to it as magical.
- iOS only
or
- an extremely-crypto/privacy-aware family who is concerned that although end-to-end encrypted, there is no out-of-band user-validated key exchange (e.g through a digit code or QR-Code) or prior validation (e.g per-key TOFU) of the other party's identity or update to their keys. Which means that theoretically Apple could insert a new key in the user's set (there is a key per user's device for perfect backward/forward secrecy†) anytime to MITM/intercept messages and you would not be able to monitor it††.
† This is obviously defeated by Messages in iCloud (which you can disable) but the iMessage protocol has this built in.
†† Of course if there was some feature like that, Apple could also make such a key hidden in some way because they also control the Messages app code.
I'd prefer to keep iMessage, but you know, walled garden. Lol.
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.
> 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??
> what we did use it for, which was discussing outages of our own product
You can't use Keybase to communicate about why Keybase is down :)
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.
