public inbox for [email protected]help / color / mirror / Atom feed
What are best practices wrt passwords? 4+ messages / 4 participants [nested] [flat]
* What are best practices wrt passwords? @ 2024-10-16 09:35 [email protected] 0 siblings, 3 replies; 4+ messages in thread From: [email protected] @ 2024-10-16 09:35 UTC (permalink / raw) To: pgsql-general Hello all, I'd like to be able to use psql without typing passwords again and again. I know about `.pgpass` and PGPASSFILE, but I specifically do not want to use it - I have the password in the `.env` file, and having it in _two_ places comes with its own set of problems, like how to make sure they don't get out of sync. I understand why giving the password on the command line or in an environment variable is a security risk (because of `ps`), but I do not understand why `psql` doesn't have an option like `--password-command` accepting a command which then prints the password on stdout. For example, I could then use `pass` (https://www.passwordstore.org/) with gpg-agent. Is there any risk associated with this usage pattern? What is the recommended practice in my case other than using `.pgpass`? Thanks in advance, P.S. Please CC me in replies, since I'm not subscribed to the list. Thanks. -- Marcin Borkowski https://mbork.pl https://crimsonelevendelightpetrichor.net/ ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: What are best practices wrt passwords? @ 2024-10-16 12:41 Dominique Devienne <[email protected]> parent: [email protected] 2 siblings, 0 replies; 4+ messages in thread From: Dominique Devienne @ 2024-10-16 12:41 UTC (permalink / raw) To: [email protected]; +Cc: pgsql-general On Wed, Oct 16, 2024 at 2:25 PM <[email protected]> wrote: > I'd like to be able to use psql without typing passwords again and > again. I know about `.pgpass` and PGPASSFILE, but I specifically do not > want to use it - I have the password in the `.env` file, and having it > in _two_ places comes with its own set of problems, like how to make > sure they don't get out of sync. What's wrong with PGPASSWORD? https://www.postgresql.org/docs/current/libpq-envars.html > I understand why giving the password on the command line or in an > environment variable is a security risk (because of `ps`), but I do not > understand why `psql` doesn't have an option like `--password-command` > accepting a command which then prints the password on stdout. For > example, I could then use `pass` (https://www.passwordstore.org/) with > gpg-agent. It's not psql, it's libpq, that does that, FTR. My own apps are libpq based, and inherit all its env-vars and defaults. But I'd welcome a way to store password encrypted, unlike the current mechanisms. And what you propose would allow that I guess, if I understand correctly. So +1. (and since transient better than enrypted/obfuscated passwords) > Is there any risk associated with this usage pattern? What is the > recommended practice in my case other than using `.pgpass`? Storing password in plain text? --DD ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: What are best practices wrt passwords? @ 2024-10-16 14:16 [email protected] parent: [email protected] 2 siblings, 0 replies; 4+ messages in thread From: [email protected] @ 2024-10-16 14:16 UTC (permalink / raw) To: pgsql-general Use the PGPASSWORD environment variable. Example: SET PGPASSWORD=P0stgres psql -h localhost -p 5432 -U postgres -d postgres -c "SELECT 1;'" https://www.postgresql.org/docs/current/libpq-envars.html On Wednesday, October 16, 2024 at 08:26:05 AM GMT-4, <[email protected]> wrote: Hello all, I'd like to be able to use psql without typing passwords again and again. I know about `.pgpass` and PGPASSFILE, but I specifically do not want to use it - I have the password in the `.env` file, and having it in _two_ places comes with its own set of problems, like how to make sure they don't get out of sync. I understand why giving the password on the command line or in an environment variable is a security risk (because of `ps`), but I do not understand why `psql` doesn't have an option like `--password-command` accepting a command which then prints the password on stdout. For example, I could then use `pass` (https://www.passwordstore.org/) with gpg-agent. Is there any risk associated with this usage pattern? What is the recommended practice in my case other than using `.pgpass`? Thanks in advance, P.S. Please CC me in replies, since I'm not subscribed to the list. Thanks. -- Marcin Borkowski https://mbork.pl https://crimsonelevendelightpetrichor.net/ ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: What are best practices wrt passwords? @ 2024-10-16 14:37 Alvaro Herrera <[email protected]> parent: [email protected] 2 siblings, 0 replies; 4+ messages in thread From: Alvaro Herrera @ 2024-10-16 14:37 UTC (permalink / raw) To: [email protected]; +Cc: pgsql-general On 2024-Oct-16, [email protected] wrote: > I understand why giving the password on the command line or in an > environment variable is a security risk (because of `ps`), but I do not > understand why `psql` doesn't have an option like `--password-command` > accepting a command which then prints the password on stdout. For > example, I could then use `pass` (https://www.passwordstore.org/) with > gpg-agent. We had a patch to add PGPASSCOMMAND once: https://www.postgresql.org/message-id/flat/CAE35ztOGZqgwae3mBA%3DL97pSg3kvin2xycQh%3Dir%3D5NiwCApiYQ... I don't remember the overall conclusions (other than the patch being rejected), but maybe you can give that a read. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-10-16 14:37 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-10-16 09:35 What are best practices wrt passwords? [email protected] 2024-10-16 12:41 ` Dominique Devienne <[email protected]> 2024-10-16 14:16 ` [email protected] 2024-10-16 14:37 ` Alvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox