41–50 of 223 posts
Postgres' defaults barely let you connect to the DB. You don't hear stories like this about Postgres.
I guess secure by default means there aren't likely to be massive hacks like this, but it does not mean people are running securely.
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…
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).
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…
Who, when wanting to write a secure piece of software, thinks: "I know! I'll use JavaScript!"? Security was always going to be an afterthought at best. There are legitimate reasons for writing things in JavaScript, and none of them apply to a database.
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…
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 also the case for Elasticsearch. In fact, to get a proper username/password/ACL setup, you need to pay for professional support.
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…
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/
Postgres' defaults barely let you connect to the DB. You don't hear stories like this about Postgres.
Well, sure but then people just open the flood gates because it's such a pain in the ass to change postgres access policies. I guess secure by default means there aren't likely to be massive hacks like this, but it does not mean people are running securely.
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…
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.
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.