3 ms·
Congratulations, now there are plaintext passwords in your server logs... I did exactly what you are suggesting on a project some time ago - deferred to the da
by NickNameNick 11y ago
Congratulations, now there are plaintext passwords in your server logs...
I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved the hashing process into the web server.
- swang 11y agoI don't see how moving to the web server would prevent that if you were logging passed req body or query parameters since they would be posted in plaintext (hopefully) over a https connection.
- theIV 11y agoI'm not sure but I'm assuming this has more to do with Postgres' WAL than it does filtering logs. I've never used this side of Postgres though, so just a guess.
- minitech 11y ago“query parameters” here are the parameters passed to PostgreSQL. That is, "SELECT * FROM users WHERE password_hash = get_hash('P4ssw0rd')" is being logged, not "?password=P4ssw0rd".
- NickNameNick 11y agoExactly so. The webserver framework I was using at the time logged all its queries to the database at the normal log level. It couldn't log an actual query string because we used prepared statements, but it reconstructed the query and substituted the parameters in. Enormously helpful for debugging an issue, when you can just copy and paste a query out of the serverlogs. Although I would probably have preferred that it not do that at the normal log level. Curiously, it never logged the http request string/parameters. When I wanted that I had to add my own code to the request handler.