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

91–100 of 130 posts

Re: MongoHQ Security breach

#91

Post by nolok »

reidrac wrote: post #67
jturolla wrote: post #40

Earlier quoted context omitted.

The question remains: Will they disable god mode? I'm truly not comfortable with this feature, I should be able to block total access from my database. I deal with extremely sensitive personal information of thousands of users, and I would never give access to it for support people from a company I hired - Not even MY support team has access to it!

I think in those cases you may not be legally allowed to use a 3rd party managed service to handle the data, although it probably depends on the country where your company is operating. Also that "god mode" only makes things easier, if you're hiring a managed service by definition it means someone must have access to manage the service. The answer is: manage it yourself effectively locking access to any 3rd party.

There is a difference between "someone must have access" and "a random support account at that company can have full access".

I agree with parent that customer should be able to disable god mode on their account.

Re: MongoHQ Security breach

#92

Post by ams6110 »

biot wrote: post #12

Long story short: MongoHQ is securing access to critical administration functionality behind a VPN and will be requiring two-factor authentication instead of having that functionality available to anyone on the internet via a simple password. What's interesting is that I think we've all been there at one point. You start building something, it gains momentum, then you get so bogged down with adding functionality and…

that functionality [critical administation functionality] available to anyone on the internet via a simple password

I mean COME ON, MAN.... there are mistakes, and then there's incompetence.

Re: MongoHQ Security breach

#93

Post by zaidf »

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.

Re: MongoHQ Security breach

#94

Post by trimbo »

alexandros wrote: post #28
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…

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…

> 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

Maybe it's high time we start taking "not screwing over your customers" into account when considering what makes a success.

Re: MongoHQ Security breach

#95

Post by sjtgraham »

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.

Re: MongoHQ Security breach

#96

Post by sjtgraham »

ajsharp wrote: post #89
computer wrote: post #46

Earlier quoted context omitted.

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?

As a founder of another startup (octocall.com) choosing to host our database with another company (postgres, hosted with Heroku) the decision is a simple one: You trade infrastructure management complexity for a monthly fee. Especially when you're starting out, the team is small, and time is much more expensive than whatever your database provider is charging you per month. It's a great trade-off for most early-stage…

+1 Using Heroku Postgres as an example gets you a lot for free, e.g. WAL-E disaster recovery.

Also farming out a piece of infrastructure and having a secure stack doesn't have to be mutually exclusive.

Re: MongoHQ Security breach

#97

Post by thomasfromcdnjs »

mrkurt wrote: post #85
sprice wrote: post #81

Earlier quoted context omitted.

So this is why our app broke yesterday. We've spent the last 24 hours wondering how our AWS key was removed. Thankfully I was able to learn about this via HN. Still waiting on a note from MongoHQ. And when we went to file an issue with AWS there was no Premium Support option.

We're very sorry about this, we went into a little bit of a panic when we realized that we held IAM credentials that gave full access to peoples' EC2 accounts and did what we thought was best. In hindsight, we should have gotten ahold of Amazon immediately and let them manage that process. You should have a support issue open in your AWS portal now, if you need any help getting new keys for other apps. If you can't f…

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

Re: MongoHQ Security breach

#98

Post by clark-kent »

aroman wrote: post #21

As much as the actual cause of the concern (apparently serious employee error) was preventable, I was still impressed by their detailed disclosure, the steps that have been taken to mitigate it, and actual details about what was compromised other than the generic "non-credit card personal data". I don't use MongoHQ for any projects right now (I evaluated their offering a year or so ago and opted to go with MongoLab,…

I guess you are suing them for good service. Sorry HN for lack of insight, I really needed the laugh.

Re: MongoHQ Security breach

#99

Post by lttlrck »

theboss wrote: post #61
nfoz wrote: post #45

Earlier quoted context omitted.

Capitalism often presents a choice between aggressively building unsafe products, or losing out to the competition. It's extremely hard to win in a fast market by being stable, secure, and correct, at least when it comes to software.

Capitalism will also say that I'm most likely to succeed if I can do all three.

Does it really?

Re: MongoHQ Security breach

#100

Post by thomasfromcdnjs »

thomasfromcdnjs wrote: post #97
mrkurt wrote: post #85

Earlier quoted context omitted.

We're very sorry about this, we went into a little bit of a panic when we realized that we held IAM credentials that gave full access to peoples' EC2 accounts and did what we thought was best. In hindsight, we should have gotten ahold of Amazon immediately and let them manage that process. You should have a support issue open in your AWS portal now, if you need any help getting new keys for other apps. If you can't f…

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.

Post reply on HN