Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uVY5A-001tRr-Di for pgsql-general@arkaria.postgresql.org; Sat, 28 Jun 2025 16:07:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uVY57-008V2Y-Ey for pgsql-general@arkaria.postgresql.org; Sat, 28 Jun 2025 16:07:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uVY57-008V2P-49 for pgsql-general@lists.postgresql.org; Sat, 28 Jun 2025 16:07:09 +0000 Received: from mx126.mail.hosttech.eu ([82.220.38.13] helo=126.hosttech.eu) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1uVY55-004ScB-0K for pgsql-general@lists.postgresql.org; Sat, 28 Jun 2025 16:07:08 +0000 X-Spam-Status: No X-hosttech-MailScanner-From: raphi@crashdump.ch X-hosttech-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-hosttech-MailScanner: Found to be clean X-hosttech-MailScanner-ID: 365E0375400E.A33AA X-hosttech-MailScanner-Information: Please contact the ISP for more information Received: from [192.168.1.205] (31-10-141-228.cgn.dynamic.upc.ch [31.10.141.228]) by 126.hosttech.eu (Postfix) with ESMTPSA id 365E0375400E for ; Sat, 28 Jun 2025 18:06:51 +0200 (CEST) Message-ID: Date: Sat, 28 Jun 2025 18:06:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: password rules To: pgsql-general@lists.postgresql.org References: <65b65e9f-b4b0-4927-b872-d24dff11449b@crashdump.ch> <20250625115535.bd3lmsslyd36qsha@hjp.at> <7b27e37f-f775-4952-96f6-2604ee8259b9@crashdump.ch> <20250625153305.hmbzbpq5nadwvczo@hjp.at> <0344a9b2-bb6b-4d09-af54-2acb10b6a51a@crashdump.ch> <20250626122741.wkemjudz3lagw6zn@hjp.at> <31fd386e-8cff-4573-8cc7-f4e64c59dc85@crashdump.ch> <20250628135923.v2hrctnfjpqlcnqs@hjp.at> X-hosttech-server: 126.hosttech.eu From: raphi In-Reply-To: <20250628135923.v2hrctnfjpqlcnqs@hjp.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Am 28.06.2025 um 15:59 schrieb Peter J. Holzer: > On 2025-06-27 19:00:36 +0200, raphi wrote: > >> It's the application's password that we want to ensure that it is >> complex and gets changed after we set an initial password for it. > Why let a human change that at all? Couldn't you just create a suitable > random password at deployment time? (And then automatically every n > months if you want to rotate it.) > Because someone has to configure the password in the application, mostly within WLS or Tomcat and that's definitely not something that we DBA want to touch, that's the devs job. Which means we would have to provide some mechanism for the application to grab the password, say from a file or something, which has it's own pitfalls. Not to mention that we DBA usually don't want to know any application passwords. The only feasable way to implement this is with hashicorp Vault or something similar, then no one knows the password, neither DBA nor Dev and it would be guaranteed that it's complex. And application maintenance by a dev directly in the DB could then be made with personal logins via LDAP and switching to the application role as you so splendidly described ;) Same would be true for SSL certificates, only the application would need it and the devs could login via LDAP. have fun raphi