Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: If your company cares about security, why does it use Slack?
39 points by misterrobot on June 28, 2017 | hide | past | favorite | 69 comments
It's insane to me how many "security conscious" companies use Slack purely out of convenience.

The fact is, it's an enormous, centralized application written in PHP (not always a bad thing, but certainly not a language that keeps you from shooting yourself in the foot), with a massive target painted on its back.

How is it acceptable to you to use a chat solution hosted by a third party? Why not use an alternative you can host yourselves? It's just a matter of time before there's a huge incident.



Umm... why do people always assume "hosting it yourself" is more secure and not less? Do you have Slack's security expertise and budget? In my experience when small to mid-size companies attempt to manage security themselves they do a passable job but are convinced they are doing an excellent job - until they get hacked.

Larger companies usually have the budget, tools and expertise. But even then there are lots big companies with mediocre security too.


Corollary question: Why do you assume that Slack's security expertise and security budget is greater than your own?

All we can do is assume that Slack cares about security enough to be sufficient. Last I checked, they didn't have any form of compliance certification, yet HIPPA, PCI, etc. compliant clients use them without reservation.


> Why do you assume that Slack's security expertise and security budget is greater than your own?

I don't assume it. I know it for a fact; I've met some of their team and I know others by reputation. And I'm not exactly a slouch when it comes to this stuff (I don't eat and sleep crypto but a large part of my business is building secure infrastructure/consulting on the systems running on that infrastructure for regulated as well as non-regulated environments).


Slack has, publicly, a multi-member security team! That's entirely focused on the chat system that I don't have to put any of my teams time towards.


I'm curious...

Which is more secure?

A) Slack.

B) Open source software on a LAN accessible only through physical entry, SSH, and/or a VPN.


I would say that Patchwork which runs on SSB protocol is more secure than Slack (if used on your LAN) and it's written in a freaking javascript.


I'd vote slack.


> I'd vote slack.

Then I suggest you put more effort into securing your LAN situation because that is a vote indicating your belief your workstations are insecure.


If you don't assume your user/dev workstations are insecure, you're going to have a rough time in life.


I'm pretty confident in saying that 95% of companies have worse endpoint protection, local network protection, cloud protection, or the intersection of any two or three of those things than Slack does application protection. Maybe more than 95%.


You should look again:

https://slack.com/security


OK: Slack is not currently a PCI-certified Service Provider.

I was also a bit surprised what they consider out of scope for their bug bounty program: https://hackerone.com/slack


I can't begin to fathom a use case for slack where you would put card data in the system...


You've never met a call center.

They've sent bug reports with credit card data they've typed in during a phone call through a variety of insecure methods.

They've also written people's credit card info on sticky notes.

Trust me, the horror that is card data and a call center is scary.


How about a bug report screen shot? Lots of non-security conscious users don't understand why this could be bad. It's your (making the assumption that "you" in this case is a Slack Administrator) job to protect them from themselves.


The use case is user error. I have also seen no shortage accidentally people paste passwords into Slack as well


HIPPA, PCI, etc. compliancy doesn't actually mean you are secure, it just means you are compliant. Take ransomware attacks for example, most of the bigger companies that get hit and have no working plan to continue their business are compliant to all sorts of things, hell complete governments are in that category...

Compliancy only tells a story about management and how many MBA's you have, it doesn't actually mean you have good security. Only being compliant isn't going to help you not get data leaks or data loss!


You're correct - it doesn't mean you're secure. It does, however, point out that you're putting some thought and effort into security. PCI requires remediation plans or justifications to pass, as does HIPPA.

And, for better or worse, you need your service providers, including chat, to be compliant. If your company were to leak PII via Slack, your company would be in pretty hot water for putting PII on a non-certified service provider.

At least if it were certified, you could say "we've done our due diligence to protect people's PII". Perhaps only important to leadership and lawyers, but still important.


In this case, however, Slack is certified.


I happen to know a few people on the Slack security team from a prior job. SalesForce, another SaaS business people trust to manage all their data.

There's no question that Slack's budget is greater than my own. They have a large, full-time security team. I have a bit of attention from myself or a colleague when setting a system up.

There's also no question their expertise is better. These are life long security professionals with direct experience at other SaaS companies.


I think both options have tradeoffs.

If you use a service, you're outsourcing your security to perhaps more competent people, but you're making yourself a larger target.

Self-hosting makes you a smaller target, but you're taking all the risk on yourself.

Neither is a panacea.


I agree the answer is shades of gray. Personally I prefer self host because I am able to get more visibility on my threat model that way. If you aren't equipped to use that information then I see little benefit to it.


> Umm... why do people always assume "hosting it yourself" is more secure and not less? Do you have Slack's security expertise and budget? In my experience when small to mid-size companies attempt to manage security themselves they do a passable job but are convinced they are doing an excellent job - until they get hacked.

I'm not exposing it to the WAN, just the LAN. :\

I don't think people really appreciate how massive of a security difference that is. It doesn't matter how big your budget is if you sit on the WAN all day. Someone will _always_ tag you eventually.

LAN with hardened VPN/SSH setups are virtually impossible to get into in a software-is-at-fault kind of way. And even if they did, they'd then have to launch the attack from someone's workstation at which point you've already been compromised anyway.

Oh, and then to get to the chat service they'd still need to break the security of an open source chat service which is non-trivial.


Your LAN is protected Only if you know that no workstation which connects via VPN, WiFi, or cable can ever be compromised elsewhere and then connect. Which is clearly not possible unless your workstations are air-gapped and immobile, with no USB ports, etc.

The majority of non-trivial breaches involve some sort of pivot or lateral movement inside the "protected" LAN. These often originate from a workstation.


Because when you host it yourself, it can be off of the public internet.


That's not very useful for your CEO/CTO/CFO/sales/etc when they are offsite or traveling.


A VPN resolves this issue and provides encryption and authentication.


A VPN is non-trivial to set up correctly. Have you set up an internal DNS to prevent leaking the domains from requests? How about IPv6 leaks? There are many things to consider, and I wouldn't trust a random programmer to do it correctly.


I wouldn't trust your programmer much at all if they couldn't configure OpenVPN with correct DNS settings, given some time.


Many good resources exist: https://www.linode.com/docs/networking/vpn/set-up-a-hardened...


and what about if your network is compromised? For most small-medium businesses, that's more likely than Slack being compromised.


Slack already had a public compromise. Most small businesses haven't been publicly compromised.

I'm not saying it's safer to self-host. There are a ton of foot-guns with operating your own IRC server.


It mostly depends on if you're a target. I must have missed when Slack was compromised, but I'm willing to take the risk of Slack being hacked, as I'm not a target. Im a fan of the methodology that bigger company = more secure, although that's obviously not always the case.


That said, you bypass a ton of those foot-guns if you just stick everything behind a corporate VPN with 2FA and the appropriate security. As long as the VPN is secure, everything behind it is secure.


> and what about if your network is compromised? For most small-medium businesses, that's more likely than Slack being compromised.

If your network and/or workstations are compromised, it is _over anyway_ because they have all your data. This is one of those situations where you are saying "What if they decapitated me? Slack might still be secure."

I mean, technically, you are correct but it isn't relevant because you are dead.

If you think such a business can survive a pentest from an employee workstation...XD


Hosting shit yourself != more secure, and only someone with a highly naive view of their capabilities as an organization would make that assessment. Facebook is written in PHP too, but you don't see that being a huge secure vulnerability, do you?

Slack has an entire security organization dedicated exclusively to securing its stuff. My security team is focused on securing our operational systems.

Do you run your own bank? How could you outsource something so critical (literally all your money and financial details!) to a 3rd party who doesn't even let you audit their stuff?! It's just a matter of time before there's a huge incident.

Do you run your own electrical generation facility? How could you outsource something so critical to a 3rd party? I bet they don't even have an SLA!

etc. etc.


The usual answer is "the self-hosted options are worse to use and make people hate them". Mattermost is a prime example, it's really clunky and uncomfortable to use. I like Rocket Chat and have hosted an instance of it myself, but it's shot through with inconsistencies and annoyances that Slack just doesn't have.

The notion that self-hosted is more secure is curious, though. Slack's security team is almost certainly better than yours, for most--not all, but most--values of "yours". You might be the rare exception (I'm certainly not, and I build reasonably secure systems by habit, if only because I don't have the time or money to focus solely on a chat service), but I doubt it.


Hi Eropple, Mattermost team here. Sorry to hear your Mattermost experience wasn't smooth. Could you share an example or two of what we can improve? We ship new releases every month on the 16th. If there's something you feel should be corrected I would love to see it addressed. There's over 500 contributors on the project and thousands of companies that deploy it.

In terms of security, I would propose that professionals dealing with sensitive data are often more comfortable with a self-hosted solution. As an example, former members of the CIA, FBI and NSA have used Mattermost on national television in the US: https://about.mattermost.com/open-source-mattermost-software...


I'd be a lot more inclined to spend time responding to you, because I certainly have a list of beefs with the software, if you didn't immediately launch into pimping your stuff and trying to sneak in how wrong I am. That's "I choose to exhibit the social acuity of a space alien" behavior.


TLDR we chose Mattermost over Slack because of security. https://www.mattermost.com

We recently evaluated many chat systems for a large tech consulting project that includes security needs.

Slack was the frontrunner because of ubiquity, ease of use, plentiful third-party integrations, openness to free areas, and helpful in-person meetings with the Slack staff.

We picked Slack for our informal connections with external developers for non-confidential discussions.

For our own teams' use, I really like Ryver. The security is better (IMHO), the team-oriented features are stronger, and the billing is much clearer. The Ryver team is fully open to discussions about how to grow the platform and improve the security.

Ultimately the security team chose self-hosted Mattermost. We liked the combination of intranet deployability, plus a ramp toward security compliance capabilities that we do need for a few projects.


Perhaps this is a bit immature of me, but I despise Ryver for their ads that they put on Twitter a few months (a year?) back where it was completely trying to discredit Slack while having a sub-par UIX itself. Maybe I'll give it another look in the near future.

EDIT: Security-wise, I would think Slack, as a bigger company, would have better security, but that's all assumption. Do you have anything to back up the idea that Ryver is more secure? If so Ill definitely give it another look.


I agree with you about the UI/UX. For security, it depends on your threat model.

My threat model emphasizes ease of security by normal users. For example, is it easy for my teammates to see when they're in a public area or private area? Can my teammates manage access controls the ways that they want? IMHO Ryver is better at this than Slack.

My sec team's threat model emphasizes the underlying platform getting hacked. IMHO Ryver and Slack are both SaaS, so both in the same boat on this: the info is outside the firewall, which incurs legal issues, compliance issues, revocation issues, etc. I believe that SaaS providers can be excellent at security, yet the SaaS target is much bigger, and the alerting is murkier, and revocation is not thorough. This is why we chose Mattermost for secure chat.


The most successful software apps in the world are built with PHP. Facebook, Wikipedia, Slack, WordPress, Flickr, Yahoo. Users don't care about your tech.


PHP does have a track record of terrible security, though. WordPress and Yahoo both still have reputations as security clusterfucks; Facebook did too until they grew up as a company and were able to hire some really good security people.

However, most of the backend services at Slack (the ones you'd actually want to attack) aren't even in PHP anymore: according to their job reqs, they're in Java and Go.


It's not just the setup of a self-hosted solution, but maintenance, and otherwise. If you look at the enterprise space, bigger and bigger companies are becoming comfortable with cloud-hosting of services. Growth of companies like Okta demonstrate that shift. As far as it being acceptable, I think there are a few things to consider:

1. The Slack model is such that your staff could start using it without even getting permission from the top. This is the Slack strategy for sales. It comes into companies from the bottom, so companies are more responding to the fact that their employees are using it vs bringing it in from the top.

2. Yes there are risks with cloud products, but risk is a cost consideration so you look at cost impact to the company of a breach and you compare that to a self-hosted high maintenance solution. This is a much more difficult calculation and it really depends on the size of your company, the value of the information Slack will be holding, etc. It's also possible Slack could be seen as more secure because an internal system breach may not include a complete Slack hosted breach. It could be seen as data segregation and diversification.

3. Slack is not the only company that is making inroads here. Slack is known well in the tech industry, but less-so in other industries. Microsoft is a giant because Skype for Business is huge, and there's many others.


Well that's a loaded question... this could easily be rephrased as "How do your companies align the need for security with the use of cloud hosted services like Slack?"

But then again, that assumes an honest question and not an agenda...


You should assume that chat logs can become public at anytime, if you host it yourself or not. Don't put sensitive/embarrassing unencrypted information in chat or email. People forget this is still data at rest.


A corollary of this is a saying a friend's dad used to have, "If it isn't in writing, it doesn't exist". Of course, with VOIP, video, etc, it is more, "if it isn't done in person via voice, it does exist". If it would be damaging to leak, seriously consider whether it should be written down at all, especially in casual conversations.


Yup.

At minimum, in the case of a lawsuit, they will be subject to document retention and subpoena.


I have an analogy.

Why would a zebra have evolved to have black and white stripes? You could see a zebra from miles away due to how it stands out! Yet.. when it's in a herd of zebra, it's hard to pick any individual one out, and that's why the pattern works.

And so it goes with using services like Slack, Gmail, S3, etc. My account on its own may not be the most secure thing ever but it's hidden in such a large pool of data - much of it far more valuable than mine - that the safety of the herd becomes relevant.


Because they care about convenience as well, and that value outshines the elusive "lack of security". You'll probably end up with much less secure option if you try to host one yourself, unless you're really dedicated to the chat app, in which case you have your priorities wrong. You should be focused on your own product.


We discuss nothing sensitive in chat, just as we refrain from doing so over unencrypted email. Pretty straightforward.


>> It's just a matter of time before there's a huge incident.

I suppose that's correct. When (or maybe if, but probably when) Slack gets breached/hacked/owned it's going to be huge because a huge number of people are going to lose something that they didn't want to lose.

When I'm self hosting something and that thing gets breached/hacked/owned it's going to be huge for me because I and/or my company are going to lose something that we didn't want to lose.

I don't believe I can keep my stuff much safer than the big guys, though the point about Slack having a massive target is a good one. Maybe that makes it less secure?

I really don't know what's better for us in the case.


Really depends on if you're a target yourself. If someone is trying to target you specifically, use Slack as it's much harder. If you're not a target and are worried about Slack in general and have the budget to run your own stuff, do that.


I think the point is much "do I trust a third party service ?" not regarding the techs involved.

I read a story from a blogger [1] who was visiting an Airbus facility for an A350 presentation and when he came back in plane, his neighbor, an Airbus sensitive contractor, was editing internal documents on a Chromebook using google doc. Yep. No fear.

[1] https://korben.info/vous-proteger-de-lespionnage-industriel-...


It seems like Quip, the document service, should be a much bigger concern:

Based on their security practices document, they seem to store documents unencrypted on their servers. It's encrypted in transit, sure, but not in storage? I was shocked when I found out.

https://help.salesforce.com/servlet/servlet.FileDownload?fil...

At least Slack encrypts data at rest https://slack.com/security


Have you tried Semaphor from SpiderOak? We provide a secure Slack alternative designed using our No Knowledge architecture--meaning that we (SpiderOak) know nothing about the encrypted data you store on our servers. This approach allows a third party to host the data, making it way more convenient from an operations standpoint. Slack provides convenience, but it severely lacks in security.


Because its convenient and easy to use.


Weird, this post appears to have been nuked from orbit. What happened?


Well, I flagged it and I imagine others did too. It's not an 'Ask HN' it's 'Yell my opinion at HN while pretending to ask something'. Which isn't that great.


You're kind of right. At the same time, the comments appear to be answering the question, so...


But, perhaps more relevant, the post doesn't say "flagged" on my end (which I'm pretty sure they do when they're flagged).


It has to be flagged enough to get that tag. As to 'commenters are commenting', that's not the criterion for what makes a good post. You're basically trying to stir up a silly fight. Sure, that gets upvotes and comments. It's still bad.


Hm, ok. Would it have been OK if I hadn't posted it under "Ask HN"? Surely this site supports sharing opinions like this one in some contexts -- it's not like this was a political shitpost or something. Right?


Probably but the result would have likely been similar. The standard is supposed to be a bit higher than 'isn't a political shitpost'. If you have something interesting to say about this, you can always write it up as a blog post and submit that. If you just want to vent a bit, it's probably not going to get too far as a post.


You could say the same about using Windows.


Php is more secure than C.


This is so only for the core language with no libraries. API provided by PHP until recently typically provided convince over any notion of safety leading to terrible bugs.

For example, it is hard with C API for databases or templates to get SQL injection or XSS bugs. With PHP it is trivial and such usage still simpler than safer versions.


A selection of reasons I have heard.

- Because self hosted HipChat / IRC / XMPP / is not cool enough.

- Because we are all supposed to use Lync / Skype for Business, but it sucks on OSX / Linux / in general.

- Because we are a small team, and maintaining a chat server is too much for us.

- Because we don't know (or want to know) how Slack works.

- Because shiney, such giffy, such memes.

- Because its free.

- Because my software engineers don't know how to connect to IRC

There is varying levels of good and bad reasons in there. (personally I am still a irrsi / IRC person, but I fully acknowledge I am not in the majority anymore)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: