Harri,
On 1/20/22 11:37, Harri Pesonen wrote:
Vault for Apache Tomcat:
https://github.com/web-servers/tomcat-vault
It hides the secrets in another encrypted file, and password for that
file is then in another file... So it just makes it more difficult to
access the secrets, but at least they are not in plain text.
What this does is satisfy the following "security" requirement:
[ ] Have you ensured that no credentials are stored unencrypted in
Tomcat's conf/server.xml file?
[X] Check!
Nice job. It doesn't answer the question "do you have plaintext
credentials in any configuration files" because whatever auditor is
asking would give you a bad grade.
As soon as that auditor learns about Vault for Apache Tomcat, they will ask:
[ ] Have you ensured that no credentials are stored unencrypted in
Tomcat's conf/server.xml file?
[ ] Have you ensured that no credentials are stored unencrypted in Vault
for Tomcat's vault-config.xml file?
Then we'll get questions about whether there is a Vault for Vault for
Apache Tomcat.
Someone should patch VfAT so it has a new feature which is the number of
configuration files it should use for encryption. So you can set it to
e.g. "4" and then you get these files:
vault-config.xml
vault-config-1.xml
vault-config-2.xml
vault-config-3.xml
And the -3 file contains the plaintext password used to unlock -2 which
unlocks -1 which unlocks vault-config.xml. Hey, three layers of
encryption! Super secure!
-chris
-----Original Message-----
From: Orendt, John <john.p.ore...@medtronic.com.INVALID>
Sent: torstai 20. tammikuuta 2022 18.11
To: users@tomcat.apache.org
Subject: RE: Tomcat 9 Encrpytion of JDBC
[Et saa yleensä sähköpostia osoitteesta john.p.ore...@medtronic.com.invalid.
Lue lisää siitä, miksi tämä on tärkeää, osoitteesta
http://aka.ms/LearnAboutSenderIdentification.]
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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
efense.com%2Fv3%2F__https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisp
la&data=04%7C01%7Charri.pesonen%40sinch.com%7C318adb49672e4fe13aa1
08d9dc2f9971%7C3b518aae89214a7b8497619d756ce20e%7C0%7C0%7C637782919266
275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mMjmECMDtbO%2Fa5ovQgdahIl
aq%2FZdVBEnzoRAyy7oYQA%3D&reserved=0
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:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Femail
disclaimer.medtronic.com%2F&data=04%7C01%7Charri.pesonen%40sinch.c
om%7C318adb49672e4fe13aa108d9dc2f9971%7C3b518aae89214a7b8497619d756ce2
0e%7C0%7C0%7C637782919266275465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=
%2Fcv%2B6vRuz8ox1ipRnMTOWZxpz2%2BBKJ%2BHlfBh8iDg5m4%3D&reserved=0
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
