The official Google Web Toolkit (GWT) developer discussion group. GWT lets you build AJAX apps in the Java programming language. ()

Sven | 31 Jul 2010 19:07

Ecryption best practices (server side, client side, password handling)?

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_Java
http://stackoverflow.com/questions/1238628/md5-hash-for-password-string-in-gwt-gwt-ext
http://stackoverflow.com/questions/695813/how-could-you-encrypt-user-data-so-only-they-can-decrypt-it

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:

(Continue reading)

headers

Stefan Bachert | 1 Aug 2010 17:06

Re: Ecryption best practices (server side, client side, password handling)?

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

(Continue reading)

headers

Danny Goovaerts | 2 Aug 2010 18:20

Re: Ecryption best practices (server side, client side, password handling)?

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.

Danny
www.cellamea.eu

(Continue reading)

headers

lineman78 | 2 Aug 2010 18:53

Re: Ecryption best practices (server side, client side, password handling)?

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...@...> 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

(Continue reading)

headers

Sven | 7 Aug 2010 12:58

Re: Ecryption best practices (server side, client side, password handling)?

Dear all,

thank you for providing advice and feedback. I agree that it is
questionable to believe that a user puts more trust in the statement
"we will encrypt your (sensitive) information on the DB on server"
than in the statement "we will not misuse your data". Why should he
believe that his data gets encrypted on the server if he has no trust
in the service at all?

However, optional encrpytion on client side may have positive impact
on trust. At least, by monitoring the server calls, the user may get
the proof that no unencrypted, clear text data leaves his machine. On
the other side, the critical part of this approach may be to convince
him that the application really makes use of the explained encryption
algorithm and does not simply send ROT-13 encoded data to the server.

SSL is also fine for increasing trust in data transmission, but it
does not influence the trust in the service provider (in this case,
me) that sensitive data is not disclosed once stored to the server
(intentionally or by chance, e.g. in the decribed example of db admins
looking at the db or logs). Also, the issue with SSL is that my host,
google app engine, does not support it with customised domain names,
as far as I remember.

I guess I will postpone this feature until more than just one user
asks for it.

Thanks!
Sven

(Continue reading)