Chris,
It appears I’ve done a poor job explaining the situation, so let me try again. We have multiple apps running on a production Tomcat server. Each one of those apps has one or more passwords that belong to the app developers. Generally we’re talking about DB passwords. If you’re willing to place your password in plain text in a file accessible via JNDI, your problem is solved. I’m not. I encrypt my password with my private key, then with the admin’s public key, then save it in a properties file for my app. When my app gets launched on Tomcat, it pulls that password from the properties file, and send it off to the decryption code. The decryption code decrypts the passed in string with the admin’s private key. Now it needs to know which public key to use to complete the decryption process. If the calling app gets to say “hey use this key”, then a malicious user can pull my encrypted key out of my properties file, and send it to the decryption code while saying “Hey, I’m Greg’s app”. Security fail. The decryption code doesn’t save any plain text passwords anywhere. It’s called with a string, it decrypts the string and returns the result. When I need to update my password, I encrypt the new password and save it in the properties file. No work for the admin, because my public key hasn’t changed. Does that make things clearer? On 2/12/16, 5:33 PM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >Gregory, > >On 2/12/16 4:49 PM, Dougherty, Gregory T., M.S. wrote: >> On 2/12/16, 3:29 PM, "Leo Donahue" <donahu...@gmail.com> wrote: >> >> >>> On Feb 12, 2016 3:19 PM, "Dougherty, Gregory T., M.S." < >>> dougherty.greg...@mayo.edu> wrote: >>>> >>>> On 2/12/16, 3:08 PM, "Leo Donahue" <donahu...@gmail.com> >>>> wrote: >>>> >>>> >>>>> On Feb 12, 2016 2:58 PM, "Dougherty, Gregory T., M.S." < >>>>> dougherty.greg...@mayo.edu> wrote: >>>>>> >>>>>> The web app needs a DB password so it can connect to the >>>>>> DB. >>>>> >>>>> I disagree that the web app needs a password. >>>> The web app has to be able to read and write to the DB. That >>>> takes a password. >>> >>> No, javax.sql.DataSource needs a password. Your web app just >>> needs a user name. >>> >>> Your custom data source will fetch a password. >> How? >> >> What, precisely, is the exact mechanism by which this custom >> DataSource will fetch the password? > >(I think Leo's bating you, here: he's trying to get you to admit that >this is a shell game where an encrypted password requires an encrypted >password requires an encrypted password, etc. all the way down. > >> And how is it that someone else, who has full access to all my >> source code, including to the source code of my custom DataSource, >> won¹t be able to retrieve the exact same password? >> >> Requirement for ³secure²: There are no files sitting anywhere on >> the server that have a plain text copy of my password. > >Is this because you don't trust your admins? > >> Requirement for secure: The sys admin does not get to know my >> password. He¹s ³trusted² in that we assume he won¹t abuse his >> private key on order to steal my password. He¹s not ³trusted² to >> know everyone¹s passwords. > >Forget about "other people's passwords" for a moment: you don't trust >your admins to peek at the super-secret database password (which is >usually something like "pr0duct!on" LOL)? > >If the admins wants the password, he (or she) is going to get it. Your >library needs the cleartext password at some point and at that point, >the admin effectively has it, too. > >(I had a conversation with Sander Temme at ApacheCon over a few beers >while he tried to explain how one of Thales's hardware key escrow >systems were capable of doing thins kind of thing. I had a hard time >understanding how it was possible. It could have been the beer.) > >> Requirement from system: password must be updated every six months. >> So I have to be able to change the password, and inform my web app >> of the changed password. > >Aah, yes. Password-rotation. That definitely keeps things secure. :( > >>> A. You don't get to manage your passwords. >>> >>> B. The suggestion I'm giving you requires coordination with sys >>> admins and DBA's. It is more than just a simple app trying find >>> a way to hide passwords, none of which will "ever" be in source >>> control. >>> >>> Leo >> >> A: I¹m the only one who knows my password, I have to manage it. I >> have to be able to use that password in contexts totally divorced >> from the web server. > >This is your LDAP password? Are we still taking about >application-level passwords for your database? Or user-level passwords >for ... what, exactly? > >> B: A solution that requires the sys admin to know, and update every >> six months, my passwords is not a viable solution. > >If the admin won't update the password, who will? > >- -chris >-----BEGIN PGP SIGNATURE----- >Comment: GPGTools - http://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iEYEARECAAYFAla+a+YACgkQ9CaO5/Lv0PBRowCfTJSdScNVitc5Bq79oY+JMoZZ >PAwAoJ+85CadSDhL/BKvDjwLoOM/thuP >=symF >-----END PGP SIGNATURE----- > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org >
