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

31–40 of 130 posts

Re: MongoHQ Security breach

#31

Post by jdp23 »

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

> opted to go with MongoLab, which I am still suing

this is either an unfortunate typo or a great backstory ...

Re: MongoHQ Security breach

#32

Post by lgleason »

These guys have great support. A client of mine was using them and had a cluster get wonky. The performance of their website got really slow during an in-opportune time. MongoHQ got right on it, fixed the issue and gave them 6 months of service and doubled their instance size free or charge to make things right..... Sure it would have been better if the servers had not gone down, but that can happen on any system. They also followed up for the next couple of weeks to make sure that things were running smoothly.

I was very impressed with their customer service and would highly recommend them.

Re: MongoHQ Security breach

#33

Post by jumby »

aerolite wrote: post #24
jumby wrote: post #4

And this is why you use 2FA and put this behind a corporate VPN in RFC 1918 space. Why they are just planning for that now is amusing. "Our support tool includes an 'impersonate' feature that enables MongoHQ employees to access our primary web UI as if they were a logged in customer"

I bet many products have a similar 'impersonate' feature. Nothing wrong with that if you take proper precautions.

Nope. Having it on the external internet is what's wrong here.

Re: MongoHQ Security breach

#34

Post by brandoncarl »

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

still "suing"...hahaha. slightly different meaning the misspelling conveys, especially in this incident!

Re: MongoHQ Security breach

#35

Post by jumby »

lgleason wrote: post #32

These guys have great support. A client of mine was using them and had a cluster get wonky. The performance of their website got really slow during an in-opportune time. MongoHQ got right on it, fixed the issue and gave them 6 months of service and doubled their instance size free or charge to make things right..... Sure it would have been better if the servers had not gone down, but that can happen on any system. Th…

That's nice. Their application security setup, processes & procedures are apparently severely lacking. So, you might want to think about recommending them to your other clients.

Re: MongoHQ Security breach

#36

Post by aroman »

jdp23 wrote: post #31
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,…

> opted to go with MongoLab, which I am still suing this is either an unfortunate typo or a great backstory ...

Hah! Oh god, yep, that was a typo. Part of me wishes I had a cool backstory to tell though... (not that I think MongoLab is in the least deserves to be the object of such action, of course!)

Re: MongoHQ Security breach

#37

Post by onedev »

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…

Yup, though I am an early adopter I am definitely less willing to just hand over my data to a random startup recently than I have in the past.

Re: MongoHQ Security breach

#38

Post by joshchaney »

flyt wrote: post #3

Especially bad for people that were using MongoHQ to manage their DB backups to S3: As a precaution, we took additional steps on behalf of our customers to invalidate the Amazon Web Services credentials we were storing for you (for the purposes of backups to S3). While this prevents the abuse of your AWS credentials by any malicious party, it may have resulted in additional unintended consequences for your AWS enviro…

I was one of those people bitten by this last night. My client called and told me he was getting access denied when trying to upload files through his CMS. After some digging I found the S3 key had been revoked. This was concerning, as I hadn't touched the CMS code I wrote in like 3 years and I've had issues deploying old stuff to Heroku in the past. I really wish MongoHQ had contacted me first about revoking the keys.

Re: MongoHQ Security breach

#39

Post by s_kilk »

mLewisLogic wrote: post #26
s_kilk wrote: post #15

Earlier quoted context omitted.

For the non-experts among us, does this imply that having the bcrypted passwords in hand is almost worthless from an attackers point of view? Would it be feasible at all to derive the plain-text passwords from that encrypted data?

With sane defaults, bcrypted passwords are "worthless" in the hands of a casual attacker. Somebody would have to REALLY want to access your account and have SIGNIFICANT financial/computational resources to crack it. And that only gives them one password. Significant and independent work is required for each individual password. On the other hand, there's nothing stopping a developer from doing something really dumb l…

>> On the other hand, there's nothing stopping a developer from doing something really dumb like setting bcrypt iterations to 1.

I _really_ hope that doesn't turn out to be the case here.

Re: MongoHQ Security breach

#40

Post by jturolla »

leokun wrote: post #20

So I am wondering if any service I'm using is using MongoHQ to store my sensitive information in plain text and was breached. Like, it is a bigger deal than just "change your password" when an attacker can "god mode" into customer databases.

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!
Post reply on HN