Java Web Start Security - Can others 'javap' our class files from client machine?

[Deshaies]

Hi,
I have a question concerning security with Java Web Start.

We have a java console/desktop application that we would like to make
available to the public via Java Web Start.

My question is this:

1. When someone uses Java Web Start to automatically download and
execute our jar file, is it possible for them (the user on client
machine) to locate and/or de-compile our class files contained within
the jar file?
(we have a database path and login/password info. hard coded into our
Java class - is this info. secure?)

hope this isn't a dumb question,

thank you very much for your feedback,
Deshaies - Anaheim, CA, USA

 

[Andrew Thompson]

My question is this:

1. When someone uses Java Web Start to automatically download and
execute our jar file, is it possible for them (the user on client
machine) to locate and/or de-compile our class files contained within
the jar file?
Yes.

(we have a database path and login/password info. hard coded into our
Java class - is this info. secure?)

No.

You can make it _difficult_ for people to
figure the codes, but it is not impossible.

 

[Deshaies]

No.

You can make it _difficult_ for people to
figure the codes, but it is not impossible.

What types of things can be done to make it difficult?
thanks,
Jean-Paul Deshaies

 

[CN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| is it possible for them (the user on client> machine) to locate and/or
de-compile our class files contained within
| the jar file?

Ability to locate class files - yes, always
Ability de-compile class files - yes, unless you obfuscate your class
files (http://www.yworks.com/en/products_yguard_about.htm). However,
there is no guarantee that no one can decrypt your obfuscated class file.

| (we have a database path and login/password info. hard coded into our
| Java class - is this info. secure?)

It depends whether your class files are decompiled, but generally it is
not a good practice.

Are you providing open access to your database server to the whole
Internet? Do you have a middle tier that sits in between the clients and
the database server? If the answers it yes, the you should hard code
database authentication into the middle tier.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAdlxHgtM42grMkd0RAt6SAKCQMKSUffPCPOcSMagV6tb7x8WQtgCfdiAT
4erR3J6V9++e8VJ6DVb4Mbw=
=o2b6
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

What types of things can be done to make it difficult?

Burn your app. straight onto chips.
Put those chips into hardware with no I/O.
Place the hardware, as well as all specs., plans,
notes, anybody that worked on it or saw it etc.,
into a big double lock safe.
Drop the safe into the Marianas Trench.

That would make it difficult.

[ (shrugs) I go open source - why
would I bother with such crap? ]

 

[Deshaies]

Burn your app. straight onto chips.
Put those chips into hardware with no I/O.
Place the hardware, as well as all specs., plans,
notes, anybody that worked on it or saw it etc.,
into a big double lock safe.
Drop the safe into the Marianas Trench.

That would make it difficult.

Ok, I have everything in a big double lock safe (including the people
that have worked on the project). Could you give me directions to the
Marianas Trench?

Seriously though, thanks for your input. The app we are creating is
for the healthcare industry and peoples personal medical histories are
at stake. I believe in open source and feel that most software should
be open source. It would not be a good idea, though, to have
everyones medical history available to the public.

thanks again for your feedback,
JP

 

[Andrew Thompson]

On 9 Apr 2004 13:43:44 -0700, Deshaies wrote:

..Could you give me directions to the
Marianas Trench?

I could give you directions, but then..
I'd have to kill you. ;-)

 

[Juha Laiho]

(e-mail address removed) (Deshaies) said:

Seriously though, thanks for your input. The app we are creating is
for the healthcare industry and peoples personal medical histories are
at stake. I believe in open source and feel that most software should
be open source. It would not be a good idea, though, to have everyones
medical history available to the public.

Open source is not an issue here. The issue is that you shouldn't
place "fixed" authentication tokens anywhere that ends up outside
your control. So, users using that client must have their personal
authentication tokens that are not built-in to the client.

As someone else wrote, fixed authentication tokens can be used in
mid-tier that runs on a controlled platform.

 

[Roedy Green]

Open source is not an issue here. The issue is that you shouldn't
place "fixed" authentication tokens anywhere that ends up outside
your control. So, users using that client must have their personal
authentication tokens that are not built-in to the client.

Have a look at http://mindprod.com/ggloss/thumbdrive.html

as a way of managing private keys for your end users in ways that
can't be easily compromised and that are convenient.

On my plate coming up is implementing such a scheme for the Replicator
so that files are always stored and transported in encrypted form.

http://mindprod.com/zips/java/replicator.html

It will be used by pharmaceutical companies for distributing drug
research data.