Hi There are at least two types of mutual authentication.
1. Device Client A and Server B 2. Human A via browser and Server B All the scenarios you mention have been solved. You just need to know how. X509 certs, the chain of trust, TPMs and HSMs are some the of parts of the solution for both types. Internet Banking does exist. John Orendt john.p.ore...@medtronic.com -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Tuesday, January 18, 2022 11:32 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9 Encrpytion of JDBC 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 <shiva...@hotmail.com> > Sent: Friday, January 14, 2022 2:05 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: RE: Tomcat 9 Encrpytion of JDBC > > OK thanks Bill! > > -----Original Message----- > From: Bill Stewart <bstew...@iname.com> > Sent: 14 January 2022 19:02 > To: Tomcat Users List <users@tomcat.apache.org> > 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/displa > y/TOMCAT/Password__;!!NFcUtLLUcw!Bhr3E8c3AZFikCj4AHarnHl2emUxh99SUwhyn > Fa-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
