John,
On 1/18/22 08:37, Orendt, John wrote:
Secrets are more secure with the use of a Trusted Platform Module
(TPM) and / or a Hardware Security Module (HSM).
Secrets need to be protected both at rest and in transit.
Sure. Where you put the password for the TPM or HSM? Or do you enter the
password for your HSM/TPM every time you start a process that needs
access to secrets? How do you handle unattended restarts?
How do you handle massive deployments? Do you manually-enter a password
on 1000 servers as they all launch together?
On all these kinds of deployments, you usually use a key server. But
then how do you authenticate to the key server? With another secret.
It's secrets all the way down. At some point, you must trust something,
and that something you trust can't be a human, because that doesn't
scale or isn't practical for some other reason.
I'd love to hear a practical solution to the "secret at rest" problem
that actually makes some sense and doesn't just hand-wave the problem
off to another component that is Somebody Else's Problem.
-chris
-Original Message-
From: Alan F
Sent: Friday, January 14, 2022 2:05 PM
To: Tomcat Users List
Subject: RE: Tomcat 9 Encrpytion of JDBC
OK thanks Bill!
-Original Message-
From: Bill Stewart
Sent: 14 January 2022 19:02
To: Tomcat Users List
Subject: Re: Tomcat 9 Encrpytion of JDBC
On Fri, Jan 14, 2022 at 10:25 AM Alan F wrote:
Interested to know your best practices on securing jdbc plain text
passwords, in my last place they used a mechanism to encrypt all passwords.
Is this the best method as I read some people don't recommend this.
Any details or procs on best practice appreciated.
The "best practice," generally speaking, is that doing so is basically
pointless from a security perspective.
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhynFa-FKWZahvlpv0TmiVo5DveVMgMyg3NbQ$
Bill
[CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is
proprietary to Medtronic and is intended for use only by the individual or
entity to which it is addressed, and may contain information that is private,
privileged, confidential or exempt from disclosure under applicable law. If you
are not the intended recipient or it appears that this mail has been forwarded
to you without proper authority, you are notified that any use or dissemination
of this information in any manner is strictly prohibited. In such cases, please
delete this mail from your records. To view this notice in other languages you
can either select the following link or manually copy and paste the link into
the address bar of a web browser: http://emaildisclaimer.medtronic.com
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
