SCRAM authentication fails #155
Comments
|
Ran into this exact issue today. PostgreSQL 14 changed the default password hashing algorithm from MD5 to SCRAM-SHA-256. To set it back to md5: Then change a new password (or re-enter the existing one): Alternatively, if you're using Timescale Cloud you can do this in their UI. When resetting it'll provide the option to hash using either SCRAM-SHA-256 or MD5. Select MD5 for compatibility with pgbouncer. Are there any plans to make the pgbouncer buildpack scram-sha-256 compatible? |
mble-sfdc
added a commit
that referenced
this issue
May 21, 2024
In order to support SCRAM support for the new Heroku Postgres "Essential" plans, we need to shift from MD5 hashed passwords in `auth_file` to plain text. This does not materially change the threat model, as anyone with dyno access can read the passwords from the environment just as well as the file. See: https://www.pgbouncer.org/config.html#authentication-file-format for more. This commit switches the `auth_type` to `scram-sha-256` and also pushes `server_tls_sslmode` up to `require` over `prefer`. Why not use a method like `auth_query`? Exposing something like `pg_authid` or `pg_shadow` in a safe way via a `SECURITY DEFINER` function is extremely challenging in a multi-tenant environment. This may change in the future. Fixes #155. Ref: https://gus.my.salesforce.com/a07EE00001rjvVBYAY
mble-sfdc
added a commit
that referenced
this issue
May 21, 2024
In order to support SCRAM support for the new Heroku Postgres "Essential" plans, we need to shift from MD5 hashed passwords in `auth_file` to plain text. This does not materially change the threat model, as anyone with dyno access can read the passwords from the environment just as well as the file. See: https://www.pgbouncer.org/config.html#authentication-file-format for more. This commit switches the `auth_type` to `scram-sha-256` and also pushes `server_tls_sslmode` up to `require` over `prefer`. Why not use a method like `auth_query`? Exposing something like `pg_authid` or `pg_shadow` in a safe way via a `SECURITY DEFINER` function is extremely challenging in a multi-tenant environment. This may change in the future. Fixes #155. Ref: https://gus.my.salesforce.com/a07EE00001rjvVBYAY
troycoll
pushed a commit
that referenced
this issue
May 23, 2024
* maint: enable SCRAM support In order to support SCRAM support for the new Heroku Postgres "Essential" plans, we need to shift from MD5 hashed passwords in `auth_file` to plain text. This does not materially change the threat model, as anyone with dyno access can read the passwords from the environment just as well as the file. See: https://www.pgbouncer.org/config.html#authentication-file-format for more. This commit switches the `auth_type` to `scram-sha-256` and also pushes `server_tls_sslmode` up to `require` over `prefer`. Why not use a method like `auth_query`? Exposing something like `pg_authid` or `pg_shadow` in a safe way via a `SECURITY DEFINER` function is extremely challenging in a multi-tenant environment. This may change in the future. Fixes #155. Ref: https://gus.my.salesforce.com/a07EE00001rjvVBYAY * update tests * add updates from feedback
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there,
I'm trying to setup on dyno pgbouncers connecting to our external timescaledb (postgres) instances. It seems as though something on the postgres side of things is not compatible with this pgbouncer.
I'm seeing the following in the logs:
I would assume the important bit is the
cannot do SCRAM authentication: wrong password type.Any suggestions on a workaround?
The text was updated successfully, but these errors were encountered: