By the way, HipChat still has no two-factor authentication.
HipChat security notice
81–90 of 119 posts
Re: HipChat security notice
#82Earlier quoted context omitted.
> Open source code now carries a moral maintenance obligation? Yes, and it always has and it can't be discharged. Pay-it-forward is the right thing to do. > Do we say the same thing about any large company that uses openssl or any other open source libs that people use or depend on? I certainly do. A red line, I-will-quit condition is and always has been "I won't participate in the development of private forks of ope…
> Yes, and it always has and it can't be discharged. Pay-it-forward is the right thing to do. Interesting - it may be a nice thing to do, but I don't agree that there is any sort of obligation to the project just for using the project. > I certainly do. A red line, I-will-quit condition is and always has been "I won't participate in the development of private forks of open-source software" and I have at multiple empl…
It's not a "nice thing to do" and it's not really a moral issue. It's simply the point that if the security of your thriving business depends on a software component you did not author, you're obliged to do everything you can to ensure that component is safe for deployment, and for open source components one thing you can easily do is contribute to development.
There's really no way around this; it's a straightforward practical problem.
Re: HipChat security notice
#83Earlier quoted context omitted.
In my experience, using irc or xmpp mostly results in people not using it unless a) the team is largely technical or b) there's a common, easy interface like gchat used to be.
Why are you giving your employees a choice in the matter of something so important? Set up an XMPP server, tell them that's what is used for internal communication. Period. And if they're too lazy/dumb/entitled to download Adium/Pidgin and enter their email address+password; well, you should probably find better employees.
"Not using it" means "compared to using offline means for communication or just not communicating," not "compared to using an unauthorized online means for communication."
Your job as IT is to deliver business value. It's certainly possible that people not communicating is better for the business than people communicating over a hackable service, but it's not the conclusion most people have come to.
Re: HipChat security notice
#84Doubt this will be a popular view around here, but using a 3rd party service for internal business communications is just a bad idea. I've seen companies posting root passwords, ssh keys, salaries, internal financial details, etc in Slack and HipChat. Just waiting for a disaster to strike, adding value for every additional company to the target. Maybe this breach won't be the last straw, but it's a consistent risk. Y…
What about private code on GitHub? Email/files on Google? Heck, customer data in AWS?
You can host your own versions of them. For that extra layer of security, you can stick them behind a domain that's only accessable behind a company-wide VPN.
Re: HipChat security notice
#85Earlier quoted context omitted.
Quite a lot of organizations use Spark which is a straight up XMPP client, they also license an enterprise XMPP server.
> Quite a lot of organizations use Spark which is a straight up XMPP client, they also license an enterprise XMPP server. The same open source community (IgniteRealtime.org[1]) that maintains the Spark[2] XMPP client, also maintains OpenFire[3], a very good and easy to setup XMPP server. [1] http://igniterealtime.org/ [2] http://igniterealtime.org/projects/spark/index.jsp [3] http://igniterealtime.org/projects/openfi…
Huh... I was confused when somebody told me they bought an Spark enterprise server license... now even moreso.
I think they probably just bought a license for a commercial fork of OpenFire.
Re: HipChat security notice
#86Needless to say their (login) servers crashed from the pressure of people resetting their credentials. "Hey, you know what might be a good idea? Let's email all of the accounts at the same time using an Appriver blast!" Atlassian. I hate to hate you.
While I can see your point in this case I think it was the appropriate action, their ops team should've just beefed up their resources in conjunction with the email blast. Only emailing a rolling amount of your customers becomes a shit show of support, who do you email first? Who do you email last? How long do you wait between groups? For who is security important, your biggest customers, highest paying, most securit…
they dont have an ops team anymore it was all moved to a terrible new product that they hope will make people love them again source:former employee
Re: HipChat security notice
#87Re: HipChat security notice
#88Doubt this will be a popular view around here, but using a 3rd party service for internal business communications is just a bad idea. I've seen companies posting root passwords, ssh keys, salaries, internal financial details, etc in Slack and HipChat. Just waiting for a disaster to strike, adding value for every additional company to the target. Maybe this breach won't be the last straw, but it's a consistent risk. Y…
Is there a single case of a company suffering a loss because of a Github or Slack data breach? Is there a single case of a company suffering a loss because of their own systems being breaches? It happens all the time. Look at Sony -- their data would have been safer stored on DropBox than their own internal servers.
You claim "risk," of using 3rd party services but can you quantify it with actual data?
Slack's entire business is secure business communication. Are we to think that our teams are better than Slack's when Slack's core competency is secure communication?
Should companies install their own phone lines because the 3rd party phone companies can't be trusted? Is there not risk when your internal teams who aren't necessarily domain experts, are building and maintaining systems that are outside of the company's core competency?
The security value of doing it yourself is nothing but anecdotal and not based on any actual data.
Re: HipChat security notice
#89Doubt this will be a popular view around here, but using a 3rd party service for internal business communications is just a bad idea. I've seen companies posting root passwords, ssh keys, salaries, internal financial details, etc in Slack and HipChat. Just waiting for a disaster to strike, adding value for every additional company to the target. Maybe this breach won't be the last straw, but it's a consistent risk. Y…
My assumption has always been that companies large enough to have a security team also have better security practices than my small company. E.g. I'd guess Atlassian infrastructure folks don't share ssh keys over chat. Maybe they do.
When a zero day drops the size of the security team is irrelevant.
Re: HipChat security notice
#90Doubt this will be a popular view around here, but using a 3rd party service for internal business communications is just a bad idea. I've seen companies posting root passwords, ssh keys, salaries, internal financial details, etc in Slack and HipChat. Just waiting for a disaster to strike, adding value for every additional company to the target. Maybe this breach won't be the last straw, but it's a consistent risk. Y…
Is there a single case of a company suffering a loss because of a Github or Slack data breach? Is there a single case of a company suffering a loss because of their own systems being breaches? It happens all the time. Look at Sony -- their data would have been safer stored on DropBox than their own internal servers. You claim "risk," of using 3rd party services but can you quantify it with actual data? Slack's entire…
> Look at Sony -- their data would have been safer stored on DropBox than their own internal servers.
Not really, if I recall correctly Sony's whole Windows network was compromised via trojans in a PDF attachment exploit. Nothing to do with local vs cloud storage. They certainly couldn't have replaced their desktops with Dropbox.
> Are we to think that our teams are better than Slack's when Slack's core competency is secure communication?
Not necessarily - but they are much better able to restrict things to only your employees by applying VPNs and HTTPS+LDAP auth only proxies. Preventing you from being affected by public breaches like these. The value there is well documented - look what happened when the world moved from exposed to behind NAT routers.
Big public breaches happen all the time - you mentioned dropbox, I've gotten several reset emails from dropbox due to compromise, I'm guessing the attackers didn't walk away empty handed in such cases. A quick search reveals that just last year 68 million dropbox accounts were compromised.
On the other hand, when was the last time an even moderately well maintained SMB file server behind a LAN was compromised directly? Unique zero-day attacks are much more likely to be used on public services too due to the nature of their value.