Chris,
On 2/15/16, 9:20 AM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Gregory, > >On 2/12/16 6:46 PM, Dougherty, Gregory T., M.S. wrote: >> Chris, >> >> >> On 2/12/16, 5:27 PM, "Christopher Schultz" >> <ch...@christopherschultz.net> wrote: >> >>> Gregory, >>> >>> On 2/12/16 4:19 PM, Dougherty, Gregory T., M.S. 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: >>>> My definition of ³secure² includes ³there exist no files with >>>> an unencrypted copy of the password². >>> >>> Do you mean "no files at all" or "no files in revision-control"? >>> Again, you have to decide whether you trust your administrators. >> >> No files at all. >> >> Even if I did trust my administrators, they don’t want the task of >> having to update the passwords every six months. >> >>>> How does the data source know that this web app, unlike every >>>> other web app in existence, is allowed to access the data >>>> source? >>> >>> The container allows you to map data sources to web applications. >>> Use that facility. And trust your administrators. >> >> This sounds like something I can use to uniquely identify which app >> is running, no? Can my code ask Tomcat for the DataSource the >> container assigns to the web app, that instead of returning a >> password, simply returns the name of the app? > >No, it will return a DataSource. What you do with it is up to you. >Generally-speaking, a DataSource already knows the password that will >be used to access the database. So the application doesn't need to >have any passwords at all. The only way I can envision the DataSource having the password is if it’s some way hard coded into it, which is the exact thing I’m trying to avoid. >>>If you free yourself from the idea that everything needs to be in >>> one big revision-control system, it makes things easier. >>> Everybody does their job: the devs write the software, the admins >>> deploy it. The admins have the keys to the kingdom (they always >>> do; don't fight it) and the devs have keys to nothing. >> >> I don’t get a vote on that one. > >So you are tasked with: > >(a) Removing all plaintext passwords from configuration files >(b) All configuration files must be in revision control >(c) Developers manage the passwords to the production dbs >(d) Admins must never see devs' passwords >(e) The system must actually work > >Do I have that all correct? Yes. > >>> Of course, the devs are writing the software, so if you are >>> truly paranoid, you need to make sure that the devs aren't >>> stealing secrets from the admins when the app runs ;) >> >> I am truly paranoid, that’s why I want an unambiguous way to figure >> out what app is running. That way the only data they can “steal” >> is their own data. > >Use separate VMs (or JVMs) for each application. No question >whatsoever which application is running. Not an available solution. However, I finally realized I do have a solution. 1: Call Decryptor.identifyMe (String whoIAm) 2: Code checks whoIAm. If a known Servlet, send that servlet a message consisting of a random integer. 3: Servlet calls Decryptor.decrypt (int token, String password) with the token and the password to decrypt 4: Decryptor.decrypt uses the token to prove what Sevlet it’s talking to, pulls up the correct public key, decodes the password, and returns it. Flaws? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
