Chirs,

On 2/12/16, 5:19 PM, "Christopher Schultz" <ch...@christopherschultz.net>
wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Gregory,
>
>On 2/12/16 3:35 PM, Dougherty, Gregory T., M.S. wrote:
>> You are correct, I¹m trying to authorize the web app, not the
>> user.
>> 
>> Goal: I am trying to come up with a way for a Tomcat app to
>> securely store and retrieve the password it needs to access a DB.
>
>Is it Tomcat that needs access to the password, or the library?
Sorry, for a web app running on Tomcat.

>> My definition of ³secure² includes ³there exist no files with an
>> unencrypted copy of the password².  IIUC, JNDI fails this test.
>> 
>> My requirements include that all web app components are checked in
>> to a source control system that malicious users can have read
>> access to.
>> 
>> Solution: 1: Trusted user creates public:private key pair (1),
>> distributes public key 2: Web app developer creates pubic:private
>> key pair (2), distributes public key 3: Web app developer encrypted
>> password with private key 2, then public key 1, stores with web
>> app 4: Web app calls decryption jar that¹s in tomcat/lib, passing
>> in the encrypted password from step 3 5: Decryption code determines
>> which app called it, pulls the public key (3) saved for that app 6:
>> Decryption code decrypts with private key 1, public key 3, and
>> returns the unencrypted password.
>
>Sounds crazy:
>
>(a) You have web developers managing passwords, keys, etc. Don't trust
>those fools! They are the ones writing those untrustworthy applications!

It’s their password I’m trusting them with.  What I don’t trust them with
is anyone else’s password.  The encrypted passwords are saved in source
code control with the web app.  Many people can read that.  Therefore the
challenge is to make sure that many people can read the encrypted
password, but only the right app can decrypt it.

>(b) You never said that any private key is stored with the web
>application (or library). How does that all work?

Probably have the Sys admin upload it to the decryption code after Tomcat
is started up.

>(c) You have two layers of encryption where only one is necessary:
>have someone (not one of the devs) encrypt the true password with a
>public key, and have only the library (or whatever) have access to the
>private key. Don't distribute the private key with the library. Only
>deploy the private key onto a server where the library will be used
>for production. That second layer does nothing unless I misunderstand
>what's going on.

You misunderstand what’s going on.
The the web app developers are the only ones who know their passwords.  If
they only encrypt it with the secure public key, then anyone else can take
that encrypted password, use it in their app, and get the unencrypted
password back.

>> So long as 1: Trusted user can store private key where it¹s secure,
>> but accessible to decryption code, and 2: Can correctly determine
>> the calling app, I believe this setup is secure.
>> 
>> We log who uploads the web apps, so if user X uploads a bogus ³User
>> Y App², we can deal with that.
>
>You can use JNDI in a way that is secure from the web application
>(within reason). You can't make it secure from the administrator, though
>.
>
>Do you trust your administrators in this scenario?

I don’t trust anyone enough to give them a plain text copy of my
passwords, no.

>- -chris
>-----BEGIN PGP SIGNATURE-----
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iEYEARECAAYFAla+aGoACgkQ9CaO5/Lv0PBqIgCgtd0iynz/vgSdjy6mEgd9q6W5
>it8AoI96Xn6dIYKrvz71fhY/WKpJHWAz
>=DlEh
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

Reply via email to