Earlier quoted context omitted.
What does this have to do with Javascript?
MongoDB is written in Javascript.
In part. According to the Github repo, it's 75% C++, 18% JS.
The MongoDB hack and the importance of secure defaults
61–70 of 223 posts
Re: The MongoDB hack and the importance of secure defaults
#62While we are at this, this checklist is worth looking at: https://github.com/FallibleInc/security-guide-for-developers...
Re: The MongoDB hack and the importance of secure defaults
#63No matter what your defaults are, if a sysadmin doesn't understand that some software is OK to connect to a public-internet addressable interface while other software is not, their shit is going to get hacked (or, as in this case, accessed).
This is the equivalent of leaving your data in a file cabinet in your lobby and being surprised someone took it. The answer isn't to add self-locking little office locks to the file cabinets by default, it's to educate folks that this is a file cabinet that's designed to be inside the office, not in a publicly accessible place.
Re: The MongoDB hack and the importance of secure defaults
#64Earlier quoted context omitted.
At a guess, it became popular through easy setup. That includes not having to configure login. That's why so many other systems are insecure. Security nearly always increases friction.
This. I once had a conversation with someone who started an open source project about the "10K meter" view. I strongly encouraged secure defaults. He asserted that when getting started, grabbing mindshare requires insecure-out-of-the-box. They could fix that later. Later never came; the project died (Not due to security). But I'm pretty sure something like this would have happened if it had taken off, because later d…
I still think the XP guys had this figured out. You scale with your customers and stop trying to write it perfect the first time. I'm a huge proponent of never making the same mistake twice but there is just not enough time in the day for perfect.
Instead you write it in a way that it has the potential to be great.
Customers that have been using your software for a year will have different problems when they have been using it for four.
On one project we essentially had a goal of doubling our data capacity of our (on premises) software every year to stay ahead of our customers' data collection rate. So my goal was 10% per month. We kept on that treadmill for over two years. Yes a couple of those months involves some pretty deep changes to get to a better info architecture. But most of it was constant application of the campsite rule.
That said, in that same project we added security and permissions after the fact, and it was one of the most frustrating things I've ever done. A constant and unending stream of bad news from QA about some other spot we missed.
Re: The MongoDB hack and the importance of secure defaults
#65It's worth noting this isn't unique to MongoDB.
The "Marked" npm package, with it's 2 million downloads, doesn't sanitize input by default. "st", another popular package, allows directory listing by default. Quite a few of those...
Re: The MongoDB hack and the importance of secure defaults
#66Earlier quoted context omitted.
Semantic counterargument: If you put a database into production without understanding its network and auth configuration then you are by definition not "technically sophisticated"
By this standard, every programmer who puts an app into production without understanding assembly is not technically sophisticated. We could expect every programmer to have domain knowledge of databases, even when it's not normally needed to operate one. Or we could just make databases not acknowledge writes that haven't happened, not listen on all ports, not hide information about data loss in non-clustered setups d…
at the time these versions of mongodb were released, it was only a few years old, and DID require considerable domain knowledge to run in production. This does not seem unreasonable for new immature technologies.
unfortunately, I don't think this was always communicated effectively by the explosion of mongodb marketing and hype.
Re: The MongoDB hack and the importance of secure defaults
#67Earlier quoted context omitted.
This is also the case for Elasticsearch. In fact, to get a proper username/password/ACL setup, you need to pay for professional support.
IIRC, there was also a time when Elasticsearch used multicast by default to detect other ES nodes on the network and to add them to the cluster automatically. So any node joining the same network will join a cluster and have shards allocated to it
Early J2EE frameworks did that too. Super fun when your dev box clusters with a coworker and undoes your regression testing because half of the tests run on an older version of the code!
Re: The MongoDB hack and the importance of secure defaults
#68Earlier quoted context omitted.
This is also the case for Elasticsearch. In fact, to get a proper username/password/ACL setup, you need to pay for professional support.
IIRC, there was also a time when Elasticsearch used multicast by default to detect other ES nodes on the network and to add them to the cluster automatically. So any node joining the same network will join a cluster and have shards allocated to it
[deleted]
Re: The MongoDB hack and the importance of secure defaults
#69Postgres' defaults barely let you connect to the DB. You don't hear stories like this about Postgres.
But back when I was starting out you did get a hell of a lot of people choosing mysql over postgres partly based on the fact that the latter was easier to connect to out of the box, and/or filling the support channels with connection questions that are already answered in an installation guide in the documentation.
Convenience "sells" even at the expense of security (and in this case, actually working properly at all!) and if you don't make it as easy as possible be prepared to support people who refuse to read the instructions.
Re: The MongoDB hack and the importance of secure defaults
#70No matter what your defaults are, if a sysadmin doesn't understand that some software is OK to connect to a public-internet addressable interface while other software is not, their shit is going to get hacked (or, as in this case, accessed). This is the equivalent of leaving your data in a file cabinet in your lobby and being surprised someone took it. The answer isn't to add self-locking little office locks to the f…
Network oriented software created after 2000 has zero excuse for allowing unauthenticated writes from the general internet by default.