public inbox for [email protected]  
help / color / mirror / Atom feed
Re: password rules
2+ messages / 2 participants
[nested] [flat]

* Re: password rules
@ 2025-06-28 16:06 raphi <[email protected]>
  2025-06-29 13:32 ` Re: password rules Peter J. Holzer <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: raphi @ 2025-06-28 16:06 UTC (permalink / raw)
  To: [email protected]



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








^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: password rules
  2025-06-28 16:06 Re: password rules raphi <[email protected]>
@ 2025-06-29 13:32 ` Peter J. Holzer <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Peter J. Holzer @ 2025-06-29 13:32 UTC (permalink / raw)
  To: [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

^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2025-06-29 13:32 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-06-28 16:06 Re: password rules raphi <[email protected]>
2025-06-29 13:32 ` Peter J. Holzer <[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