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. 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: 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. 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. Greg
