public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter J. Holzer <[email protected]>
To: [email protected]
Subject: Re: password rules
Date: Sun, 29 Jun 2025 15:32:10 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On 2025-06-28 18:06:51 +0200, raphi wrote:
> 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
Yeah, my aim would be to eliminate that "somebody" and automate it with
an ansible playbook (or whatever).
> 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.
If it's automated the DBA wouldn't know the password. The playbook would
generate a random password, create the user in the database and create
an XML file for Tomcat[1] with the connection details (including the
password). It seems to me that this would be a relatively simple change
to your existing "database self service" mechanism.
> 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.
That's another possibility. Might be a bit more complex, but I've never
used it so I don't really know.
hjp
[1] There are probably different methods, but wherever I see Java, I
also see XML ;-)
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: password rules
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox