On Wednesday, October 24, 2012 5:41:06 AM UTC-4, Flying-w wrote: > I am investigating security considerations around the user login for a GWT > application in respect of the following strategy: > > - User enters their id and password in a dialogue; > - Client transmits the login request with the above details to the > server using RPC; > - Server returns a token unique to the client. The client stores this > in a cookie such that if they press F5 to reload the application, or > navigate away and come back, they do not need to login again (within a > timeout period); > - On every request the client sends to the server, the token is > included in the payload of the request to authenticate the request; > > This sounds awfully similar to a session cookie - any reason why you can't just use that? If you want to persist identity across browser sessions, then you'd need a separate cookie, but that would generate additional security concerns.
> > - Use SSL. Any good guides about doing this with GWT? Does SSL also > defeat the "Mallory" attacker that can also modify network data? > > Yes, use SSL/TLS. Configuration of SSL is primarily a hosting concern and doesn't really affect GWT per se, though there are some settings that you may want to specify in the server-side configuration (e.g. only transmit cookies over SSL). If you're using SSL, the "Mallory"-style attacks require user intervention (i.e. accepting an untrusted SSL certificate), so you are somewhat "safe" in that regard. > > - Any non-SSL solutions? > > You could always write your own application-level encryption scheme, but this is likely to be much slower. Since you're already using HTTP, you might as well take advantage of the existing SSL facilities. On Wednesday, October 24, 2012 2:38:51 PM UTC-4, Manuel Carrasco wrote: > > - You could compute and send the MD5 hash of the password instead of the > clear one if the server is storing the password in MD5 > This doesn't really work against MITM attacks. As written, the proposal substitutes a password equivalent in place of the original password, which doesn't really provide any protection against unauthorized access to the system because intercepting the password equivalent would still be sufficient for access. It does protect the original password, though that's typically a lesser concern. -Abraham -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/wGJyLkMhP8EJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
