I use both... but i guess it's just my case... my app is connected to Facebook and since something in their API catches fire daily over there, i decided to use one thing for something and another for the rest... i have to do a HmacSHA256 verification to ensure the data comes from FB and there's also the OpenGraph thing with token and code trading... check GWT Crypto to encrypt client-side... use https (if you can)... and verify the data comes from where you think it comes at the server side... and remember that if someone has access to the datastore it doesn't matter if you encrypt, hash or whatever... if they delete the info, it's the same thing. Control the access to the information and you'll be on the safeR side... nothing is perfect...
On Jul 31, 12:07 pm, Sven <sven.ti...@googlemail.com> wrote: > Dear group, > > I want to extend a GWT/GAE application by offering the option to > encrypt information entered by the user on client side in the > database. The goal is to increase trust when storing potentially > sensitive data, e.g. to prevent that people who have access to the DB > (like me) have read access to the stored information. > > For client-side encryption using GWT I found this > post:http://www.mooreds.com/wordpress/archives/000529 > > However, others do not even recommend to compute password hashs on the > client and propose to do that on the > server:http://www.owasp.org/index.php/Hashing_Javahttp://stackoverflow.com/questions/1238628/md5-hash-for-password-stri...http://stackoverflow.com/questions/695813/how-could-you-encrypt-user-... > > From user's perspective, I would not be comfortable with transmitting > my data unencrypted to the server (even using HTTPS), as the server- > side may for example log my information (and my password!). Especially > for the password-part I would feel unconfortable, as many people tend > to reuse their passwords (please no discussion about this :-)). > > Currently, I see two options: > a) Encrypt and decrypt the information on the client using JS/GWT. > Pro: The password never leaves the browser, the unencrypted > information never leaves the browser. Con: Depending on the size of > the data the encryption/decryption may be slow; if loaded via HTTP, > the JS code may be compromised, etc. > b) Encrypt and decrypt the information on the server. Pro: Fast. Con: > The information is transmitted unencrypted. > > What would be your recommendation? > > In case of server-side encryption, would it make sense to hash the > password on client side and to use the hash to encrypt/decrypt? Or > would that be a no-go? > > What happens if the user forgets his/her password? All data lost, I > guess? > > I have no deep practical experience with cryptography, so I would > appreciate any suggestions or pointers to resources in the web. My > goal is not to have a bullet proof solution for highly sensitive > information, but it should be an improvement compared to the current > implementation (no HTTPs, no encryption). > > Thanks > Sven > > PS: x-post Google App Engine for Java, Google Web Toolkit -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
