Live data from Hacker News

HipChat security notice

blog.hipchat.com

51–60 of 119 posts

Re: HipChat security notice

#51
post #6
post #2

I wonder which "popular third-party library" caused the problem

More importantly, I wonder how much they were paying for this library, or to what extent they were supporting it internally. Because if the answer is zero and they weren't, I would put a lot of the blame on HipChat engineering.

[deleted]

Re: HipChat security notice

#52

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…

I think that's a totally legitimate view

Re: HipChat security notice

#53

Earlier quoted context omitted.

Serious question: Do you need the non-techy explanation?

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

Is that a problem? I guess they could have put a "technical details:" in front of it, to make that clearer, but it has to be in that e-mail (otherwise the techies complain) and isn't really something they can explain in a useful way there.

Re: HipChat security notice

#55

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.

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.

Re: HipChat security notice

#56

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.

Oh for God's sake.

Re: HipChat security notice

#57

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?

Re: HipChat security notice

#58

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?

Re: HipChat security notice

#59

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?

Re: HipChat security notice

#60
post #7
post #6

Earlier quoted context omitted.

More importantly, I wonder how much they were paying for this library, or to what extent they were supporting it internally. Because if the answer is zero and they weren't, I would put a lot of the blame on HipChat engineering.

I'm not sure I understand you - You would blame the users of a third-party library if the library was found to have a vulnerability and it was exploited against the people using the library?

If it's free software? Yes, absolutely. To do otherwise is a chilling effect against hobbyist free-software authors in favor of large companies that have the ability to take on that liability. I, as an individual, want to be able to write code in my free time, put it on GitHub, and let it get popular without worrying that maybe it has a bug in it. If people want to start holding me responsible for it, I'm just not going to release it. Maybe you can pay my employer for a commercial license if we think that the cost of auditing it and taking on the liability for bugs is commercially reasonable, but it's also unlikely my employer will be interested.
Post reply on HN