-----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
