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

21–30 of 130 posts

Re: MongoHQ Security breach

#21

Post by aroman »

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, which I am still suing), but their response impressed me. There is indeed such a thing as screwing up properly, imho.

Kudos to the MongoHQ team, and best of luck in dealing with this mess.

Re: MongoHQ Security breach

#22

Post by iloveponies »

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"

2FA and VPNs are not exclusively the only way to secure things. X.509, bastion servers, airgaps that require physical access to a secure facility etc are also valid options, dependent on your systems and their configuration.

Re: MongoHQ Security breach

#23

Post by jumby »

roin wrote: post #16

If I were running a company, I'd buy everyone a license of 1Password and make its use mandatory. Sure there are still plenty of attack vectors, but it's just too easy, and 1Password is such a cheap way to mitigate risk (not to mention you're doing your employees a huge favor by reducing their vulnerability outside of work).

Better yet, how about making sure your employees can only connect to your internal tools when on a properly secured VPN and not "externally" from home/coffee shop/airport?

Re: MongoHQ Security breach

#24

Post by aerolite »

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.

Re: MongoHQ Security breach

#25

Post by meowface »

s_kilk wrote: post #15
meowface wrote: post #6

At least they used bcrypt to hash user passwords.

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?

No, the hashed passwords are certainly not "almost worthless." It does depend on the cost setting as well (you can configure how fast bcrypt takes to compute via this setting).

Anyone using the password "password" or "password123" or other basic common passwords, plus passwords that are just dictionary words, will likely be cracked if the attackers make a dedicated effort no matter what setting is in use. In general though, cracking bcrypt hashes is much, much, much slower than cracking MD5 or SHA1 hashes.

So anyone using a somewhat decent password is likely safe from having it cracked. While with MD5 or SHA1, you generally need a fairly entropic password over at least 10 characters in length to remain safe (a password of totally random 10 characters still wouldn't be cracked with MD5 or SHA1, but it's rare that people use /dev/urandom output as a password).

Re: MongoHQ Security breach

#26

Post by mLewisLogic »

s_kilk wrote: post #15
meowface wrote: post #6

At least they used bcrypt to hash user passwords.

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 like setting bcrypt iterations to 1.

Re: MongoHQ Security breach

#27

Post by iloveponies »

roin wrote: post #16

If I were running a company, I'd buy everyone a license of 1Password and make its use mandatory. Sure there are still plenty of attack vectors, but it's just too easy, and 1Password is such a cheap way to mitigate risk (not to mention you're doing your employees a huge favor by reducing their vulnerability outside of work).

It's far simpler to remove the need for passwords alltogether or at least minimise them than to offset the liability against your employees using security software correctly.

Re: MongoHQ Security breach

#28

Post by alexandros »

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 credentials/data are burning the commons wrt people's willingness to use new products.

But then on hand #3, it's not as if BigCo's have a much better record, so I guess this gets chalked up to the general 'why in the world do we release software this bad?' and the general answer is 'because people have been trained to accept it'. In the same way that if the car was invented today it'd never surpass our current health&safety considerations.

So I guess my point is, software is terrible in general, and security is just one aspect of many. As long as we don't have a better way to write it, it'll keep being bad. It's not fair to expect startups to set a higher standard, when they're optimising along several other dimensions at the same time.

Re: MongoHQ Security breach

#29

Post by jumby »

iloveponies wrote: post #22
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"

2FA and VPNs are not exclusively the only way to secure things. X.509, bastion servers, airgaps that require physical access to a secure facility etc are also valid options, dependent on your systems and their configuration.

Granted, but an airgap would make working with some internal support tool a bit cumbersome :)

Bastion servers if properly firewalled might be OK for a short term solution. The concern there is if you allow unfettered ssh (for example) is someone watching for the inevitable brute-forcing that will ensue?

Re: MongoHQ Security breach

#30

Post by petercooper »

gmjosack wrote: post #7

The name of this company is unfortunate. It doesn't appear that this service has any affiliation with MongoDB, Inc.

Mongo is a trademark of MongoDB so I suspect they got permission because naming your company after a trademark is a quick way to get into trouble.
Post reply on HN