Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Security / August 2005

Tip: Looking for answers? Try searching our database.

Sensitive information in applet source code

Thread view: 
Mogens Heller Jensen - 29 Aug 2005 15:41 GMT
Hi group!

I have made an applet which works as a simple FTP client. Its purpose is to
upload files to a server (located at the applet's origin) when the files are
too large for HTTP upload.

The applet is signed and everything, and it works perfectly.

However, one last problem remains to be solved: Where do I store the login
and password used to log in to the FTP server? Right now they are hard-coded
into the source file, but it is very easy to use a decompiler on the .class
file to see every string in the source.

I have heard about bytecode obfuscators, but to my knowledge they only make
it harder to read the code, they do not actually add any security.

Thanks in advance :o)

Regards,
Mogens
Thomas Hawtin - 29 Aug 2005 16:16 GMT
> I have made an applet which works as a simple FTP client. Its purpose is to
> upload files to a server (located at the applet's origin) when the files are
> too large for HTTP upload.
>
> The applet is signed and everything, and it works perfectly.

Is that necessary for an upload. IIRC, there will be a control
connection plus a connection from client to server for data (although
there are different modes).

> However, one last problem remains to be solved: Where do I store the login
> and password used to log in to the FTP server? Right now they are hard-coded
> into the source file, but it is very easy to use a decompiler on the .class
> file to see every string in the source.

Or just: find . -name "*.class" -exec strings {} \; | more

> I have heard about bytecode obfuscators, but to my knowledge they only make
> it harder to read the code, they do not actually add any security.

Quite. Security by obscurity is no security. You don't even need to look
at the code, just monitor the TCP packets. The login for the FTP server
should be dealt with in the same way as if you were using HTTP.

Tom Hawtin
Mogens Heller Jensen - 29 Aug 2005 18:42 GMT
>> I have made an applet which works as a simple FTP client. Its purpose is
>> to upload files to a server (located at the applet's origin) when the
[quoted text clipped - 5 lines]
> plus a connection from client to server for data (although there are
> different modes).

?
Could any of these be used to transfer a file from the client to the server?
I do not see how this should be possible.

The reason FTP is used when a simple HTTP transfer could have been done is
that the file sizes range from 200 MB and up - and when IIS receives a file
via HTTP is stores the entire file in RAM until it is fully received. This
would be a disastrous situation if a couple of people did this
simultaneously.

>> However, one last problem remains to be solved: Where do I store the
>> login and password used to log in to the FTP server? Right now they are
>> hard-coded into the source file, but it is very easy to use a decompiler
>> on the .class file to see every string in the source.
>
> Or just: find . -name "*.class" -exec strings {} \; | more

Yes, we can agree that it is easy to learn what strings the .class-file
contains.

>> I have heard about bytecode obfuscators, but to my knowledge they only
>> make it harder to read the code, they do not actually add any security.
>
> Quite. Security by obscurity is no security. You don't even need to look
> at the code, just monitor the TCP packets. The login for the FTP server
> should be dealt with in the same way as if you were using HTTP.

Security by obscurity not secure, exactly my point.

Nice point though about the TCP packets not being encrypted in any way - you
could argue that securing (if it was possible) the login and password would
serve no purpose since a packet sniffer could be used to monitor the
unencrypted communication between the applet and the server.

I think the solution will be to obfuscate the code, since this will make it
a bit harder for script-kiddies to learn the login and password. If a real
cracker wanted to compromise the system he would know how to do it anyway.

Thanks for the input!

-Mogens


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.