-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory,
On 2/12/16 7:03 PM, Dougherty, Gregory T., M.S. wrote: > It appears I’ve done a poor job explaining the situation, so let me > try again. > > We have multiple apps running on a production Tomcat server. Each > one of those apps has one or more passwords that belong to the app > developers. Generally we’re talking about DB passwords. > > If you’re willing to place your password in plain text in a file > accessible via JNDI, your problem is solved. I’m not. I do get it. I'm just not sure (a) why you are so concerned about plaintext passwords and (b) how you think you can actually secure such a system. > I encrypt my password with my private key, then with the admin’s > public key, then save it in a properties file for my app. When my > app gets launched on Tomcat, it pulls that password from the > properties file, and send it off to the decryption code. Encrypting your own password with your private key is next to useless. By definition, the decryption key for the thing you just created (your encrypted password) is publicly-known. Therefore everyone in the world can decrypt that password. The only think you can gain by encrypting your own password with your private key is authentication: the decryption code can determine that you are the one who injected that key into the keystore. > The decryption code decrypts the passed in string with the admin’s > private key. Now it needs to know which public key to use to > complete the decryption process. If the calling app gets to say > “hey use this key”, then a malicious user can pull my encrypted key > out of my properties file, and send it to the decryption code while > saying “Hey, I’m Greg’s app”. Security fail. Is the admin's private key publicly-available? I would suspect so, since you said that everything is checked-into source-control. If the admin's private key is in fact public (source control = public, by your definition), then everything an attacker needs to know (your public key, admin's private key) is public. *There's* your "security fail". Why? because you went through all that trouble to convince yourself you were safe, and you actually aren't. It's /worse/ than the plaintext scenario. > The decryption code doesn’t save any plain text passwords anywhere. > It’s called with a string, it decrypts the string and returns the > result. > > When I need to update my password, I encrypt the new password and > save it in the properties file. No work for the admin, because my > public key hasn’t changed. > > Does that make things clearer? It does. It just doesn't make them secure in any way that I can see. Contratulations: you have succeeded in removing plaintext passwords from your files. But you did it in a very convoluted way that adds no more security than using XOR or ROT13 on the password values. If you want no cleartext passwords in configuration files, then why not use password-less logins? It achieves the same level of security with a lot less effort. Remember, hiding the passwords from the admins is useless: they have admin access to the db, so the only thing you are protecting is the password itself, not the data it protects. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbB618ACgkQ9CaO5/Lv0PD2ogCfVjKw2jjzegwgdnS9oyoHp4Gi MPMAnRez/yeEe8xY7X8iqgConHGRuGM9 =MN6X -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
