Re: Password leakage avoidance

On 1/6/24 15:10, Tom Lane wrote: Joe Conway writes: The only code specific comments were Tom's above, which have been addressed. If there are no serious objections I plan to commit this relatively soon. I had not actually read this patchset before, but now I have, and I have a few minor

Re: Password leakage avoidance

Joe Conway writes: > The only code specific comments were Tom's above, which have been > addressed. If there are no serious objections I plan to commit this > relatively soon. I had not actually read this patchset before, but now I have, and I have a few minor suggestions: * The API comment

Re: Password leakage avoidance

On 1/6/24 13:16, Sehrope Sarkuni wrote: On Sat, Jan 6, 2024 at 12:39 PM Joe Conway > wrote: The only code specific comments were Tom's above, which have been addressed. If there are no serious objections I plan to commit this relatively soon. One more

Re: Password leakage avoidance

Scratch that, rather than memset(...) should be explicit_bzero(...) so it doesn't get optimized out. Same idea though. Regards, -- Sehrope Sarkuni Founder & CEO | JackDB, Inc. | https://www.jackdb.com/ >

Re: Password leakage avoidance

On Sat, Jan 6, 2024 at 12:39 PM Joe Conway wrote: > The only code specific comments were Tom's above, which have been > addressed. If there are no serious objections I plan to commit this > relatively soon. > One more thing that we do in pgjdbc is to zero out the input password args so that

Re: Password leakage avoidance

On Sat, Jan 6, 2024 at 11:53 AM Joe Conway wrote: > On 1/2/24 07:23, Sehrope Sarkuni wrote: > > 1. There's two sets of defaults, the client program's default and the > > server's default. Need to pick one for each implemented function. They > > don't need to be the same across the board. > > Is

Re: Password leakage avoidance

On 12/24/23 10:14, Joe Conway wrote: On 12/23/23 11:00, Tom Lane wrote: Joe Conway writes: The attached patch set moves the guts of \password from psql into the libpq client side -- PQchangePassword() (patch 0001). Haven't really read the patch, just looked at the docs, but here's a bit of

Re: Password leakage avoidance

On 1/2/24 07:23, Sehrope Sarkuni wrote: 1. There's two sets of defaults, the client program's default and the server's default. Need to pick one for each implemented function. They don't need to be the same across the board. Is there a concrete recommendation here? 2. Password encoding

Re: Password leakage avoidance

On 1/3/24 7:53 AM, Robert Haas wrote: Also, +1 for the general idea. I don't think this is a whole answer to the problem of passwords appearing in log files because (1) you have to be using libpq in order to make use of this and (2) you have to actually use it instead

Re: Password leakage avoidance

On 1/2/24 7:23 AM, Sehrope Sarkuni wrote: Having worked on and just about wrapped up the JDBC driver patch for this, couple thoughts: 2. Password encoding should be split out and made available as its own functions. Not just as part of a wider "create _or_ alter a user's password" function

Re: Password leakage avoidance

On Wed, 3 Jan 2024 at 08:53, Robert Haas wrote: > On Sun, Dec 24, 2023 at 12:06 PM Jonathan S. Katz > wrote: > > We're likely to have new algorithms in the future, as there is a draft > > RFC for updating the SCRAM hashes, and already some regulatory bodies > > are looking to deprecate SHA256.

Re: Password leakage avoidance

On Sun, Dec 24, 2023 at 12:06 PM Jonathan S. Katz wrote: > We're likely to have new algorithms in the future, as there is a draft > RFC for updating the SCRAM hashes, and already some regulatory bodies > are looking to deprecate SHA256. My concern with relying on the > "encrypted_password" GUC

Re: Password leakage avoidance

Having worked on and just about wrapped up the JDBC driver patch for this, couple thoughts: 1. There's two sets of defaults, the client program's default and the server's default. Need to pick one for each implemented function. They don't need to be the same across the board. 2. Password encoding

Re: Password leakage avoidance

On 12/31/23 9:50 AM, Magnus Hagander wrote: On Wed, Dec 27, 2023 at 10:31 PM Jonathan S. Katz wrote: On 12/24/23 12:15 PM, Tom Lane wrote: Maybe we need a PQcreaterole that provide the mechanism to set passwords safely. It'd likely need to take all the options need for creating a role, but

Re: Password leakage avoidance

On Wed, Dec 27, 2023 at 10:31 PM Jonathan S. Katz wrote: > > On 12/24/23 12:15 PM, Tom Lane wrote: > > >> Maybe we need a PQcreaterole that provide the mechanism to set passwords > >> safely. It'd likely need to take all the options need for creating a > >> role, but that would at least give the

Re: Password leakage avoidance

On 12/24/23 12:15 PM, Tom Lane wrote: Maybe we need a PQcreaterole that provide the mechanism to set passwords safely. It'd likely need to take all the options need for creating a role, but that would at least give the underlying mechanism to ensure we're always sending a hashed password to the

Re: Password leakage avoidance

On 12/27/23 16:09, Tom Lane wrote: Joe Conway writes: On 12/27/23 15:39, Peter Eisentraut wrote: On 23.12.23 16:13, Joe Conway wrote: The attached patch set moves the guts of \password from psql into the libpq client side -- PQchangePassword() (patch 0001). I don't follow how you get from

Re: Password leakage avoidance

On Wed, 27 Dec 2023 at 16:10, Tom Lane wrote: > Joe Conway writes: > > On 12/27/23 15:39, Peter Eisentraut wrote: > >> On 23.12.23 16:13, Joe Conway wrote: > >>> The attached patch set moves the guts of \password from psql into the > >>> libpq client side -- PQchangePassword() (patch 0001). > >

Re: Password leakage avoidance

Joe Conway writes: > On 12/27/23 15:39, Peter Eisentraut wrote: >> On 23.12.23 16:13, Joe Conway wrote: >>> The attached patch set moves the guts of \password from psql into the >>> libpq client side -- PQchangePassword() (patch 0001). >> I don't follow how you get from the problem statement to

Re: Password leakage avoidance

On 12/27/23 15:39, Peter Eisentraut wrote: On 23.12.23 16:13, Joe Conway wrote: I have recently, once again for the umpteenth time, been involved in discussions around (paraphrasing) "why does Postgres leak the passwords into the logs when they are changed". I know well that the canonical

Re: Password leakage avoidance

On 23.12.23 16:13, Joe Conway wrote: I have recently, once again for the umpteenth time, been involved in discussions around (paraphrasing) "why does Postgres leak the passwords into the logs when they are changed". I know well that the canonical advice is something like "use psql with

Re: Password leakage avoidance

Joe Conway writes: > Oh well, I guess I will get with the program and put every patch-set > into its own directory. Yeah, that's what I've started doing too. It does have some advantages, in that you can squirrel away other related files in the same subdirectory.

Re: Password leakage avoidance

On 12/24/23 12:22, Tom Lane wrote: Joe Conway writes: Completely unrelated process bikeshedding: I changed the naming scheme I used for the split patch-set this time. I don't know if we have a settled/documented pattern for such naming, but the original pattern which I borrowed from someone

Re: Password leakage avoidance

Joe Conway writes: > Completely unrelated process bikeshedding: > I changed the naming scheme I used for the split patch-set this time. I > don't know if we have a settled/documented pattern for such naming, but > the original pattern which I borrowed from someone else's patches was >

Re: Password leakage avoidance

"Jonathan S. Katz" writes: > I think this is a good start and adds something that's better than what > we have today. However, it seems like we also need something for "CREATE > ROLE", otherwise we're either asking users to set passwords in two > steps, or allowing for the unencrypted password

Re: Password leakage avoidance

On 12/24/23 10:14 AM, Joe Conway wrote: On 12/23/23 11:00, Tom Lane wrote: Joe Conway writes: The attached patch set moves the guts of \password from psql into the libpq client side -- PQchangePassword() (patch 0001). Haven't really read the patch, just looked at the docs, but here's a bit

Re: Password leakage avoidance

On 12/23/23 11:00, Tom Lane wrote: Joe Conway writes: The attached patch set moves the guts of \password from psql into the libpq client side -- PQchangePassword() (patch 0001). Haven't really read the patch, just looked at the docs, but here's a bit of bikeshedding: Thanks! * This seems

Re: Password leakage avoidance

Dave Cramer www.postgres.rocks On Sat, 23 Dec 2023 at 11:00, Tom Lane wrote: > Joe Conway writes: > > The attached patch set moves the guts of \password from psql into the > > libpq client side -- PQchangePassword() (patch 0001). > > Haven't really read the patch, just looked at the docs, but

Re: Password leakage avoidance

Joe Conway writes: > The attached patch set moves the guts of \password from psql into the > libpq client side -- PQchangePassword() (patch 0001). Haven't really read the patch, just looked at the docs, but here's a bit of bikeshedding: * This seems way too eager to promote the use of md5.

Password leakage avoidance

I have recently, once again for the umpteenth time, been involved in discussions around (paraphrasing) "why does Postgres leak the passwords into the logs when they are changed". I know well that the canonical advice is something like "use psql with \password if you care about that". And