-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leo,
On 2/12/16 8:35 PM, Leo Donahue wrote: > 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. Yeah, this is a dumb requirement. Application-level passwords should never have to change. User passwords? Fine, if you have some silly requirement that they be changed ("okay, FINE! password-zero-ONE!"), make users change their own passwords. But don't make administrators change db-access passwords. Lock-down access to the database and don't have anything change. >>>> 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. Gregory, here's where you can use your crazy private-public-encryption thing work. You can have your code unlock the password during startup and then the application will get an unlocked DataSource and never has to deal with passwords at all. > 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. I think he's comfortable with a non-plaintext password written to a file. So, if you had a DataSource configuration that looked like this, for instance: <Resource ... password="adb6ab9876b6a78da987b6d67a8bda8976bd67a8bd89a76b6d789ad" where the value of the "password" field was actually this multiply-encrypted thing he's been talking about. Where to store those private and public keys, though? Sounds like it's gotta to into revision-control, and that means the encrypted values are also not safe. But, anyway... > 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. A synchronization process is possible. You could inject the new password via JMX, for example. (At least, I think you can.) The worst part is that, evidently, the admins are going to have to change the passwords at the database-level, but they aren't allowed to know the passwords. So I don't know how that's gonna work. > 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#JDB C_Data_Sources > > https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html#getC onnection-java.lang.String-java.lang.String- I think maybe something confusing to me has been whose users passwords are we talking about, here? I've been assuming that we are talking about an application-level user for an entire application. So, if you are running "myapp", then the username is always "myappdbuser" and the password is always "myappdbpassword" (or whatever). Usually, applications always use the same credentials to access a database like this; it's not always necessary to support multiple usernames and passwords, like for example calling DataSource.getConnection(username, password). Instead, it's just DataSource.getConnection(). If it's always the same credentials, then the application never needs to have access to them at all. If the application doesn't need access, then the admin gets to make-up the passwords to production, and the devs get to make up the passwords for dev environments. Nobody needs to share anything. Nothing needs to go into revision-control. If the application never sees passwords, the application can't steal anything, and this whole endeavor is a waste of time. So am I really just missing the point? - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbB8GkACgkQ9CaO5/Lv0PAVfQCfVfN1gjAuP2RLAUklT14P0VKe UZ0An3WsMK8KMGvaxrD4KMxOeNdB6pNv =z/qI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org