Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HipChat security notice

blog.hipchat.com

Post reply on HN
Print view View original

71–80 of 119 posts

Re: HipChat security notice

#71

Post by MichaelGlass »

problems wrote: post #31

Doubt 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.

Re: HipChat security notice

#72

Post by geofft »

lolsal wrote: post #33
falcolas wrote: post #24

Earlier quoted context omitted.

IMO, frankly, yes. If you use someone else's code, especially if you're not paying anything for it, you get what you put into it: nothing. The liability for this breach is ultimately owned by Atlassian, not the third party library writer. To quote the most permissive license out there: "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NO…

To use an analogy, do you blame everyone that has ever used the linux kernel whenever bugs/vulnerabilities are discovered in the kernel?

If they use the upstream kernel, yes. Linus Torvalds has been very clear that security is not a priority.

"We have one rule in the kernel: don't break userspace. Everything else is kind of a guideline. The whole security thing? It's a guideline that we shouldn't do stupid shit. But people do stupid shit all the time and I don't get that upset." https://www.youtube.com/watch?v=1Mg5_gxNXTo#t=8m28

Imagine, Torvalds said, that terrorists exploited a flaw in the Linux kernel to cause a meltdown at a nuclear power plant, killing millions of people. “There is no way in hell the problem there is the kernel,” Torvalds said. “If you run a nuclear power plant that can kill millions of people, you don’t connect it to the Internet.” Or if you do, he continued, you build robust defenses such as firewalls and other protections beyond the operating system so that a bug in the Linux kernel is not enough to create a catastrophe. http://www.washingtonpost.com/sf/business/2015/11/05/net-of-...

And the Linux kernel has a track record for not being the world's most secure piece of software. Which is fine, it's a project he started for fun.

It's certainly possible to pay people for a kernel that they'll stand behind commercially. If you're using, say, a RHEL kernel and a bug or vulnerability is discovered that impacts you, by all means get upset at Red Hat. If you're using a Fedora kernel, though, you made the choice to use it. It's completely unfair for you to get the benefits of running a kernel you put neither time nor money into, and not also the risk of running that kernel.

Re: HipChat security notice

#73

Post by eropple »

lolsal wrote: post #30
eropple wrote: post #13

Earlier 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…

Where I come from, if you aren't paying it forward, you aren't grateful. (You are also probably hurting yourself, in that problems with it are problems for you, too.)

Re: HipChat security notice

#74

Post by geofft »

algesten wrote: post #38
falcolas wrote: post #24

Earlier quoted context omitted.

IMO, frankly, yes. If you use someone else's code, especially if you're not paying anything for it, you get what you put into it: nothing. The liability for this breach is ultimately owned by Atlassian, not the third party library writer. To quote the most permissive license out there: "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NO…

Surely that's completely unreasonable. Who can claim that any piece of software is without bugs/security holes? The problem is absolutely owned by Atlassian, but they actually did do something to fix it. I don't believe anyone (apart from maybe Daniel J Bernstein) can claim any piece of software is bug/hole free, and neither does anyone need to!

Why is that unreasonable? If I write a complex piece of software, and something goes wrong, the blame is on me. As you say, there's no way to claim that it is without bugs.

Why, when I use someone else's software without so much as telling them, let alone signing a support contract with them, does the blame shift to them? My responsibility is to deliver a service, not to write software. If writing software is the easiest way to do it, great. If using someone else's software is the easiest way to do it, great. But I'm the one running the service, either way.

Re: HipChat security notice

#75

Post by CaptSpify »

Gaelan wrote: post #57
problems wrote: post #31

Doubt 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?

What about them? They are just as prone to the same problems

Re: HipChat security notice

#76

Post by geofft »

lolsal wrote: post #63
plange wrote: post #43

Earlier quoted context omitted.

Nothing in life is free. Quality software doesn't create itself out of thin air (yet, if ever). That means someone has to make an investment. You don't have to invest in the upkeep of the foundation of your house, but if some bugs, say termites, were to sneak in you can't blame the original builders for the donated foundation. Please downvote for the bad analogy.

I think of it like the Heartbleed vulnerability - was everyone affected to blame for the vulnerability? Was everyone simultaneously morally obligated to be contributing patches back to openssl? I don't think so.

Everyone affected was to blame for their own vulnerability, to the extent they relied on OpenSSL.

I worked for a company that needed to push out an out-of-cycle patch for Heartbleed. We were building a virtualization product that included a OpenSSL and other free-software libraries in the core product, plus an entire Linux distro to support our install-this-on-dedicated-hardware product. We made the business decision that we could reuse Ubuntu and not develop our own operating system and control plane. Others, like Microsoft, made the decision to implement it all themselves. Others, like VMware, took a decision sort of in the middle.

We got a significant amount of functionality for free - and a significant amount of risk for free. Whatever code worked for our needs, we could profit from. Whatever code introduced security vulnerabilities in our application (and it was not all upstream security vulnerabilities, since we intentionally designed our system to anticipate that local root exploits would be easy), we took responsibility for. That was part of saying that this was our product, and not just a shell script for building a similar product on your own.

Re: HipChat security notice

#77

Post by DKnoll »

throwaway91111 wrote: post #47
problems wrote: post #31

Doubt 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…

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.

Quite a lot of organizations use Spark which is a straight up XMPP client, they also license an enterprise XMPP server.

Re: HipChat security notice

#78

Post by jordache »

plange wrote: post #22
jordache wrote: post #19

Earlier quoted context omitted.

no.. but I could be a non IT user using hipchat. This sentence is likely meaningless to me.

Then you would be fine with the standard boilerplate "your data is secure with us"? I'm happy they say this.. now i'd like some sort of proof :-)

A follow up sentence that re-iterates the same sentiment in non technical term will accommodate none technical recipients.

Poor UX is my point of this

Re: HipChat security notice

#79

Post by Xylakant »

deaddodo wrote: post #55
throwaway91111 wrote: post #47

Earlier 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.

Friends don't let friends use libpurple based messengers. Sadly, Adium development is pretty stale and unresponsive to even major security issues such as https://threatpost.com/code-execution-vulnerability-found-in...

Re: HipChat security notice

#80

Post by Alupis »

DKnoll wrote: post #77
throwaway91111 wrote: post #47

Earlier 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.

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/openfire/index.jsp

Post reply on HN