Live data from Hacker News

Securing PostgreSQL [pdf]

thebuild.com

71–72 of 72 posts

Re: Securing PostgreSQL [pdf]

#71

Earlier quoted context omitted.

i am curious, you are commenting on a post about secure postgres but after signing up for your service i see that the database i created is publicly available, on the standard port 5432, with the default postgres username. the only thing stopping me is a password, no certificate required. i am not a postgres expert but how is this not extremely insecure?

"Extremely" insecure is a bit of an exaggeration. It's not as though the password is "password" on all the databases. We do support certificate-based logins and firewalls with IP whitelists. They're just not on by default. Frankly, the reason is because almost all customers don't care about having a very high level of security if that implies doing more work (setting up certificates, whitelisting IPs.) Moreover, they…

Out of curiosity, can one change these settings for their own databases automatically via some "control panel" or such, or does it require intervention from your staff?

Fortunately, I think there have been fewer "unauthenticated remote access" vulnerabilities with PostgreSQL than MySQL so this (being accessible from 0/0) probably isn't a huge deal. That said, I'd look for ways to restrict who can actually connect to 5432/TCP that won't negatively affect the majority of your customers (e.g., if your databases are running on DigitalOcean, can you restrict connections to that particular DO datacenter by default and provide an option to loosen those restrictions in increments -- "this datacenter", "all DO datacenters", "the world", etc.?).

Re: Securing PostgreSQL [pdf]

#72

Earlier quoted context omitted.

"Extremely" insecure is a bit of an exaggeration. It's not as though the password is "password" on all the databases. We do support certificate-based logins and firewalls with IP whitelists. They're just not on by default. Frankly, the reason is because almost all customers don't care about having a very high level of security if that implies doing more work (setting up certificates, whitelisting IPs.) Moreover, they…

Out of curiosity, can one change these settings for their own databases automatically via some "control panel" or such, or does it require intervention from your staff? Fortunately, I think there have been fewer "unauthenticated remote access" vulnerabilities with PostgreSQL than MySQL so this (being accessible from 0/0) probably isn't a huge deal. That said, I'd look for ways to restrict who can actually connect to…

These settings are currently manually operated by staff, via support@databaselabs.io.

That will get added to the control panel eventually, but right now as approximately zero percent of customers want those things, it's not a good use of our limited engineering time to even automate that, versus other things that engineers could be doing with their time.

While it would be nice in theory to restrict them by default, in practice there's just no restriction that's close enough to universally applicable to be workable (i.e. one that won't disrupt a large number of users' use of the database if it's applied everywhere.)

And you are correct, there are essentially zero unauthenticated remote access vulnerabilities that come out in Postgres. Combine that with:

* All connections require SSL * The password is a long string of randomly generated characters * We actively monitor the network for unusual traffic patterns

and it's actually not so bad. Not ideal of course, but very much not "extremely" insecure, as the above post said.

Post reply on HN