[TCM]

SCRAM authentication looks like a nice security improvement also. No description on the site but http://paquier.xyz/postgresql-2/postgres-10-scram-authentica... gives a good overview.

[pjungwir]

Seems like this might make using passwords compliant with FIPS 140-2. (Not sure, so maybe someone else can share their opinion.) Previously I heard in a few places that people would use LDAP to delegate the auth to something else, e.g. here: https://news.ycombinator.com/item?id=12129906

[xyzzy_plugh]

It's an improvement for sure, but I am curious -- does anyone situate a Postgres instance where it is publicly accessible? Who was asking for this feature?

[petereisentraut]

Several reasons:

- Checkbox item for people not wanting MD5 anymore.

- Storing passwords on the server in a securely hashed way, so the admin won’t know your password.

- PostgreSQL developers getting out of the roll-your-own-crypto game.

[dalyons]

Lots of cloud managed dbs are/can be publicly accessible. Eg all heroku hosted Postgres instances

[merb]

are they? even without ssl? by default?

[fdr]

SSL is (was?) required. I left Heroku about a year ago and it's nearly inconceivable that this would be changed, having been the case for many years.

I don't think they've implemented certificate validation since I've left though.

My naive hope, going on many years, is that SCRAM with channel binding would have landed years ago (the first versions of the patch began to show up then), making client-side certificate checking (and let's get real: it's hard enough to use that many people will not validate when developing from their laptops, simply backspacing out the optional cert validation connection option, a elision that is invisible to the server) obsolete. It should be possible to modify the definitions of pg_hba.conf to require a channel-bound SCRAM connection, which would mean that the client is certain to have checked for an untampered certificate.

This implementation of SCRAM doesn't have that yet, but it's been an ambition of the author for some time to do so.

[ioltas]

A patch implementing channel binding has been presented for integration into Postgres 11: https://commitfest.postgresql.org/14/1153/. Two channel types are presented: tls-finish and endpoint. Per the RFC 5802, it is mandatory to use SSL if you want channel binding as the data needed for binding validation is either the TLS finish message which can be found after the SSL handshake between the server and the client (which happens before the password-based authentication), and a hash of the server certificate. All those things are actually supported by a set of APIs in OpenSSL.

[pdimitar]

Not sure about SSL, but in the past customers of mine have copy-pasted full Heroku PG URLs to me and I was able to get in via `psql` immediately.

So yes they're public but their addresses are basically impossible to guess.

[cbowal]

Known as "Security through Obscurity" [0]

[0] https://en.wikipedia.org/wiki/Security_through_obscurity

[wongarsu]

Debatable. If the address is really unguessable, the address acts like a regular key.

It's still not good practice, since most systems treat addresses with far less care than passwords and often save and/or transmit them unencrypted.

[pdimitar]

Oh, I am not saying it's a good practice at all. I was just answering the question.

I still think it's a low-friction solution. But a secure one -- hardly.

[e12e]

> yes they're public but their addresses are basically impossible to guess.

Ipv6 only then?

[deepsun]

Sometimes people do a conference talk or just share the screen, and it's easy to take picture of that URL.

[pdimitar]

True. I am not saying it's the best idea around, only that it's low friction. I'd probably approach it differently but I can see why they did it like they did.

[anarazel]

I think by far the biggest benefit is being able to check the "no insecure crypto algorithms used" box. Even though the way md5 was used wasn't really that concerning security wise, it constantly comes up.