-7

A number of years ago now, still well into the 2000s, I was very naive. Especially in terms of computer security.

To make a long, painful story which I don't even remember myself all too well, the basic gist is that I set up a FreeBSD server at home with PostgreSQL. Being the naive fool that I was, I had no idea that there even existed such a thing as a "SSH tunnel" or anything like that. Thus, I assumed that the only way to connect to my database was to allow remote connections directly to it.

I didn't have a "NAT LAN" with internal IP addresses; instead, I had multiple "real" (external) IP addresses, one for my normal PC and one for the server. As such, this issue was made even more serious.

When setting up the so-called "pg_hba.conf" file, which controls how you can connect to the PostgreSQL database (separate from the user accounts or "roles"), I did not read or understand the manual and the comments in the file properly. For this reason, I interpreted the "trust" mode as meaning "trust, assuming that they give the right username and password". In reality, it meant "trust this username with ANY PASSWORD OR NO PASSWORD AT ALL".

Since I also had selected "all IP addresses" (because, even though they were "real" IP addresses, they were not static, and would sometimes change), this means that for over six months, my "secure" (as I imagined it in my stupid head) server with very private and sensitive data on it was sitting there for the entire world to freely connect to as long as they could just guess my very easily guessable PG username... from any IP address... with any or no password...

Only after months and months (again, six months sounds about right), did I revisit this file after getting cold feet. This was basically just a "hunch", and it could easily have continued like that for years and years. Still to this day I'm not sure if somebody did connect and stole all the data and is now sitting on it for future blackmail opportunities.

Yes, I was a complete idiot for not reading/understanding. I get it. I even agree. But still, why would it even have such a configuration possibility? Who would ever want it to "trust" somebody just providing the username/role and ignore the password, even though a password has been set? It makes zero sense to me. In my defense, it just never occurred in my brain that anyone would design a system in such a stupid manner. Yes, I do blame the database software designers to a degree, even though this was not the default configuration. I did actively change it, but why even make it possible to do that? The manual didn't exactly have a big fat warning about this, and not a single message was outputted when restarting the database to warn me about this or anything like that.

It just boggles my mind still to this day that such a configuration was (and probably still is) possible at all. You don't set a password for it to be bypassed like this. I'm still almost in disbelief over this.

Also, although I've never used it myself, in recent years, I've heard horror stories about MongoDB databases allowing the entire world to connect to them freely by default! That goes even further than PostgreSQL, and makes my skin crawl just thinking about it. I truly feel for those poor fools who trust that database and set it up thinking, just like I did with PG, that it's secure and sane.

Why do they do this? If it's to somehow give DBAs "job security", well, that's a really cruel way of accomplishing that. Even though it was largely/mostly my fault, I still hold this against the PostgreSQL developers and probably will never "drop it" mentally. In the case of MongoDB, it seems like they really did it on purpose, since it was by default. I don't understand how they can put their users at risk like this, especially not without the user even changing the configuration.

  • 1
    If you can control access to the server itself, there is nothing really wrong with using trust for local connections. Of course this is pretty dangerous for a computer visible to the world. But for a computer only visible inside a closed network, this can be controlled quite easily – a_horse_with_no_name Feb 9 at 11:18
1

In PostgreSQL, it is a pretty common set up to have "local" type set to "trust" or "peer", but "host*" types set to "md5" or the new "scram-sha-256" method. You seem to want the existence of a password to disable "trust", that would disable this setup as the password can't exist in one socket access method and not the other. I'd be pretty annoyed to have this broke because someone else can't bother the read the documentation for what they are doing.

You could do something more complicated, like having the password set could disable "trust" only for "host*" and only if the IP address has a netmask less than 32 bits (but is 32 the right number? If someone sets the netmask with 28 bit, that suggests they know what they are doing and set up network segmentation correctly, while 8 bits probably doesn't suggest that). But that just makes it more complicated, making it even less likely people will bother to read and understand the documentation.

If it were being redesigned from scratch with no concern for backward compatibility, perhaps it would be done differently.

Not the answer you're looking for? Browse other questions tagged or ask your own question.