10 ms·

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 uns

by 51Cards 10y ago

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 this was really bad design? Hopefully someone with MongoDB history can explain if this was a long term sticking point, etc. Thanks.

andersonmvd 10y ago
We usually can't see the same problems happening in front of our noses. Why shouldn't we discuss why docker images run as root by default then?
- jcrawfordor 10y ago
  I think we absolutely should discuss this - the number of images I see on Docker Hub that run complex network services as the root user really concerns me. The security measures implemented by Docker reduce the risk but absolutely do not eliminate it, you're taking a big risk there. This issue, along with its related issues with permissions on persistent storage, is one of the major reasons I'm hoping to move away from Docker as soon as possible.
  - tannhaeuser 10y ago
    What Docker security measures do you mean? Actually, I was wondering recently what isolation Docker provides that a basic chroot-jail doesn't. Re root permisions I guess if you're running a typical network daemon (Apache, say), then requiring Docker to run as root is no worse than running the service on the host; root would be a requisite anyway for the daemon to open privileged ports/gain logging permissions etc. before dropping to "nobody" or what have you.
    - kccqzy 10y ago
      Docker drops capabilities of root by default. It doesn't drop everything but better than not dropping at all. If you are not using docker, you can manually add the specific privilege to open low-numbered ports without running the program in question as root.
pjc50 10y ago
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.
- at_tt 10y ago
  Yeah though configuring login is not something that takes more time than to set it up.
- giancarlostoro 10y ago
  IIRC on Debian it is by default not listening externally. So ideally on Ubuntu as well. Though that is Debian / Ubuntu specific, elsewhere they likely ship with default configs. Still no default authentication, but still better than just letting anyone externally connect to it.
  - hackcasual 10y ago
    But if a substantial use case requires it to listen remotely, you're just delaying disaster. Listening remotely should have required an authentication setup, or an additional configuration directive like "imbeingatotalidiotandamopeningmydatatuptoanymaluciousactors": true
- __jal 10y ago
  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 doesn't come until something like this happens. I don't know how wide-spread this thinking is, but it slots in well with a lot of the decisions I see made by other startup types. There seems to be a lot of conventional wisdom about the slimy-ish shortcuts and deceptions, bad design decisions, and so on that are "OK" to make to get off the ground. I'm not going to comment on the necessity of that sort of bad behavior from a business context; I think the answer is complex, and kind of appalling. But on the engineering side, it seems to usually lead to nasty things coming back to bite you, and it is notable that it does so after you've gotten attention and people depend on you.
richardwhiuk 10y ago
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).
- cpuguy83 10y ago
  This is a really bad practice to follow. You can't rely on the network to be secure.
  - hueving 10y ago
    That's true in many cases, but if the network is solely for database access and the only servers with access to it would be configured with DB credentials anyway, then the path to compromise is equivalent (get into a server with db credentials/network access).
- Cozumel 10y ago
  This problem was caused by broken 'thinking' like that.
- raverbashing 10y ago
  > In production deployments, unsecured remote connections might be fine No. Absolutely not Unsecured local connections yes, anything from outside 127.0.0.1 should be explicitly allowed and secured (like port 80/443). Rate-limited, fail2banned, fuzzed during testing, etc
  - Pxtl 10y ago
    "I opened the ports on the firewall and gave the user access, why doesn't it work!? This system is stupid." "I changed my password on one system and then on the other, but somehow my account got locked up in that brief time between changeover, how the hell do you unlock an account? This system is stupid." "We're scaling up and we're running into outdated rate-limiting settings on every service we use, some of them even having multiple layers of rate-limiting within a single service, and each setting requires hours of debugging to figure out which setting is taking down the whole project. This system is stupid." There's a reason Mongo got adoption while "secure" systems did not.
hitgeek 10y ago
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 alternative to much more mature relational data stores, which was and still is an unfair comparison.
- nailer 10y ago
  Even technically sophisticated users should be able to expect secure defaults.
  - omni 10y ago
    Semantic counterargument: If you put a database into production without understanding its network and auth configuration then you are by definition not "technically sophisticated"
    - nailer 10y ago
      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 deep inside the documentation. Counterargument: many people who are good at a particular topic enjoy feeling superior to people who don't have their knowledge.
      - hitgeek 10y ago
        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.
cpuguy83 10y ago
Most likely this configuration is due to the traditional mongo use-case, which is to have data replicated between many nodes. This requires each participating node to be able to communicate with every other node.
bqe 10y ago
This is also the case for Elasticsearch. In fact, to get a proper username/password/ACL setup, you need to pay for professional support.
- reqres 10y ago
  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
  - hinkley 10y ago
    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!
  - deleted 10y ago
    [deleted]
  - sneakymichael 10y ago
    It seemingly still does; I'm just getting started with Elasticsearch & your description aligns with what I've read in the introduction guide
    - polyfractal 10y ago
      Just FYI, multicast discovery was moved to a plugin in v2.0 [1], deprecated in v2.2 [2] and removed entirely in v5.0 [3] - [1] https://www.elastic.co/guide/en/elasticsearch/reference/2.0/breaking_20_removed_features.html#_multicast_discovery_is_now_a_plugin https://www.elastic.co/guide/en/elasticsearch/reference/2.0/... - [2] https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/discovery-multicast.html https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/di... - [3] https://www.elastic.co/guide/en/elasticsearch/plugins/5.1/discovery-multicast.html https://www.elastic.co/guide/en/elasticsearch/plugins/5.1/di...
pmlnr 10y ago
If this is not addressed at a _very_ early state of a software, it will stick, because people get used to it and you drive people away by backwards-incompatible changes. Especially if it's a software that's targeting people who wants things easy & fast, like Mongo did at the beginning. See reasons[1] for WordPress needing to be PHP 5.2 compatible, which had been out of support for 6 years. [1]: https://www.rarst.net/wordpress/technical-responsibility/ https://www.rarst.net/wordpress/technical-responsibility/
bogomipz 10y ago
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.
- user5994461 10y ago
  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!
  - bogomipz 10y ago
    Elasticsearch never had authentication. So they never dropped it from the free version. I feel like it is an appropriate comparison. The general response to Elasticsearch's lack of security was "your'e supposed to run it behind a firewall" Elasticsearch got all the way to version 1.4 with no authentication as part of the design. Between 1.4.1 and 1.5 release candidates is when they announced Shield as part of their enterprise offering. Here are the release dates and announcements: https://www.elastic.co/blog/shield-know-security-coming-soon https://www.elastic.co/blog/shield-know-security-coming-soon https://www.elastic.co/downloads/past-releases?page=16 https://www.elastic.co/downloads/past-releases?page=16
    - jsmthrowaway 10y ago
      Because it absolutely wasn't, and still isn't, necessary. Full stop. ElasticSearch speaks HTTP. Why would I want it to reimplement HTTP authentication when I can place it behind a reverse proxy that's already integrated with my company's AAA and has been doing nothing but HTTP for oh, three decades or so? Separation of concerns. This is how this goes, and I've seen the pattern followed with several infrastructure services, even here in this HN thread right now: 1) A bug report comes in to AwesomeDB. "You do not have authentication support. This is bad. I'm going to yell about it on social media and make fun of you until you can accept a username and password, because everything in existence should write its own authentication code. Even MySQL takes passwords, dude, get with 2017." 2) A rough version is implemented by an intern, because authorization is way less sexy than hyperdimensional bloom filter quantum hash tables to speed up random reads. The intern then departs back to beer pong and nobody at AwesomeDB now understands the security infrastructure of their product. 3A) A mid-level executive, seeing the announcement, instructs me that I no longer have to keep AwesomeDB behind my 'stupid' reverse proxy + ACL solution and we can finally use native authentication and be really secure! 3B) Alternatively and more reastically, someone at Qualys adds "authentication is not turned on in AwesomeDB" to their scanning product and I get nastygrams from a contractor clicking "Scan" and copying and pasting the results for each of my fifty AwesomeDB instances. 4) During testing, I capture the credentials in plain text in about three minutes because it's a database. Why on earth would it terminate TLS? If we are down the 3B path above: Ha! Your move, security team! 5) Another bug report is filed against AwesomeDB to terminate TLS. Equal shaming is performed, because every service in the world needs to link in OpenSSL and terminate TLS, because that's never been a problem or backfired in any way. Oh yeah, and everyone has a different mechanism for handling certificates, and most don't bother to consider revocation. (Just like the broader point I'm making about auth, stop adding TLS support to your systems. Please. If you speak TCP I can wrap you in something uniform that does a much better job anyway. You know how I know your integration is shitty? Because OpenSSL is hopelessly undocumented and the APIs even more so. You Googled and read a guide. How about instead, I can drop a pretty awesome TLS listener in front of you, potentially even in hardware! Whoo!) 6) TLS support is added to AwesomeDB. Cool! Now we can really be secure! (But nobody implements client certificates, so we still have to do the username/password shared secret business. And alternate DH parameters? What are those? They weren't covered in the guide, so AwesomeDB hardcoded a couple.) At this point, most people would put credentials directly in their repo. I'd sit around making the Vault argument, but nobody would listen. We have now traded my ACLs and authentication stack for security on our private GitHub repos. I set to work automating changing all of our infrastructure passwords every time an intern leaves the company. We still secure the network, of course, but now there's special strings of characters in existence to work around a competent network security strategy that already existed. 7) As a growing company we introduce LDAP and Kerberos. Oh wait, AwesomeDB and its home brewed authentication stack do not support LDAP because what startup needs LDAP? 8) Another bug report is filed against AwesomeDB for "LDAP support." A bunch of startup engineers spend several months trying to understand the guts of LDAP (I feel your pain) and, worse, the cornucopia of vendor shenanigans in that space, and set the bug report to "holy shit, someday." A rough version that works with one exact schema and hopelessly avoids being just right for my needs might ship, or might not. 9) I redeploy my perfectly functional reverse proxy solution which has supported LDAP since the mid 90s and wire it up to Google OAuth for bonus points (getting rid of passwords for all corporate systems overnight! Neat!) while half the world pointlessly fights for every infrastructure service that exists to basically link in an operating system's worth of encryption and authentication support just to be a document store or search server. Given the choice I would very much rather secure my network or use well-established software to secure an infrastructure service. Asking every database vendor in existence to reimplement this stuff is a bad idea. People who blindly advocate for this sort of work, then paper over it with "you can't trust the network" without really supporting that statement, just generate busy work for companies that write infrastructure services. If you can't trust your network, what business do you have operating a production service that maintains user data? Do you really think having ElasticSearch do its own HTTP basic is more secure than any other solution? They at least had the JVM/netty/whatever to fall back on, where a lot of these infrastructure services have had to write their own authentication. There is a middle ground here and a lot of advocacy, both on HN and elsewhere, that misses the forest for the trees. Of course, none of this applies to MongoDB, because they were like sure, the world needs another bespoke binary protocol. You absolutely should be keeping your data on a secured network, though, and opaque strings of characters for system A to log in to system B might seem like defense in depth, but they end up in your source code, another system, or the working set of your executing process, and they are routinely captured by active adversaries. So. Having a mode where an infrastructure service assumes a connection is legitimate and just services the client is important. Some of us have a little more confidence in our security strategy than others and feel that we know what we are doing. Wiring that mode up to a 0.0.0.0 bind, by default, is the bug. Oh yeah, almost forgot: 10) All that custom authentication in AwesomeDB that you had an intern write becomes a CVE factory and starts reflecting on the security of the product. Womp womp.
vkou 10y ago
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.
user5994461 10y ago
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.
aioprisan 10y ago
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-checklist/ https://docs.mongodb.com/v3.2/administration/security-checkl...
- morgo 10y ago
  It is much harder to do this with MySQL. The default is now a randomly generated password. You have to overwrite it with --initialize-insecure if you want to setup with a blank password.
  - aioprisan 10y ago
    I don't buy that. Just did an apt-get install mysql-server and it let me install with a blank password (Ubuntu 16.04 MySQL Server 5.7)
    - morgo 10y ago
      It is most likely appearing to work without a password because it is using socket authentication (vs tcp). See: http://mysqlserverteam.com/secure-by-default-in-mysql-5-7/ http://mysqlserverteam.com/secure-by-default-in-mysql-5-7/ If you want to double check, try 'mysql --protocol=tcp'.
    - Sanddancer 10y ago
      That's ubuntu screwing things up, not mysql. When you run the init manually -- mysqld --initialize -- it does require a password.
      - aioprisan 10y ago
        Since we're just talking about defaults, you'd get an equally unsecured MySQL install on the latest and most popular AWS AMI today, as you would with old MongoDB installs.
edgan 10y ago
Elasticsearch is still this way, and actually tries to make you pay for Shield, their way of securing it.

by 51Cards 10y ago

andersonmvd 10y ago

We usually can't see the same problems happening in front of our noses. Why shouldn't we discuss why docker images run as root by default then?

jcrawfordor 10y ago
I think we absolutely should discuss this - the number of images I see on Docker Hub that run complex network services as the root user really concerns me. The security measures implemented by Docker reduce the risk but absolutely do not eliminate it, you're taking a big risk there. This issue, along with its related issues with permissions on persistent storage, is one of the major reasons I'm hoping to move away from Docker as soon as possible.
- tannhaeuser 10y ago
  What Docker security measures do you mean? Actually, I was wondering recently what isolation Docker provides that a basic chroot-jail doesn't. Re root permisions I guess if you're running a typical network daemon (Apache, say), then requiring Docker to run as root is no worse than running the service on the host; root would be a requisite anyway for the daemon to open privileged ports/gain logging permissions etc. before dropping to "nobody" or what have you.
  - kccqzy 10y ago
    Docker drops capabilities of root by default. It doesn't drop everything but better than not dropping at all. If you are not using docker, you can manually add the specific privilege to open low-numbered ports without running the program in question as root.

pjc50 10y ago

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.

at_tt 10y ago
Yeah though configuring login is not something that takes more time than to set it up.
giancarlostoro 10y ago
IIRC on Debian it is by default not listening externally. So ideally on Ubuntu as well. Though that is Debian / Ubuntu specific, elsewhere they likely ship with default configs. Still no default authentication, but still better than just letting anyone externally connect to it.
- hackcasual 10y ago
  But if a substantial use case requires it to listen remotely, you're just delaying disaster. Listening remotely should have required an authentication setup, or an additional configuration directive like "imbeingatotalidiotandamopeningmydatatuptoanymaluciousactors": true
__jal 10y ago
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 doesn't come until something like this happens. I don't know how wide-spread this thinking is, but it slots in well with a lot of the decisions I see made by other startup types. There seems to be a lot of conventional wisdom about the slimy-ish shortcuts and deceptions, bad design decisions, and so on that are "OK" to make to get off the ground. I'm not going to comment on the necessity of that sort of bad behavior from a business context; I think the answer is complex, and kind of appalling. But on the engineering side, it seems to usually lead to nasty things coming back to bite you, and it is notable that it does so after you've gotten attention and people depend on you.

richardwhiuk 10y ago

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).

cpuguy83 10y ago
This is a really bad practice to follow. You can't rely on the network to be secure.
- hueving 10y ago
  That's true in many cases, but if the network is solely for database access and the only servers with access to it would be configured with DB credentials anyway, then the path to compromise is equivalent (get into a server with db credentials/network access).
Cozumel 10y ago
This problem was caused by broken 'thinking' like that.
raverbashing 10y ago
> In production deployments, unsecured remote connections might be fine No. Absolutely not Unsecured local connections yes, anything from outside 127.0.0.1 should be explicitly allowed and secured (like port 80/443). Rate-limited, fail2banned, fuzzed during testing, etc
- Pxtl 10y ago
  "I opened the ports on the firewall and gave the user access, why doesn't it work!? This system is stupid." "I changed my password on one system and then on the other, but somehow my account got locked up in that brief time between changeover, how the hell do you unlock an account? This system is stupid." "We're scaling up and we're running into outdated rate-limiting settings on every service we use, some of them even having multiple layers of rate-limiting within a single service, and each setting requires hours of debugging to figure out which setting is taking down the whole project. This system is stupid." There's a reason Mongo got adoption while "secure" systems did not.

hitgeek 10y ago

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 alternative to much more mature relational data stores, which was and still is an unfair comparison.

nailer 10y ago
Even technically sophisticated users should be able to expect secure defaults.
- omni 10y ago
  Semantic counterargument: If you put a database into production without understanding its network and auth configuration then you are by definition not "technically sophisticated"
  - nailer 10y ago
    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 deep inside the documentation. Counterargument: many people who are good at a particular topic enjoy feeling superior to people who don't have their knowledge.
    - hitgeek 10y ago
      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.

cpuguy83 10y ago

Most likely this configuration is due to the traditional mongo use-case, which is to have data replicated between many nodes. This requires each participating node to be able to communicate with every other node.

bqe 10y ago

This is also the case for Elasticsearch. In fact, to get a proper username/password/ACL setup, you need to pay for professional support.

reqres 10y ago
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
- hinkley 10y ago
  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!
- deleted 10y ago
  [deleted]
- sneakymichael 10y ago
  It seemingly still does; I'm just getting started with Elasticsearch & your description aligns with what I've read in the introduction guide
  - polyfractal 10y ago
    Just FYI, multicast discovery was moved to a plugin in v2.0 [1], deprecated in v2.2 [2] and removed entirely in v5.0 [3] - [1] https://www.elastic.co/guide/en/elasticsearch/reference/2.0/breaking_20_removed_features.html#_multicast_discovery_is_now_a_plugin https://www.elastic.co/guide/en/elasticsearch/reference/2.0/... - [2] https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/discovery-multicast.html https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/di... - [3] https://www.elastic.co/guide/en/elasticsearch/plugins/5.1/discovery-multicast.html https://www.elastic.co/guide/en/elasticsearch/plugins/5.1/di...

pmlnr 10y ago

If this is not addressed at a _very_ early state of a software, it will stick, because people get used to it and you drive people away by backwards-incompatible changes. Especially if it's a software that's targeting people who wants things easy & fast, like Mongo did at the beginning. See reasons[1] for WordPress needing to be PHP 5.2 compatible, which had been out of support for 6 years. [1]: https://www.rarst.net/wordpress/technical-responsibility/ https://www.rarst.net/wordpress/technical-responsibility/

bogomipz 10y ago

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.

user5994461 10y ago
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!
- bogomipz 10y ago
  Elasticsearch never had authentication. So they never dropped it from the free version. I feel like it is an appropriate comparison. The general response to Elasticsearch's lack of security was "your'e supposed to run it behind a firewall" Elasticsearch got all the way to version 1.4 with no authentication as part of the design. Between 1.4.1 and 1.5 release candidates is when they announced Shield as part of their enterprise offering. Here are the release dates and announcements: https://www.elastic.co/blog/shield-know-security-coming-soon https://www.elastic.co/blog/shield-know-security-coming-soon https://www.elastic.co/downloads/past-releases?page=16 https://www.elastic.co/downloads/past-releases?page=16
  - jsmthrowaway 10y ago
    Because it absolutely wasn't, and still isn't, necessary. Full stop. ElasticSearch speaks HTTP. Why would I want it to reimplement HTTP authentication when I can place it behind a reverse proxy that's already integrated with my company's AAA and has been doing nothing but HTTP for oh, three decades or so? Separation of concerns. This is how this goes, and I've seen the pattern followed with several infrastructure services, even here in this HN thread right now: 1) A bug report comes in to AwesomeDB. "You do not have authentication support. This is bad. I'm going to yell about it on social media and make fun of you until you can accept a username and password, because everything in existence should write its own authentication code. Even MySQL takes passwords, dude, get with 2017." 2) A rough version is implemented by an intern, because authorization is way less sexy than hyperdimensional bloom filter quantum hash tables to speed up random reads. The intern then departs back to beer pong and nobody at AwesomeDB now understands the security infrastructure of their product. 3A) A mid-level executive, seeing the announcement, instructs me that I no longer have to keep AwesomeDB behind my 'stupid' reverse proxy + ACL solution and we can finally use native authentication and be really secure! 3B) Alternatively and more reastically, someone at Qualys adds "authentication is not turned on in AwesomeDB" to their scanning product and I get nastygrams from a contractor clicking "Scan" and copying and pasting the results for each of my fifty AwesomeDB instances. 4) During testing, I capture the credentials in plain text in about three minutes because it's a database. Why on earth would it terminate TLS? If we are down the 3B path above: Ha! Your move, security team! 5) Another bug report is filed against AwesomeDB to terminate TLS. Equal shaming is performed, because every service in the world needs to link in OpenSSL and terminate TLS, because that's never been a problem or backfired in any way. Oh yeah, and everyone has a different mechanism for handling certificates, and most don't bother to consider revocation. (Just like the broader point I'm making about auth, stop adding TLS support to your systems. Please. If you speak TCP I can wrap you in something uniform that does a much better job anyway. You know how I know your integration is shitty? Because OpenSSL is hopelessly undocumented and the APIs even more so. You Googled and read a guide. How about instead, I can drop a pretty awesome TLS listener in front of you, potentially even in hardware! Whoo!) 6) TLS support is added to AwesomeDB. Cool! Now we can really be secure! (But nobody implements client certificates, so we still have to do the username/password shared secret business. And alternate DH parameters? What are those? They weren't covered in the guide, so AwesomeDB hardcoded a couple.) At this point, most people would put credentials directly in their repo. I'd sit around making the Vault argument, but nobody would listen. We have now traded my ACLs and authentication stack for security on our private GitHub repos. I set to work automating changing all of our infrastructure passwords every time an intern leaves the company. We still secure the network, of course, but now there's special strings of characters in existence to work around a competent network security strategy that already existed. 7) As a growing company we introduce LDAP and Kerberos. Oh wait, AwesomeDB and its home brewed authentication stack do not support LDAP because what startup needs LDAP? 8) Another bug report is filed against AwesomeDB for "LDAP support." A bunch of startup engineers spend several months trying to understand the guts of LDAP (I feel your pain) and, worse, the cornucopia of vendor shenanigans in that space, and set the bug report to "holy shit, someday." A rough version that works with one exact schema and hopelessly avoids being just right for my needs might ship, or might not. 9) I redeploy my perfectly functional reverse proxy solution which has supported LDAP since the mid 90s and wire it up to Google OAuth for bonus points (getting rid of passwords for all corporate systems overnight! Neat!) while half the world pointlessly fights for every infrastructure service that exists to basically link in an operating system's worth of encryption and authentication support just to be a document store or search server. Given the choice I would very much rather secure my network or use well-established software to secure an infrastructure service. Asking every database vendor in existence to reimplement this stuff is a bad idea. People who blindly advocate for this sort of work, then paper over it with "you can't trust the network" without really supporting that statement, just generate busy work for companies that write infrastructure services. If you can't trust your network, what business do you have operating a production service that maintains user data? Do you really think having ElasticSearch do its own HTTP basic is more secure than any other solution? They at least had the JVM/netty/whatever to fall back on, where a lot of these infrastructure services have had to write their own authentication. There is a middle ground here and a lot of advocacy, both on HN and elsewhere, that misses the forest for the trees. Of course, none of this applies to MongoDB, because they were like sure, the world needs another bespoke binary protocol. You absolutely should be keeping your data on a secured network, though, and opaque strings of characters for system A to log in to system B might seem like defense in depth, but they end up in your source code, another system, or the working set of your executing process, and they are routinely captured by active adversaries. So. Having a mode where an infrastructure service assumes a connection is legitimate and just services the client is important. Some of us have a little more confidence in our security strategy than others and feel that we know what we are doing. Wiring that mode up to a 0.0.0.0 bind, by default, is the bug. Oh yeah, almost forgot: 10) All that custom authentication in AwesomeDB that you had an intern write becomes a CVE factory and starts reflecting on the security of the product. Womp womp.

vkou 10y ago

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.

user5994461 10y ago

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.

aioprisan 10y ago

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-checklist/ https://docs.mongodb.com/v3.2/administration/security-checkl...

morgo 10y ago
It is much harder to do this with MySQL. The default is now a randomly generated password. You have to overwrite it with --initialize-insecure if you want to setup with a blank password.
- aioprisan 10y ago
  I don't buy that. Just did an apt-get install mysql-server and it let me install with a blank password (Ubuntu 16.04 MySQL Server 5.7)
  - morgo 10y ago
    It is most likely appearing to work without a password because it is using socket authentication (vs tcp). See: http://mysqlserverteam.com/secure-by-default-in-mysql-5-7/ http://mysqlserverteam.com/secure-by-default-in-mysql-5-7/ If you want to double check, try 'mysql --protocol=tcp'.
  - Sanddancer 10y ago
    That's ubuntu screwing things up, not mysql. When you run the init manually -- mysqld --initialize -- it does require a password.
    - aioprisan 10y ago
      Since we're just talking about defaults, you'd get an equally unsecured MySQL install on the latest and most popular AWS AMI today, as you would with old MongoDB installs.

edgan 10y ago

Elasticsearch is still this way, and actually tries to make you pay for Shield, their way of securing it.