How Slack Stays Secure During Hyper Growth
heavybit.com
heavybit.com
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://www.wired.com/2017/03/hack-brief-slack-bug-everyones...
2^16, 2^32, and 2^64 are a lot easier to understand than 6.5 * 10^3, 4.2 * 10^9, and 1.8 * 10^19
They could fix it afterwards, but they don't even do that.
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.
Not to mention, in most clients, it took significantly less than ten seconds for the text to appear on the screen after you started typing.
I used to think maybe it could have been before I was required to use it last year, but no, it's not. It is the worst chat application I have ever used (maybe tinder is worse heh, but at least the keyboard latency is below a second.) It's almost comical how bad it is.
In my (limited) experience this seems true to me.
I've used Slack for a couple years in purely open source / social / educational settings and can't really fathom how it could be described as comically bad. There are aspects I dislike, but overall it feels like it solves pretty well the problem it set out to address.
A lot of the hate seems to be around the the fact that it gives employers yet another method of disturbing work flow and creating accountability around meaningless metrics (response time or participation in pointless chats).
Instead of increasing productivity, it turns the entire workday into a meeting, with all the downsides of a traditional meeting.
But, again, those are all complaints about the setting and expectations surrounding the product, not the product itself. Slack is quite good at what it does, by any reasonable measure in my view.
Reasonably secure against crimes of opportunity, perhaps. Secure? Highly doubtful.
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...
In all seriousness, and as much as I'm willing to assume that they've a good team, the title is cringeworthy.
https://news.ycombinator.com/item?id=9277370 (March 2015)
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.
only to leave the installation out of date with critical vulnerabilities and missing features that the hosted installation would be on top of.
Probably because in general self-updating goes against the control on-prem is supposed to give enterprises, especially when they're afraid of breaking critical workflows.
And it’s not like nation states can’t attack companies directly.
That being said: A company-wide Discourse forum works much better for knowledge sharing and discussions.
So if your 'resonable expectation of security' involves slack not being able to read your chat history, you are going to have to give up search.
Otherwise, the reasonable expectation of security will have to rely on trusting slack to properly secure their side of things.
or don't provide a search service, have client have its own local index.
That would be an incredibly insecure method of encryption.
> or don't provide a search service, have client have its own local index.
Yep, I would prefer an on-prem solution.
No. Slack does not implement searching logic on the client. If the key is only known to the client, and the search logic is only known to the server, you can't search anything.
End-to-end encryption is fundamentally incompatible with server-side search, because it mandates that the secret key can never leave the client. You can't reconcile these two features without efficient homomorphic encryption (which does not exist yet, and will not exist for the foreseeable future in any practical sense).
The move to 3rd party hosting for super-sensitive internal stuff like this baffles me.
The tricky part here is defining who the user is. If you're implementing end-to-end encryption for data on a per-employee basis, you're back to square one with a self-hosted server. But if you're implementing end-to-end encryption for data on a per-organization basis, and the organization has a self-hosted instance it controls, then yes, end-to-end encryption is compatible with organization-wide message search.
Actual content of the messages could be encrypted separately. Client would send separately the selected terms for indexing and the content for each message.
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.
that's not unreasonable at all
More to the point, end to end encryption is necessary (but far from sufficient!) to keep communication secure. If you don't need your communication to be secure, that's fine.
The thing about the modern, networked world, is that you don't have to be the CIA to face a sophisticated, global threat model.
The only way that’s obvious to me is searching locally on your device. This will not be a happy experience for any moderately sized organization.
Especially not if I just want to quickly check my messages from a web browser.
Some data can always be locally stored on the device and searched (maybe anything I've typed myself, or particular forums I search frequently). Some data could be downloadable on demand (if I want to search all of my DMs with a given person, it's reasonable even on a phone to download that entire 5MB chat log locally to do the search).
Another way is to trust an archive/search server temporarily with the decryption; if you trust it right now, you can decrypt your logs on that server, do the search, then wipe it. That's a lot safer than all of those logs sitting around forever for anyone who pops the server at any point in the future.
Another option is an enterprise chat server (e.g. Mattermost), or having some kind of chat log server run by the enterprise which is for searching, but use a hypothetical end to end encrypted Slack for routine communications.
Making this all happen as transparently as possible and as efficiently as possible, with clear user security expectations, is what the "company" level stuff would be.
Allowing different security models for different groups would make sense, as long as you could communicate the security models to users and admins somehow.
e2e for direct user to user makes sense.
I disagree, corporate chats still have plenty of reason to want access to historical user-to-user chats. Ignoring the cynical reasons, institutional memory isn't confined to channel chats.
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.
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.
If someone gets into an email server, they only get the mailboxes on that server.
By centralizing slack, they've made it the ultimate target worthy of people with 0-days.
So you’re opposed to Gmail and Outlook as well? Do you run your own mail server? Does your organization?
Security has diminishing returns of efficiency with respect to how much safety it adds at the cost of removing some usability. I stand by my point: in practice, end-to-end encryption is not desirable for many applications, and that’s completely fine. We have entire fields like application security precisely because it’s inappropriate and untenable to lean on maximal computational security for all of our confidentiality, authentication and authorization requirements.
The crime rate is hinged on when a crime is detected. If I'm forgetful and you snag one of my power bricks I might just think I misplaced it or it got thrown away. If you've been embezzling and I can't tell yet I can't report it.
Crimes are being committed whether they get reported or not. We count on them having personality flaws like poor judgement and thrill seeking assuming they will eventually be caught. But if there are people who can go into a casino once a year and spend exactly $100, why can't there be criminals who steal $100 once a year and never get caught?
In the UK the survey is called the British Crime Survey and it's pretty robust in it's methodology (although not without criticisim). https://en.wikipedia.org/wiki/Crime_Survey_for_England_and_W...
What a confusing post.
The crime rate is a known political tool that is actively manipulated for political gain (stop and frisk anyone?). Everyone knows that being "tough on crime" is moral statement not a statement of fact. Outside of crime averages that operate on a continuum the crime rate is so subjective as to almost be useless.
I would say "the crime rate is down" as an argument is roughly equivalent to believing that any given president has an impact on the DJIA. Look at the cover of the NYPOST yesterday[0]. Attributing a president who has been in office for a year with anything having to do with the economy is almost always untrue [1]. In fact, if anything it's more likely that Trump is benefiting from the policies of his predecessor.
So in conclusion the "crime rate" is never up or down, it's just one tool in the political handbook to try and manipulate people with fear, uncertainty and doubt. As a basis of establishing policy it's almost always rhetoric. To further elaborate on your comment, it has less to do with when a crime is "detected" and more to do with what is a crime.
[0] https://i.imgur.com/uifDjWI.png
[1] https://fivethirtyeight.com/features/a-presidents-economic-d...
Lower detection of crime doesn't mean less crime and higher detection of crime doesn't mean more crime.
The point is the crime rate as a tool to understand the effectiveness of law enforcement is useless.
This is a common problem I see all the time in "fact based" circles. People care more about the fact that the needle is moving rather than questioning if they're even measuring what they think they're measuring.
There's no reason to believe Slack would ever be able to detect someone exfiltrating chat logs.
How about
Crimes are being committed whether they get [identified] or not
"Well, we can't PROVE someone isn't exfiltrating chat logs, therefore slack can't really be secure"
What is the value of this statement? How is it an indictment of slack's security?
From the podcast :
"Geoff also concludes that companies should encourage basic security hygiene rather than seek a silver bullet that does not exist."
So despite good law enforcement people get away with crimes. What exactly is the insight there? What is the actionable information for both slack and law enforcement of these "unknown unknowns?"
It's pointing out that you aren't very secure when you are operating in a model where it's even possible to leak all of your client records without even noticing.
Compare slack to something with actual end-to-end encryption and you'll start to see the difference.
This is why murders are a gold standard for crime statistics. Most people agree murders are bad. And the rate at which murders become disappearances tends to be stable across time in a given society (but not between societies).
The idea that I should expect all my gmail messages to end up in a torrent somewhere is a pretty audacious claim. I don’t pretend to believe that it won’t happen, but if it does, I can’t pretend I would have been more prepared than google when it comes to hosting my own email.
I think this. (In the context of a company, communications where the company doesn't hold all the keys.) Insecure modes aren't useless. But they certainly shouldn't be used to share sensitive information.
One of the simplest issues I can see is the search functionality, something I use daily in Slack and would sorely miss not having. Elasticsearch requires access to the contents of a message to index it (basic requirement).
Another thing that would become difficult would be adding people to a group, although my technical knowledge in this area is perhaps not massive, my thoughts are that if a user can join a group with another key, surely a Slack attacker would also be able to add their own key?
I'm sure there are many other things that ensure Slack cannot be E2E encrypted since it stops a significant amount of the logic they can do (they would become a dumb proxy), similar to why Google hasn't gone E2E.
As I said, not every communication mode must be secure. Slack trades off security for other features, and that is okay.
It's odd for Slack to be beating their chest, however, about staying secure when security is not a feature they optimize for.
Isn't that obviously true? It's clear that your data can be taken from you and sent to whoever they want at any time, all without your knowlede. Either by Google themselves, or a malicious actor who has access to Google's data.
How is this not the very definition of insecure?
Don't get me wrong, securing your own server isnt for everyone, but Google is an already known compromised system.
It’s certainly reasonable to expect a platform owner to be able to control access and integrity of customer data without encryption, for many use cases.
It's such a high-value target that it's almost inevitable.
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.