Comment by nemild | Hacker News Reader

Comment by nemild | Hacker News Reader

Parent Full thread

I'd be interested to know which version of MongoDB this was.

This "no auth" was a default choice for MongoDB through at least 2013 (in this case, it helped to find nefarious actions).

For more background, I wrote a three-part MongoDB[1]. These are the notes on auth behavior from the interview with MongoDB's CTO:

> - Defaults: I feel like it’s playing with fire to set bad defaults in a database - with numerous data breaches due to 10gen’s early decisions on authentication, remote login, and encryption (see for example, https://snyk.io/blog/mongodb-hack-and-secure-defaults/ ). For auth, Eliot argues that developers need to take responsibility for exposing MongoDB on public servers - and that the SLA for a self-hosted instance is different than a managed instance (at minimum, I have issues with users having their data exposed to the world through no fault of their own). He disagreed with 10gen’s decision to turn on auth by default in later self-hosted versions once MongoDB ignored remote connections by default (but thought this was the right choice for the managed Atlas service). (But before 2014, the default behavior was no auth - and accepting all remote connections, see https://snyk.io/blog/mongodb-hack-and-secure-defaults/ ; Eliot notes that this took a while because changing the default would have caused issues for existing customers)

( https://news.ycombinator.com/item?id=14804765 )

[1] https://www.nemil.com/mongo/

For auth, Eliot argues that developers need to take responsibility for exposing MongoDB on public servers

That’s like selling a car without preinstalled seat belts and then saying it is the responsibility of the driver if they take it on the road like that. It’s technically true, but it’s sort of missing the point.

I made the same seat belt point to him, and here's the section with his response:

> I do have concerns when 10gen explicitly targets junior developers ... What [Eliot, MongoDB CTO] says makes sense say 20 years ago, but with 25% of new software engineers coming from coding bootcamps with non-engineering backgrounds, I worry that defaults matter ever more in dev tools (and even seasoned engineers may mess this up, if they’re coming from a database with different defaults). We discussed analogies like seat belt lights versus the responsibility of passengers to know better. He also argued that waiting to get all this right - not just auth - would impact database innovation, while I think there’s a balance that gets us a lot of the low hanging fruit (like security).

https://news.ycombinator.com/item?id=14804765

My position, which I'm starting to get loud about, is that defaults matter more because the most recent shift in developer 'standards', for better or worse, is to expect us to use a vast number of tools to do our work.

If I have to use a vast number of tools, not only can't I be an expert in all of them, I can't even dedicate 5% of my attention to each one of them. Or really, to any of them. Because if I do, then I have nothing left to fulfill my job description. I'd just be curating a list of third party code all day long.

We either need to back away from the 'npm install' model or we need to really start thinking about our libraries as cattle. Which means they all have to behave in a predictable fashion or we cull them from the herd.

You can't have it both ways. We can't use peer pressure to stop people from writing their own (NIH), and then blame the victim when tools behave in surprising ways. The safeties need to be on by default, and only a few things in our lives can be so dangerous that we require special training to use them without killing ourselves. We only have space for a handful.

We need to develop the humility to accept that our module should be boring to the people using it, rather than a special snowflake. Take pride in the utility, not the notoriety.

> with 25% of new software engineers coming from coding bootcamps with non-engineering backgrounds

This is unnecessarily elitist: I’ve seen no difference in security awareness based on anything other than specializing in security, and even then it can be surprisingly blinkered.

That's fair. I was mostly reflecting on the time that most bootcamps spend on a student (2-3 months) relative to other programs.

But I agree that no matter the program, security best practices are rarely taught.

Agreed — I often feel like we’re in the period where the germ theory of disease is known but it’s still a battle to get doctors to wash their hands.

Or selling a gun without a safety.

"Well just don't shoot yourself or the wrong people silly!"

Dude that is not what happens in the real world!

Rule number one of firearms is never point it at anything with a round in the chamber unless you want it dead. That's an iron rule. You can't depend on safeties working 100% of the time, even in designs that have them.

You're not wrong about that, but humans are terrible about following instructions, that's kinda what I was getting at.

Sell thing where they say "well don't do that" doesn't make much sense in some cases.

I thought it was don't point it at anything you don't want dead i.e always assume there's a round in the chamber.

Many guns are manufactured and sold without safeties. Personal responsibility transcends industry.

Name a handgun in current production, that you can buy in any Western country, that has no safety on it.

Revolvers.

Fun fact: one of the bartenders at my old watering hole was playing with the "bar gun", flipping the cylinder closed by flicking his wrist, and shot a round into the wall. Luckily I wasn't there that night because accidental discharges are a beatable offence.

I've had an ND only once in my life, and it was with a target rifle with a <1 lb trigger pointed downrange. It still scared the bejesus out of me.

If someone shot a round into a wall at a bar, it would be more than a beatable offence for me.

Handguns without safeties are really common - in fact most newly purchased police guns in the US today don't require anything beyond pulling the trigger.

The two most popular handgun lines in the US, the Glock[1] and the M&P[2], don't have what a laymen would consider a safety. The Sig P250[3], of CounterStrike fame, has no safety of any kind whatsoever.

[1] https://en.wikipedia.org/wiki/Glock [2] https://en.wikipedia.org/wiki/Smith_%26_Wesson_M%26P [3] https://en.wikipedia.org/wiki/SIG_Sauer_P250

ALL Glocks have a safety. It is integrated into the trigger pull mechanism.

(You should NEVER put your finger on a gun's trigger unless you intend to fire it. This is taught in all good gun safety courses.)

It is disingenuous to conflate a trigger "safety" with a classic manual safety. One requires unlocking as a separate action from pulling the trigger, and has it's own state independent of the trigger.

I doubt the original commenter new the difference, and was most likely referring to manual safeties.

Bought this online not too long ago, M&P 9c No Thumb Safety.

https://www.sportsmansoutdoorsuperstore.com/products2.cfm/ID...

The Glock, one of the most common pistols for law enforcement and military, has no safety catch.

There's internal safeties to stop it from discharging if you drop it, but there's no safety to stop you from pulling the trigger and discharging a round.

You're right about pistols, but revolvers have no safety mechanisms (in general, at least), and they're handguns.

Sadly Glock has one of those on the trigger safeties... it's absurd.

Kel-Tec P-32?

I don't agree with your analogy. A database is not an consumer product, it's a tool and the people using it are responsible for its appropriate use.

To me this sounds like the hardware store selling saws, an uneducated consumer coming in and buying one and then going home and cutting their finger off and complaining that the hardware store should sell safer saws.

It's your responsibility to educate yourself on proper and safe operation of your tools.

My guess is most cases where this happens the developer don't know the server is public. I've seen it happen at past companies where DB/Services were accidentally configured on AWS with a public IP and VPC wasn't set up correctly to make it more explicit when exposing public services.

That's a wrong analogy, because the security itself is there, it's just that the user has to turn it on. It would be more like selling a car and allowing to drive it without seatbelts.

Reply on news.ycombinator.com