5 ms·

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,

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?

pjlegato 10y ago
"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 actively prefer to have "simpler and less secure" over "more complex and more secure." We've done experiments with certificates and firewall IP whitelists and so on. Almost all customers and potential customers reject these things. They say they want a simple password that just works from anywhere. We had to choose between being slightly less secure and having customers, versus being highly secure and having no customers. Since the business can't survive without any customers, that choice was easy. That said, if you do want any of those things turned on for your database, just write support@databaselabs.io.
- jlgaddis 10y ago
  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.?).
  - pjlegato 10y ago
    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.

pjlegato 10y ago

"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 actively prefer to have "simpler and less secure" over "more complex and more secure." We've done experiments with certificates and firewall IP whitelists and so on. Almost all customers and potential customers reject these things. They say they want a simple password that just works from anywhere. We had to choose between being slightly less secure and having customers, versus being highly secure and having no customers. Since the business can't survive without any customers, that choice was easy. That said, if you do want any of those things turned on for your database, just write support@databaselabs.io.

jlgaddis 10y ago
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.?).
- pjlegato 10y ago
  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.