A lot of databases provide encryption so that you can prevent sys admins from seeing the data without being authenticated to the DB itself. Oracle provides it natively, where MySql is a combination of 3rd party software. If you are really paranoid MySql provides AES encrypt/decrypt functions.
http://www.hotscripts.com/forums/database/54910-encrypting-mysql-database.html Like Danny said, no point in reinventing the wheel, just use SSL. Right now SSL is still justified by the simple fact that it would take more expensive hardware to break the encryption than any data would be worth that they may extract in most cases. For authentication, I would highly recommend using container managed security though with a JDBC realm. Most give you the option for choosing the hash type for the password. On Aug 2, 10:20 am, Danny Goovaerts <danny.goovae...@gmail.com> wrote: > Stefan has allready made some very good comments so I'm not going to > repeat them. > Some more additional thoughts. > > Regarding encrypting the data in the database. If a user does not > trust you (yourself and any of the people that have access to your > server) to look at his data in the database, > why would he trust you when you make the claim that his data is > encrypted in the database? Furthermore, encrypting the data precludes > providing any form of application > level support to your users. Unless your service is exactly providing > extremely secure storage of confidential data, I dont' see any reason > for encrypting the data in the database and in that case you should > find some security experts to assist you. > This of course does not mean that you should not take precautions > against data being accessed by unauthorized people or data being > disclosed. But that falls > under traditional secure server deployment. > > I'm afraid that there is no easy and proven solution to protect the > confidentiality and integrity of Internet based communication without > https. The SSL//TLS protocols have been scrutinized by security > experts. Unless you are such an expert, don't > think that you can come up with something that is solid enough. I > personally would not trust any security measure that has not been > published and analysed by the security and encryption community. > > Dannywww.cellamea.eu > > On 1 aug, 17:06, Stefan Bachert <stefanbach...@yahoo.de> wrote: > > > Hi Sven, > > > i did have similar thought in the past. > > Encrypting the database base would solve any "Datenschutz" data > > protection topic since the application provider would not be able to > > even read the data of his customers. > > However, I do not see any easy solution, yet. Just encrypting any > > database data would destroy any orderings on indexes. > > It would work when only using equivalence, but this is a hard limit. > > > The point of encryption should be the server. > > When you doing encryption on client side you must offer the encryption > > and decryption algo, too. > > So it is likely to loose more than to win. (And it is difficult to > > implement encryption without having an integral data type as it is the > > case with javascript). > > > To hash the password on client side is equivalent as to put the > > password in clear to the database. > > You loose security when doing so. Any attacker would just send the > > encrypted password, may be to a similar service using the same > > approach! > > > Any attacker could substitude the browser and code when he has a legal > > access to the service. > > So he can get the encryption algo and apply it to other users. > > > The only thing which is under your control is the server. > > > Stefan Bachert > > http::/gwtworld.de > > > Inquiries for professional GWT support are welcome. > > I am sorry, I won't do free personal support. > > > On 31 Jul., 19:07, 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/q...... > > > > 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 Web Toolkit" group. To post to this group, send email to google-web-tool...@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.
