Intro note: If this post sounds condescending because it rehashes a lot of what has been said and mostly presumes the reader is clueless on the topic, I apologize. That is not my intent at all; I'm merely trying to be extremely clear because, with security, you don't get a bug report during test, you get a mob of angry users a few months into deployment. My thanks for indulging me.
The problem with hashing on the client is that you need to include a hash library on the client. This is non-trivial and pumps up the download size. This is especially important if you ARE using SSL, due to wonky caching behaviours. Sidenote: The reason a lot of websites jump through hoops to weave in and out of SSL instead of just going SSL whole hog isn't, usually, CPU concerns. It's the asinine crap the browsers shove in your face when in SSL mode in a backward attempt to protect the world from idiot web server maintainers. But I digress. The main goal of hashing, after all, is not so much wire security, but not leaking a big batch of passwords if you decide to copy the production db to your notebook for some on-the-road debugging and someone nicks it. See reddit.com founders for a few induhviduals who screwed that up. Assuming for a moment the web app isn't SSL: If people were perfect security conscious users, they'd pick a different password for all services and the difference between sending the password over the wire or the hash is entirely moot; either will grant you access to the webapp in question and no others. The point, of course, is that people aren't that perfect (and it isn't fair to blame them for this) and tend to re-use passwords, and by hashing on the client, you sidestep this problem entirely; knowing the hash of a user for webapp A allows you to log in as that user for webapp A. It gives you bupkis for webapps B, C, all the way through Z, even if the user used the same password on every single one of those. This is all presuming you use BCrypt and you aren't a foolhardy moron who decides to roll his own hash/salt scheme and does it wrong. I'm still not aware of a BCrypt implementation that is halfway workable (remember, BCrypt is explicitly designed to be slow as molasses) on the client. The LoginSecurityFAQ was written to be practical. I did not at the time consider client side hashing (or http digest) practical. If there is one for JS, it should probably be wrapped into a nice GWT library of sorts. Also, remember, there are tons of webservices out there that don't use SSL for login, and reuse a password at any one of those, and you've compromised all your webapps that use that password. Remember, the vast majority of line sniffing occurs very close to the source (open WiFi, internet cafe router). Log in to your GWT app, google mail (not over https), and let's say some online game, and the client side hashing, or lack thereof, of the GWT app is utterly moot: The game or gmail already gave away the keys to the kingdom, and in the process allows the sniffer to log into the GWT app as well. It would be nice if GWT apps set a better example for this world and did it right (e.g. by hashing on the client), but the odds that this complicated act actually translates to tangible security benefits is, as far as I can tell, really quite small. That doesn't make it a bad idea; on the contrary, you should always endeavour to go the extra mile for security, because the status quo tends to be badly borked. However, client side hashing isn't cheap or easy. I don't think its justified to do it in this case. By all means, prove me otherwise, and I'll update the FAQ. Incidentally, I think anyone with incubator commit access can fiddle with that FAQ, and feel free to, though I would prefer it if the practical spirit of the document remains intact. On Sep 17, 6:45 pm, hezjing <[EMAIL PROTECTED]> wrote: > Hi > When reading this > LoginSecurityFAQ<http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecur...> > > String password = /*(get password from incoming JSON or GWT-RPC > request)*/; > String hashFromDB = /*(obtain hash from user's db entry)*/; > boolean valid = BCrypt.checkpw(password, hashFromDB); > if ( valid ) generateSessionIDAndSendItBackToClient(); > else sendErrorToClient("Wrong Username or Password."); > > The article explained that the password is retrieved from the incoming JSON > or GWT-RPC. > If I read this correctly, this means the password is sent over the wire (and > not secured)? > > On Wed, Aug 20, 2008 at 11:25 PM, walden <[EMAIL PROTECTED]>wrote: > > > > > > > Hi cresteb, > > > When contemplating security for a network application, you have to ask > > yourself how secure is secure enough. Security on the web is like the > > locks on your doors: there is no sure way to prevent all attacks; you > > can only lower the value to potential attackers by making the attack > > harder to achieve. > > > A couple of notes on your writeup (independently numbered): > > > 1. For registration, I would never send a password over the wire, only > > its hash. If your entire interaction is going to be over SSL, ignore > > that, because it's a given. > > > 2. HTTP Digest Authentication, which was by no means maturely > > implemented eight years ago, is a different story today. It > > alleviates most concerns by never sending identifying information in > > clear text and by changing salt (or whatever they call it) to make Man > > In Middle and other attacks harder. In my view, most of the gyrations > > developers go through today with http<-->https switching and sessions > > and session cookie duplication, and so on and so on, are a poor > > alternative to HTTP Digest, which deserves a fresh look. > > > Hope this helps, > > > Walden > > > On Aug 19, 10:11 pm, cresteb <[EMAIL PROTECTED]> wrote: > > > Hello! > > > > I have some basic questions on the Register + Login + Keep session > > > alive process described on the Login Security FAQ. > > > > I know this is a little bit offtopic, but it would be really helpful > > > for me and other newbies if anyone can clarify some issues. > > > > This is how I see the process with some questions attached, please > > > correct it where necessary! > > > > Register: > > > > 1) Send username and password from client to server. > > > Q: I guess all the sites make this step over https so anyone can sniff > > > the password, right? > > > > 2) Store in the DB the username and the hash of the password. > > > > Login: > > > > 1) Send username and password from client to server (again over SSL). > > > > 2) Calculate the pasword's hash and look for a register in the DB that > > > contains that username and hash combination. > > > > 3) Return a session ID from server to client. > > > Q: Is this also done through https? If not, can't it be this session > > > id intercepted and used later to make a query as if you were other > > > user? > > > > During the session: > > > > 1) For every request from the client, include the session id, so the > > > server knows which user is sending the request and it is able to check > > > if the session is still active. > > > Q: Is secure enough just sending the session ID in order to identify > > > the user? > > > Q: The same as above...should it be sent through https? > > > > 2) Check if the session ID is valid or not. If its valid, send the > > > response with the data of the associated user. > > > Q: Is it also recommended to send a new session ID on each request so > > > we increase the security? > > > > Please, feel free to suggest me any document related with this topic. > > > > Thanks is advance! > > -- > > Hez --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
