Re: Password leakage avoidance - Mailing list pgsql-hackers

From Sehrope Sarkuni
Subject Re: Password leakage avoidance
Date
Msg-id CAH7T-ap7wjmY3Qk9wYJVLnJxaqAcnPFU=_gCRURMZcKTGH2vnQ@mail.gmail.com
Whole thread Raw
In response to Re: Password leakage avoidance  (Joe Conway <mail@joeconway.com>)
Responses Re: Password leakage avoidance
Re: Password leakage avoidance
List pgsql-hackers
On Sat, Jan 6, 2024 at 12:39 PM Joe Conway <mail@joeconway.com> 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 they don't remain in memory even after being freed. It's kind of odd in Java as it makes the input interface a char[] and we have to convert them to garbage collected Strings internally (which kind of defeats the purpose of the exercise).

But in libpq could be done via something like:

memset(pw1, 0, strlen(pw1));
memset(pw2, 0, strlen(pw2));

There was some debate on our end of where to do that and we settled on doing it inside the encoding functions to ensure it always happens. So the input password char[] always gets wiped regardless of how the encoding functions are invoked.

Even if it's not added to the password encoding functions (as that kind of changes the after effects if anything was relying on the password still having the password), I think it'd be good to add it to the command.c stuff that has the two copies of the password prior to freeing them.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/ 

pgsql-hackers by date:

Previous
From: Sehrope Sarkuni
Date:
Subject: Re: Password leakage avoidance
Next
From: Sehrope Sarkuni
Date:
Subject: Re: Password leakage avoidance