Re: Password leakage avoidance

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> 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 to leak to the logs via
> CREATE ROLE.

> 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 server.

I'm kind of down on that, because it seems like it'd be quite hard to
design an easy-to-use C API that doesn't break the next time somebody
adds another option to CREATE USER. What's so wrong with suggesting
that the password be set in a separate step? (For comparison, typical
Unix utilities like useradd(8) also tell you to set the password
separately.)

regards, tom lane