You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alan F <sh...@hotmail.com> on 2022/01/14 17:25:26 UTC
Tomcat 9 Encrpytion of JDBC
All,
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.
Thanks
Ken
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 9 Encrpytion of JDBC
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <sh...@hotmail.com>
>> Sent: Friday, January 14, 2022 2:05 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: RE: Tomcat 9 Encrpytion of JDBC
>>
>> OK thanks Bill!
>>
>> -----Original Message-----
>> From: Bill Stewart <bs...@iname.com>
>> Sent: 14 January 2022 19:02
>> To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 9 Encrpytion of JDBC
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Jan 20, 2022 at 6:30 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> 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!
So I guess this means you're still not interested in that awesome
potential contribution we could make to Tomcat :D
Rémy
Rémy
>
> -chris
>
> > -----Original Message-----
> > From: Orendt, John <jo...@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.orendt@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.orendt@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 <sh...@hotmail.com>
> >> Sent: Friday, January 14, 2022 2:05 PM
> >> To: Tomcat Users List <us...@tomcat.apache.org>
> >> Subject: RE: Tomcat 9 Encrpytion of JDBC
> >>
> >> OK thanks Bill!
> >>
> >> -----Original Message-----
> >> From: Bill Stewart <bs...@iname.com>
> >> Sent: 14 January 2022 19:02
> >> To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 9 Encrpytion of JDBC
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <jo...@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.orendt@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.orendt@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 <sh...@hotmail.com>
>> Sent: Friday, January 14, 2022 2:05 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: RE: Tomcat 9 Encrpytion of JDBC
>>
>> OK thanks Bill!
>>
>> -----Original Message-----
>> From: Bill Stewart <bs...@iname.com>
>> Sent: 14 January 2022 19:02
>> To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 9 Encrpytion of JDBC
Posted by Harri Pesonen <ha...@sinch.com>.
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.
-Harri
-----Original Message-----
From: Orendt, John <jo...@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.orendt@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.orendt@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 <sh...@hotmail.com>
> Sent: Friday, January 14, 2022 2:05 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: Tomcat 9 Encrpytion of JDBC
>
> OK thanks Bill!
>
> -----Original Message-----
> From: Bill Stewart <bs...@iname.com>
> Sent: 14 January 2022 19:02
> To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 9 Encrpytion of JDBC
Posted by "Orendt, John" <jo...@medtronic.com.INVALID>.
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.orendt@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 <sh...@hotmail.com>
> Sent: Friday, January 14, 2022 2:05 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: Tomcat 9 Encrpytion of JDBC
>
> OK thanks Bill!
>
> -----Original Message-----
> From: Bill Stewart <bs...@iname.com>
> Sent: 14 January 2022 19:02
> To: Tomcat Users List <us...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 9 Encrpytion of JDBC
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <sh...@hotmail.com>
> Sent: Friday, January 14, 2022 2:05 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: Tomcat 9 Encrpytion of JDBC
>
> OK thanks Bill!
>
> -----Original Message-----
> From: Bill Stewart <bs...@iname.com>
> Sent: 14 January 2022 19:02
> To: Tomcat Users List <us...@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/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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 9 Encrpytion of JDBC
Posted by "Orendt, John" <jo...@medtronic.com.INVALID>.
Hi All
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.
John Orendt
John.p.orendt@medtronic.com
-----Original Message-----
From: Alan F <sh...@hotmail.com>
Sent: Friday, January 14, 2022 2:05 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: RE: Tomcat 9 Encrpytion of JDBC
OK thanks Bill!
-----Original Message-----
From: Bill Stewart <bs...@iname.com>
Sent: 14 January 2022 19:02
To: Tomcat Users List <us...@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/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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 9 Encrpytion of JDBC
Posted by Alan F <sh...@hotmail.com>.
OK thanks Bill!
-----Original Message-----
From: Bill Stewart <bs...@iname.com>
Sent: 14 January 2022 19:02
To: Tomcat Users List <us...@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://cwiki.apache.org/confluence/display/TOMCAT/Password
Bill
Re: Tomcat 9 Encrpytion of JDBC
Posted by Bill Stewart <bs...@iname.com>.
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://cwiki.apache.org/confluence/display/TOMCAT/Password
Bill