On Fri, Feb 12, 2016 at 5:46 PM, Dougherty, Gregory T., M.S. <
dougherty.greg...@mayo.edu> 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.
>
Not even encrypted files?
>
> Even if I did trust my administrators, they don’t want the task of having
> to update the passwords every six months.
>
Greaaat.
>
> >> 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?
>
What I was saying about the data source is that where you configure it in
Tomcat doesn't need a password in plain text, if your custom data source is
going to simply use the username from the Tomcat data source config file to
go look up the real encrypted password. You have to implement this
yourself. Precisely how is totally up to you.
You are going to need a process that writes encrypted user passwords to an
ENCRYPTED file, on a schedule, preferably every day. If you can't have
encrypted files, then you are stuck, don't read on.
You need to write something that generates long passwords, because you
don't need to remember them, and writes them to the encrypted file. All
you need to do is regenerate them whenever you want. If you are saying
that you need to choose your own password because it is used elsewhere,
then you are stuck again.
This same process is going to let you read and un-encrypt (spell check not
helping me here) said password. How you write this is up to you.
In your custom data source, where you override the
getConnection(username,password), you will obviously need to call the
function that fetches the real password for said supplied user. How you do
that is up to you, like I said, this is a bigger project than a quick hack.
<Context ...>
...
<Resource name="jdbc/YourJNDIName"
auth="Container"
type="javax.sql.DataSource"
username="dbusername"
password="this can be blank or null, because your custom
data source will handle it"
driverClassName="this is your custom data source class
which implements javax.sql.Datasource"
url="jdbc:Whatever"
maxActive="etc"
maxIdle="etc"/>
...
</Context>
https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html#JDBC_Data_Sources
https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html#getConnection-java.lang.String-java.lang.String-
>
> >> For that matter, how do I set up the data source (whose every
> >> element is checked into the source code control system that a
> >> malicious user may have access to) so that it knows the passwords
> >> of interest?
> >
> >Why would you check the data source configuration into the
> >revision-control system? It's not necessary to do that. Do you check
> >Tomcat's server.xml into revision control?
>
> Are you going to have your data source configuration sitting on only one
> user’s personal computer? What happens when that person is on vacation?
> Sick? Has a hard drive crash?
>
I don't understand why that would be the case that you store this data
source configuration on anyone's personal computer. Are you saying that
Mayo Clinic IT lets developers run production apps from Tomcats on their
personal computers?
>
> >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.
>
> >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.
>
> >
> >- -chris
> -Greg
>
>
