> 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