-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Martin,
On 2/24/17 12:32 PM, Martin Knoblauch wrote: > On Fri, Feb 24, 2017 at 6:06 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Martin, >> >> On 2/22/17 5:19 AM, Martin Knoblauch wrote: >>> On Tue, Feb 21, 2017 at 8:55 PM, Mark Thomas >>> <ma...@apache.org> wrote: >>> >>>> On 21/02/2017 13:31, Martin Knoblauch wrote: >>>>> Hi, >>>>> >>>>> is there a way to find the absolute path of the >>>>> application root before the servlet is initialized? >>>>> >>>>> Alternatively: is there a way to defer the initialization >>>>> of a datasource until the servlet is initialized? >>>>> >>>>> Background: I have extended "org.apache.tomcat.jdbc.pool. >>>> DataSourceFactory" >>>>> to automatically set credentials so that they are not >>>>> stored in the "Catalina/localhost/XXX.xml" file. Instead >>>>> they are taken from encrypted values in a file below the >>>>> application root. Works fine if I know that >>>> path >>>>> at "createDataSource" time. >>>> >>>> And the decryption key for that file is stored where? >>>> >>>> https://wiki.apache.org/tomcat/FAQ/Password >>>> >>>> >>> Thanks for link. It clearly reflects my opinion as well >> >> Good. At least you know this is all a farce. >> > > Not sure I'd call it a farce, but yes this is all hide and seek > > >> >>> , but the customer demand is: >>> >>> - no plain-text credentials (Big multinational company >>> security policies - fight them if you need the fun). And yes, >>> this is all about making auditors happy >> >> Obviously, you are still failing this requirement. The only >> requirement you are satisfying is "no plain-text credentials in >> a standard configuration file". What you are doing is moving the >> plain-text credentials into a non-standard configuration file. >> >> > No, there are no plain-text credentials stored anywhere. They are > stored crypted with an api to decrypt them. ... and the keys passed-into the API. > But of course > > - how good is the decryption key protected It must be plain-text somewhere. You can obscure it all you want, but you are just buying yourself a small amount of time. > - what about the in-memory copy of the credentials once the > datasource has been initialized They are always available, since the connection-pool manager may have to open a new connection at any moment. > - what about snooping them on the network when the DB connection is > built. OK. We are using SSL there. TLS should do your job, here. Of course, nobody needs your credentials if they can sniff the network traffic. So TLS is important to ensure. I would even require it as a condition of all non-local connections. > This makes most auditors and penetration testers sufficiently > happy. > > >>> - minimize the locations where credentials are stored. This is >>> only lightly related to the decrypt issue. Having to store >>> identical stuff in more than one place is opening up all other >>> sorts of practical issues >> >> This is a reasonable requirement, as it helps reduce the attack >> surface. But when the attack surface is "a file on the disk", >> getting owned means you are owned, regardless of the location of >> the file(s). >> >> As for the location of the secrets file, would it be possible to >> store it *outside* of the web application's on-disk footprint? >> That will in fact make you more secure. Let's say for example >> that a vulnerability exists in the DefaultServlet, or one of your >> application's own servlets. It allows path-traversal or whatever. >> A file living in your application will then be potentially >> remotely-fetchable :( If you move that file outside of the web >> application, you have a better change of preventing that kind of >> thing. > > There is no secrets file. As I said before - the app has obfuscated > the key deep in the source... So the secrets file is called MySecrets.class :) - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYsK2qAAoJEBzwKT+lPKRYQbEP/RamJmHnm+G3Pz4hCprsGrqA n6xCcdCyU2jMqHpIdnhVHNLoMAYmeRDHpetn4GTWLff3TNjcljRfEdmPggQOy4Ei bE7sq/1A79TS/Y+Xo2/QuYdMFHm0F0nAuyMsVdJ/XzoMuQtNlWjq3SlZQcYzkzGC aofnpd7FjtePrCyBeSQfyAZ+lep8Tjvsg0tzH03eUMsgM6RJ5E0jcloBbqm7hsVP oo6oS4cwts/Vq+PnNbmTiQaQA/wQWEvZRLQctflyeRYjvcLr5/ABJ1iBJc6tdTXA zY8qd8Zx2DMOdsSvVLSdjATm1YvT+ucQl5O1TJ6AXJKRa+f76eM17kr7fafOyG4U IeQgCwS9/q0UB4HH14bvsb9jhSXup3j5aNHMGgI6xyZtbaRoI8jrwQvGd/KNXDjQ jXtr7xBBWFTxE6r3bk5afJvHC+A3n0KlBySoQ4S0Wg6B37QFW+ThU4sTpOKrH/Bs NiM0r+qEDXA255O3LuvYJJUYPBGSL0AD7UaV14LWiFN9iPgWZyB633JW8Ngnm5ZO 9Ogp0udT4zjuZc2Q20MNuheR9LFKDcji0K92STGbhhHhsk/TBJBrijq2ApIAkeSH CDU5jIVfzjwd5vVXzlGc44s2vIbMxaok6grbEl5fWvthqlO3kYfgozHS1k43qvFb hPiAqnZv9E+e/fBqME4u =uY5I -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
