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

MongoHQ Security breach

security.mongohq.com

Post reply on HN
Print view View original

101–110 of 130 posts

Re: MongoHQ Security breach

#101

Post by JshWright »

sjtgraham wrote: post #95
joelgascoigne wrote: post #42

Hi everyone. Joel here from Buffer. Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday. This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full…

It's not cool throw your upstream vendors under the bus.

Seems like they're pretty clear that they're still culpable for designing a system that relied on the trust of a 3rd party vendor to protect user data.

They waited until after MongoHQ made their own disclosure, and all evidence (including comments on the post) point to a fairly good working relationship between the two.

I'm sure both parties wish this hadn't happened, but I don't see any bus throwing...

Re: MongoHQ Security breach

#102

Post by mrkurt »

sjtgraham wrote: post #95
joelgascoigne wrote: post #42

Hi everyone. Joel here from Buffer. Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday. This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full…

It's not cool throw your upstream vendors under the bus.

(I am one of the founders of MongoHQ)

Buffer has been exceedingly fair with us, we are fully in favor of them giving customers all the information they have.

Re: MongoHQ Security breach

#103

Post by darkarmani »

bdcravens wrote: post #2

detected unauthorized access to an internal support application using a password that was shared with a compromised personal account Someone's updating their resume tonight.

> Someone's updating their resume tonight.

At a start-up, it most likely was not an engineering decision, but an agility trade-off. Get that product out the door now!

Re: MongoHQ Security breach

#104

Post by mrkurt »

thomasfromcdnjs wrote: post #100
thomasfromcdnjs wrote: post #97

Earlier quoted context omitted.

Our application also had problems due to this. Would have been nice to receive a phone call or email.

Also I believe you should alert us as soon as you find out how long your servers have been compromised for. As a company we are now trying to figure out how long our access tokens have been out in the wild.

You are 100% right on both points. We'll be updating our security page as we get more details, I expect we'll have some rough timeline information tomorrow.

Re: MongoHQ Security breach

#105

Post by whbk »

Pretty poor communication -- we were also among those who had to get new AWS credentials with no idea as to why ours were no longer working. Luckily we jumped on it pretty quickly, but I hope this kind of thing is handled much differently by providers in the future. Very inconsiderate of the impact on users.

Re: MongoHQ Security breach

#106

Post by [deleted] »

jumby wrote: post #74
julian37 wrote: post #63

Earlier quoted context omitted.

This is the elephant in the room and I'm surprised it hasn't been mentioned by any of the other comments. When it comes to infrastructure as a service, it appears to me that there is an imbalance between the sensitivity of information entrusted to external systems on one hand, and the standards such systems are held up to on the other. EDIT: case in point, on http://mongohq.com I can't find a single mention of the wo…

"security" is always left for after-the-fact ---- exactly as evidenced by this disclosure and their poor in-house practices.

[deleted]

Re: MongoHQ Security breach

#107

Post by dustingetz »

computer wrote: post #46
joelgascoigne wrote: post #42

Hi everyone. Joel here from Buffer. Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday. This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full…

Have you considered not outsourcing critical parts of your company to startups that are iterating fast and potentially breaking things? Could you share the reasoning behind Buffer choosing to store their customers' private data with MongoHQ, instead of your own secure infrastructure?

Security-after-the-fact is actually +EV just like certain risk distributions are +EV in finance. Companies must balance where they want to be in the secureness spectrum against the investment cost to get there and it seems that high grade security isn't worth the opportunity cost for a pretty big class of companies and customers.

Re: MongoHQ Security breach

#108

Post by joelgascoigne »

zaidf wrote: post #93
joelgascoigne wrote: post #42

Hi everyone. Joel here from Buffer. Some of you might have heard about our security breach on Saturday. I just wanted to leave a quick note and clarify that this MongoHQ security breach was the method used to obtain our users' access tokens, which led to the wave of spam on Saturday. This is a key final piece of our investigation which brings it back full circle. I'm very happy that we have been able to gain the full…

If access tokens were encrypted (which they are now) then this would have been avoided. That answers my question! (See https://news.ycombinator.com/item?id=6619265 ) Kudos for how you guys handled this during this tough few days.

That's right. In addition, Facebook has an 'appsecret_proof' method where you can require signing of all API calls with the app secret. We've now implemented this. Details: https://developers.facebook.com/docs/reference/api/securing-...

Thanks for the kind words :)

Re: MongoHQ Security breach

#109

Post by morgante »

theboss wrote: post #13

One thing I hate seeing is startups and security. Not that mongo is bad or anything this is just a good time to say it. Build your product correctly from the start and have a security policy early. Don't leave XSS in your website, don't just hack code together and throw it on a server. As a security guy I love seeing new startups products because so often the code is so freshly written and immature that anyone it's a…

> Not that mongo is bad or anything this is just a good time to say it.

To be clear, this breach had absolutely nothing to do with Mongo. It occurred via a web interface which could've been put in front of any hosted database.

Re: MongoHQ Security breach

#110

Post by memset »

theboss wrote: post #49
alexandros wrote: post #28

Earlier quoted context omitted.

Some times taking more time (and/or better coders) to do something 'right' vs. just hacking it together is the difference between failure and success. So from an individual startup's POV this may not be worth doing. Having enough users/success to warrant a security breach is a luxury problem when viewed from the eyes of an entrepreneur with no product. On the other hand, collectively, startups losing everyone's crede…

You're right that it is a luxury but you are wrong that it is unfair to expect startups to set a higher standard. Startups have fewer assets than big companies. If you can't secure 1 webserver or you have a security breach with only 3 employees, there is something seriously wrong. If you expect to one day have 10,000 servers you better believe I expect you to be able to handle 3 or 5 or 10 by yourself.

How, or where, does one learn how to implement a secure application (say, nginx + uwsgi + python + mongodb)?

This is a serious question - the best that I'm aware of are blog posts, but every time someone writes a post about security, HN comments (et al) give contradictory advice.

Post reply on HN