On Mon, Feb 24, 2025 at 5:07 AM Aleksander Alekseev < aleksan...@timescale.com> wrote:
> If the problem is that the password might be logged, wouldn't a proper > solution be not to log such queries? > Yes, this has been discussed before. The short answer is that it is extremely difficult to implement reliably because we would need to add some artificial intelligence to our parser and/or logger to prevent passwords from being added via syntax errors. Even preventing certain valid commands from being logged is fraught with edge cases and difficult tradeoffs. As mentioned, it's also not just direct logging, it's things like pg_stat_activity and pg_stat_statements. The real solution is to train people and applications not to send clear text passwords. If the command fails to work, that's a pretty good way to train them. > I don't see how a warning and an extra GUC will improve the overall > security of the system, and I suspect very few users will voluntarily > trade convenience to security by choosing "disallow". So in its current > state the patch doesn't seem to help much. > One of the main goals is to start leading people away from using insecure methods. Like with MD5, first we warn, then we disable usage (but allow a way to enable for stubborn users/applications). So I would say the goals are: * Provide a warning, so people are aware that sending passwords in the clear is a bad idea. Right now, there is no warning. Quite the improvement. * Provide a way to disable using clear text passwords. Also a win for people like the OP in another thread that wants to prevent password changes from ending up in the logs. Now they can (and may help with PCI compliance and related things). * Provide notice to applications/drivers/frameworks that clear text passwords are deprecated and they should provide (or recommend) an alternate method. * Lay the groundwork for eventually disallowing plain text passwords completely. A long way off, but this is the start. After a couple years, we could switch the default from "warn" to "disallow". A few years after that, disallow completely. I know it is not a perfect solution, and likely never will be, but we can't let the perfect be the enemy of the good. This seems a good, small incremental step. The three-value solution also allows for complete backwards compatibility, while still allowing admins to throw a warning or error if desired. Cheers, Greg -- Crunchy Data - https://www.crunchydata.com Enterprise Postgres Software Products & Tech Support
