Live data from Hacker News

The MongoDB hack and the importance of secure defaults

snyk.io

71–80 of 223 posts

Re: The MongoDB hack and the importance of secure defaults

#71
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

In production deployments, unsecured remote connections might be fine, because security would be handled at the network layer (e.g. by deploying MongoDB on a VLAN which only was accessible by your MongoDB clients which were on separate servers).

Before VMs and the cloud you'd buy a server with three or more network cards in it and you ended up with physically separate networks just because you could and it staved off network saturation. That it simplified your security architecture was the cherry on top.

But Mongo pretty much rejected that world view (web scale!) so it's a little odd that they designed a system that only works in it.

Re: The MongoDB hack and the importance of secure defaults

#72
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

Because trivialities like requiring your users to set a password on their database are barriers to adoption.

Move fast, and break things - you're not responsible for the damage your product does. Our industry both optimizes for, and rewards this kind of behaviour.

Re: The MongoDB hack and the importance of secure defaults

#73
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

MongoDB was easy to setup and new. It got popular among developers who always jump to the latest trend and don't care about quality, maintenance or long term support.

Internally everything is screwed, from the architecture to the security settings, to the reliability of data storage (or lack thereof).

MongoDB is the school case of 1) Worse/bad software can succeed despite being bad. 2) Don't trust hype. 3) Developers in general have low standards.

Re: The MongoDB hack and the importance of secure defaults

#74

Microsoft took a rash of shit some time ago (15 years?) for shipping MS Proxy Server with every port open by default. From the POV of employee-at-the-time, it took them a disappointingly long time for them to not do that anymore. Since then, I've learned to not assume that products are secure-by-default. At the same time, I kind of thought we learned our lesson and cut that shit out low these many years later. Add a…

Years ago Oracle had two admin accounts out of the box, but half the docs only talked about one. So a whole lot of people discovered that they had an admin account with a default password hanging out in production. Those were some awkward conversations.

Re: The MongoDB hack and the importance of secure defaults

#75
post #22
post #16

Earlier quoted context omitted.

at v2.6 the product was only about 4 years old and underwent a lot of change during that time. (For comparison Postgres version 3 was released in 1991) I think the main guilty parties at mongodb were/are in marketing. technically sophisticated users understood the immaturity of the product and the tradeoffs that came with its architecture. however it was sometimes marketed as a general purpose data store, or as an al…

Even technically sophisticated users should be able to expect secure defaults.

Sophisticated users understand when to adopt a product. MongoDB had all the red flags, a sophisticated user would have done a trial and ban it with a company-wide memo after the first week and already the 3rd disaster.

Re: The MongoDB hack and the importance of secure defaults

#76
post #20

Earlier quoted context omitted.

This is absolutely the problem. There are high-horse developers who've made 4 webapps using PHP and don't know anything about the system they're deploying on -- but they're rockstars disrupting the world! They leave mysqld bound to 0.0.0.0 because they don't know any better. They SSH as root because they don't know any better. They have a default WordPress install with the config db sitting in webroot. But hey, their…

Everyone can't know everything, be realistic.

Ah yes, everything is absolutely what I was getting at. This line of thinking is what allows these problems to happen due to pure laziness or not caring.

When you build a product or service, you should own it end-to-end OR simply let it be known that you are unable or unwilling to do so.

If you take it seriously, you'll know what can sink your project/business -- and stuff like leaving your entire database publically available with no auth, is one of them.

Re: The MongoDB hack and the importance of secure defaults

#77

I don't mean to defend Mongo here, but as a counter argument to the broad principle: Ubuntu doesn't ship with iptables blocking all incoming connections by default. Should it?

Well, if you're on a laptop, Linux may ship with no Wifi card support and thus no internet whatsoever. Guess that's even more secure!

Re: The MongoDB hack and the importance of secure defaults

#78
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

You can set up the latest MySQL with a blank root password and open to the world as well. The lack of good security options is a 1.x-ism, now there are plenty of security mechanisms now https://docs.mongodb.com/v3.2/administration/security-checkl...

Re: The MongoDB hack and the importance of secure defaults

#79
post #4

I have never used MongoDB so I admit I'm talking blind here, but can someone explain how/why a piece of highly popular software gets to version 2.6 allowing unsecured remote connections by default? Further to that is that type of thinking you want in the development process of something as critical as a database engine? It just seems amazing to me that it got so far before the community in general pushed back that th…

This is not unique to MongoDB however Elasticsearch is similar. The line they seem to tow is "this is made to be run behind a firewall." I agree its unacceptable but its unfortunately not unique to MongoDB.

That's not a fair comparison. ElasticSearch doesn't have authentication in the free edition. You gotta pay to get the authentication plugin.

ElasticSearch => Dropped authentication (i.e. an important aspect for security) to get a chance at monetization.

MongoDB => Dropped everything, including your data. YOLO!

Re: The MongoDB hack and the importance of secure defaults

#80
post #29

Microsoft took a rash of shit some time ago (15 years?) for shipping MS Proxy Server with every port open by default. From the POV of employee-at-the-time, it took them a disappointingly long time for them to not do that anymore. Since then, I've learned to not assume that products are secure-by-default. At the same time, I kind of thought we learned our lesson and cut that shit out low these many years later. Add a…

Microsoft is a different beast. They ship things based on the principal of least surprise. There are incredible features in newer versions of SQL Server that aren't turned on by default when upgrading, even though no one would want to not have them on.

Can you give some examples?
Post reply on HN