John,
On 1/20/22 11:10, Orendt, John wrote:
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.
Okay, let's take X.509 certs as an example.
Your server needs to sign messages sent to the client to provide
authentication (to the client). For that you need the key, unencrypted.
So how do you unlock the key without having the password around?
Let's take TPM as another example: the key is in the TPM and it's
(somewhat) tamper-proof and you can't extract it.
Some software on the machine where the TPM is located asks the TPM to
sign or decrypt something using the key. But how does the software
authenticate to the TPM? (Hint: it doesn't). The trust is established by
simple physical connection.
So, let's get back to encrypting your JDBC password in your
conf/server.xml file. If you encrypt that, you have to put the
encryption key elsewhere. Fine, you say, I'll use a "remote key-service"
where I supply an encrypted secret to the service and it returns the
unencrypted password I can then use to connect to my JDBC server. Well,
how do you authenticate to the key-service? Is it another physical
presence thing? IP allow-listing? Whatever it is, it's almost exactly as
secure as having the password right there in the file on the machine
without all the hand-waving and complexity.
"Oh, but if the server is stolen or data is exfiltrated then OMG what do
we do?" Well, first of all, you don't allow connections to your database
from random strangers: that password is only useful when used locally.
So the "secret" of the password getting out isn't really a problem.
Fine, rotating the password would be a good idea, but the password
should be useless without that other security control: presence in a
(relatively) trusted position.
Internet Banking does exist.
Yep, and I've never had anyone from the banking industry tell me how
they protect their TLS keys in some super-secure way that uses TPMs,
HSMs, and X.509 certifictes. Maybe it's a closely-guarded secret that
they aren't allowed to tell anybody.
If you think you have an idea that meaningfully improves security and
ALSO does not rely on hand-waving to simply move the problem somewhere
else, I'd love to hear it.
-chris
-----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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
