On Feb 16, 2016 10:50 AM, "Dougherty, Gregory T., M.S." < dougherty.greg...@mayo.edu> wrote: > > On 2/16/16, 9:13 AM, "Christopher Schultz" <ch...@christopherschultz.net> > wrote: > > > >Gregory, > > > >On 2/15/16 11:18 AM, Dougherty, Gregory T., M.S. wrote: > >> How to trade information with a specified URL calling java code in > >> tomcat/lib: > >> > >> 1: Servlet calls Decryptor.start (String whoIAm, int validator, int xOr) > > > >What prevents the servlet from specifying whoIAm="someoneElse"? > > Absolutely nothing. That’s why the decrypt code does an HTTP get against > whoIAm, to validate that claim > > >> 2: Code calls Servlet http get with id=randomly generated int > > > >Which code calls Servlet HTTP? > > HttpURLConnection, called from within the decrypt code > > > > > >> 3: Servlet returns validator in response to the http get call. 0 is > >>not a > >> valid validator, it¹s what the Servlet returns if it doesn¹t have an > >> outstanding call to Decryptor.start > > > >But the whole point is that you don't trust the servlet, right? What is > >the servlet always returns the same value? Any servlet could impersonate > >any other one. > > I trust each servlet to act in its own best interest. > > An honest servlet will 1: Pass in real random numbers for validator and > xOr, 2: React correctly to this http get call. > An incompetently written or dishonest servlet can only give away its own > passwords by doing the wrong thing.
Give them away? Are you logging the passwords used? That’s their problem, not mine. > > >> 4: Having received the random number from the http get call, Servlet > >>xors > >> it with xOr, and calls Decryptor.decrypt (String whoIAm, String > >>password, > >> int xOred) > > > >So, the servlet makes the HTTP request and manages the checking? I > >really don't get it. > > Servlet (calles Decrypt.start): Sends whoIAm, validator, xOr > Code (calls http get on whoIAm): Sends cValid > Servlet (response to HTTP get): Sends validator (same as was send in call > to Decrypt.start). This validates whoIAm > Servlet (calls Decrypt.decode): Sends whoIAm, password (encrypted), xOred > (= xOr ^ cValid) > Code (return value from Decrypt.decode): password (decrypted) > > > > >> 5: Code checks xOred against whoIAm. If gets a match decrypts the > >> password and returns it from Decryptor.decrypt. > > > >After all that, it's okay for the servlet to be able to read its own > >database password? Why not just give the servlet access to a DataSource > >with the password already set inside it? > > Because it’s the Servlet’s password? How many times do I have to save > that before you’ll believe it? > > The data belongs to the servlet. The servlet is working with the > decryption code so that the data can be safely stored with the servlet. > > Every servlet trusts itself. None of them should be required to trust any > other servlet running on that instance of Tomcat. None of them should be > required to trust that data saved in the source control system won’t be > abused, if it can be abused. > > >>But so long as I can make the following two calls from my code: > >> > >> URL theURL = new URL (urlString); > >> HttpURLConnection uc = (HttpURLConnection) theURL.openConnection (); > >> > >> I think I¹m good. > >> > >> Flaws? > > > >Let's see: > > > > Constructed dubious use case? CHECK > Wrong. This use case is my current work situation. > > > Rolled your own security code? CHECK > > Used highly-secure XOR algorithm? CHECK > > Complicated enough to seem plausible? CHECK > > Confused objective leads to trivial attacks? CHECK > > > >I think you've got all the bases covered, here. > > > >I still don't understand what's being protected from whom, here. It > >looks like the code is very complicated in order to keep the password > >from the code, but then the code is given the password anyway. If you > >trust the code but not the admin, then why bother with the complex code? > > The problem, Chris, is that you don’t understand the situation, and rather > than try to understand the situation you’re spending all your time and > effort sniping at things you don’t understand. Let’s try one more time: > > If you led with the information below in your original post, it would have helped. > My servlet is running on a Tomcat instance that is hosting 5 other Servlets > > I completely and totally trust my servlet with my data. I do not in the > least bit trust any other servlet running on that Tomcat instance > > I am willing to trust a Jar file that I’ve written / reviewed, and the > administrators have added to tomcat/lib > > I have data that my servlet needs to use. I am not going to try to go to > a page on my servlet and personally type in that data every time it runs. > Therefore I’m going to have to save that data. I’m not going to save that > data somewhere on the server hosting the Tomcat instance, because I just > don’t’ trust the administrators that much. > > This means I have to save the data with my web app. Everything saved with > my app is available to a pool of people, large enough that I can not trust > that the data is secure. > > > This is the current situation. Neither you nor I get to change any of the > above parameters. Is anything about the above unclear (other than why > this is so)? > > When I say “I do not trust the Servlet calling the jar code” what I mean > is that I absolutely trust my own servlet when it’s calling the jar code, > but I do not trust any of the other servlets (and I’m sure they all feel > the same way about me). Any of the other Servlets could pretend they are > my servlet. This is why the jar needs to be tied to ldap accounts/roles. I know it is not in your ability to do this, but unless you do this or take Mark's advice about using a security manager, nothing else is going to get you what you need. Decryption code that lets them get away with that pretense is > worse than useless. > > Until a user has logged in, you don’t trust them. After the user has > logged in, you do. I need a way from my Servlet to “log in” to the > decryption code, but I can’t give it a useable password with which to log > in. Thus the need to validate that the servlet is the servlet it claims > to be. I suppose asking for your own Tomcat instance is out of the question? > > Greg
