
How Slack Stays Secure During Hyper Growth - maliapowers
https://www.heavybit.com/library/podcasts/the-secure-developer/ep-14-how-slack-stays-secure-during-hyper-growth/
======
ajsharp
Slack is an excellent product with a seemingly top-notch engineering team. But
Slack has had multiple published security events the last couple of years.
Including a DATABASE BREACH. E.g. someone either left a db open to the public,
or didn't have ssh password auth disabled, or any number of no-brainer
security practices.

Again, no hate for Slack -- growing as fast as they have is an incredible
feat. But heavybit is, um, pushing the definition of "secure" with that title.
LOL.

* [https://slackhq.com/march-2015-security-incident-and-the-lau...](https://slackhq.com/march-2015-security-incident-and-the-launch-of-two-factor-authentication-3cdcc8efba29) * [https://www.wired.com/2017/03/hack-brief-slack-bug-everyones...](https://www.wired.com/2017/03/hack-brief-slack-bug-everyones-worst-office-nightmare/)

~~~
anticodon
Slack is not an excellent product. When I'm using 3g tethered connection Slack
experience is unbearable. It constantly loses connection. Why is simple text
chat is so bandwidth hungry. I'm surw it's due to bad engineering. IRC was
much more reliable on much worse connections.

~~~
RyanZAG
People often confuse engineering and design. Slack has a very good design
team, the UX is far above IRC or competing solutions and everything flows and
works in a way that most users expect. The engineering itself is not the
strong point, that's for sure. Slow, bandwidth hungry, memory intensive,
strange syncing problems, security issues, etc.

~~~
crdoconnor
It's certainly pretty. It reminds me of that quote by Joel Spolsky - "people
ridiculously overvalue aesthetics and beauty when evaluating products. It's
one of the reasons iPods, and, for that matter, Keanu Reeves, are so
successful."

I don't think usability-wise it's all that great though. If you have multiple
chatrooms in multiple slack organizations, it's a PITA checking on them all,
for instance.

~~~
ajsharp
On Spolsky's quote, wouldn't that mean people _undervalue_ aesthetics and
beauty?

~~~
hansl_
Engineers undervalue it, users overvalue it compared to other criteria. Mostly
because users are not engineers and so have no way to look at why a product is
engineeringly superior; they can only look at how easy/simple it is to use.

------
ComputerGuru
The idea that anyone could think of Slack as a "secure" communications
platform is laughable. There's security and then there's security theatre.

Reasonably secure against crimes of opportunity, perhaps. Secure? Highly
doubtful.

~~~
sidcool
Are there any known security vulnerabilities or incidents you can elaborate?

------
mcculley
We tried out Slack recently. I was reticent to replace our existing XMPP
server with an external service for security reasons. When I started the
Electron-based desktop app, it tried to connect to lots of third-party
services. That was enough to scare me away:
[https://twitter.com/mcculley/status/941728005617078272](https://twitter.com/mcculley/status/941728005617078272)

~~~
e12e
I recently had a _quick_ look at mattermost, zulip, matrix and rocket.chat. Of
them, rocket.chat was the only one I could get up in 5 minutes, just from a
docker-compose file. I assume they're all similar for a full production set-up
- but for a dev test, rocket-chat came out far ahead.

Mattermost actually have a dockerized setup - but it didn't work without more
fiddling than I cared to do for a test run.

I'm not all that happy about rocket being a meteor/mongodb app - but if you
for some reason want to move away from a working xmpp setup (why?) to
something slack-like, you might want to take rocket for a spin.

I've seen people complaining that the clients for rocket are bloated - but
afaik they're not as bad as slack (I've just used the Web front-end and
Android client).

A curious fact: from the wording on the doc page, you might think this needs a
lot of twiddling ("Create docker-compose.yml based on our example..."). But
it's clearly commented, and someone apparently verified that it _actually
works_ :)

[https://rocket.chat/docs/installation/docker-
containers/dock...](https://rocket.chat/docs/installation/docker-
containers/docker-compose/)

------
ddebernardy
Slack gets hacked in 3... 2... 1...

In all seriousness, and as much as I'm willing to assume that they've a good
team, the title is cringeworthy.

------
Pyxl101
Slack has been hacked before. Previous discussion on HN:

[https://news.ycombinator.com/item?id=9277370](https://news.ycombinator.com/item?id=9277370)
(March 2015)

------
staunch
More like "How Slack _Thinks_ It Stays Secure..."

A sophisticated attack against Slack would be for the purpose of maintaining
long-term access to chat data. There's no reason to believe Slack would ever
be able to detect someone exfiltrating chat logs. They might catch some
attacks but customers can not rightly expect that that their privacy is being
maintained. Data being stolen is _more_ likely than not.

Slack chat should be treated like semi-public communication, with the
expectation that it will all end up in a torrent file at some point.

The idea that you can "secure" unencrypted text chats using a Security Team
with Executive Leadership is pure theater. If Slack took security seriously it
would utilize end-to-end encryption.

~~~
dsacco
Taking your criticism to its logical conclusion, are you asking for end-to-end
encryption on every online mode of communication in order to consider it
secure?

When security engineers and cryptographers analyze an application, they frame
their analysis in the context of security goals, threat models and categories
of risk. They don't begin from the perspective that application security is a
boolean property - i.e. that the software is either secure under the most
strenuous of requirements or simply insecure. That's not how any of this
works. All security analysis exists on a continuum between safety and
usability.

Not all messaging software _needs_ to be secure enough that it could be used
as an anti-censorship platform or to facilitate secure communication from
journalists in totalitarian regimes. For most companies it's enough that their
data is protected through strong application security mechanisms, and Slack
devotes significant resources to that task.

In addition, customers choose to use Slack for its features. As others have
pointed out, some of these features (like message search, or an audit log for
direct messages between team members) cannot exist under an end-to-end
encrypted model. If you want to use _Slack_ , that means you want to use
Slack's _features_. It's pointless to demand Slack to become something it's
fundamentally incompatible with. If you want confidentiality assurance at the
highest echelons of computational security, just use something else.

~~~
snowwrestler
There is a qualitative difference between having your staff communicate with
each over Slack, and having your staff communicate with each other over email
or local chat within the firewall.

For one thing, if you run applications on servers you own, you and only you
will get the subpoena for that information. You and only you will know if that
information is breached or exfiltrated. Under 3rd party doctrine, Slack does
not need your permission to provide your data to law enforcement, nor are they
under any obligation to tell you that they did.

And while I haven't read the Slack legal agreement for a while, I would be
surprised if there is an ironclad SLA around their duty to notify you if they
are breached, or to provide all details about who got what when.

The alternative to Slack is not always Gmail and Gchat, in every institution.
Running licensed applications on owned hardware is still a thing that many
organizations do for the reasons I list above, and others including document
retention policies.

And yes, employees with mobile devices can certainly be encouraged to chat
over WhatsApp, iMessage, or even Signal instead of Slack. Or at least they can
be empowered with an understanding of why they might want to put certain
sensitive information there instead of in Slack.

~~~
danenania
I think the key is to make sure that developers and other employees understand
the tradeoffs. This applies not just to Slack, but also to email, Github,
cloud storage tools, and even browser extensions.

Apart from easy setup and good ux, these tools provide ideal integration
points for third party plugins that can do all kinds of amazing things for
productivity, sales, business processes, code intelligence, etc. etc.

In my view, this is all well and good, and we shouldn't be looking to axe
these benefits by demanding self-hosting or end-to-end encryption for
everything.

Instead, people need to understand what they are and aren't appropriate for.
If your browser has 20 extensions installed with access to every page's
data... that's cool--I'm sure they all do useful things, but would you sign in
to your bank's website with 20 strangers looking over your shoulder?

Same deal with Gmail, Slack, and Github. They all have their place, but they
were not designed to store e.g. application secrets securely-- _especially_ if
you're also using third party integrations (which, why wouldn't you?--it's a
big part of the value they offer). None of this is a problem if you just draw
the line in the right place.

Quick plug: this issue is exactly why I started EnvKey[1], a 1Password-like
service that keeps application secrets securely in sync across development and
server environments so that developers aren't tempted to share them over third
party channels in plain text. If your secrets management strategy involves
exposure to _any_ third party, you should probably re-evaluate what you're
doing. EnvKey offers a very quick, hosted, end-to-end encrypted approach to
getting you on the right track.

1 - [https://www.envkey.com](https://www.envkey.com)

------
lima
The day Slack is compromised will be a fun one...

It's such a high-value target that it's almost inevitable.

~~~
kayhi
I thought it has been: [https://www.wired.com/2017/03/hack-brief-slack-bug-
everyones...](https://www.wired.com/2017/03/hack-brief-slack-bug-everyones-
worst-office-nightmare/)

------
chris_wot
The Windows client is buggy as hell. It makes me wonder how many security
flaws there are in there...

------
throwwwwaway9
Don't poke the bear

------
ransom1538
If you use slack:

1) create a slack channel name not related to you or your company. EG. channel
name 'foobarindustryyys'

2) require all users to use anonymous emails

3) delete the channel once a month

EG. If you run on eagames.slack.com you will get owned. Horribly.

