Hacker News new | past | comments | ask | show | jobs | submit login

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




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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: