thinking about hackers
Dear friends,
in my previous post I suggested to use CVS commands to create a "dynamic hard code passphrase". Of course it is a naive security strategy, but my project has no safety requirements excpet avoid the curios people.
i.e., I have a system installed in a web server - it is the Cejug-Classifieds project, hosted at https://cejug-classifieds.dev.java.net/.
The code is running well, but I got myself to think about the hackers behaviour.
Imagine a hacker trying to break my system, considering such hacker should with full access to the server. I know this is an unsafe scenario, but I just trying to make the things more tricky to the hacker...
what you suggest ? use a external key ? a keystore ?
>
> what you suggest ? use a external key ? a keystore ?
You could get the best of both worlds! Make the application request a passphrase that is used to access the key in the keystore. This way the hacker will not be able to find the actual key used without getting into the running application.
I know it can be difficult to start a web application and request a passphrase but it is not impossible. A simple Swing GUI should suffice BUT if the server is 'headless' then you cannot use swing. I once wrote a simple C++ JNI password requestor for a client - I don't know how secure it was but the client seemed happy.
ok, but the part of the application which uses the passphre is automated, i.e., it is a server thread - a timer task.
The system has some mail procedures. The server checks about new messages in the Inbox within a time interval.
There are no user in the moment of this verification. The timer task read the Mail host, user and password from the configuration file. Thi sconfiguration file is exposed on the server. My first precaution was to encrypt the information of this configuration file, but it seems naive because a hacker can obtain the passphrase in my OpenSource CVS repository and use it to decrypt all the information ..
I磎 thinking about some tricks in order to make the hacker duty a bit more dificult :)
> There are no user in the moment of this verification.
> The timer task read the Mail host, user and password
> from the configuration file. Thi sconfiguration file
> is exposed on the server. My first precaution was to
> encrypt the information of this configuration file,
> but it seems naive because a hacker can obtain the
> passphrase in my OpenSource CVS repository and use it
> to decrypt all the information ..
Surely the naive part is having the key in CVS! The key should be stored in somones head or in a repository secured by a passphrase stored in somones head.
>
> I磎 thinking about some tricks in order to make the
> hacker duty a bit more dificult :)
So you seek the Holy Grail!
ehehheh :)))))) ok, you are right....
but lets think just for fun about some protection strategies ......
my first guess is to use the CVS Commands as the passphrase.
i.e.:
passphrase = "$Revision$;
everytime one commits the code, this passphrase will change. It will have the same format, but with different date and version ....
private static String passphrase = "$Id: Password.java,v 1.1 2005/09/24 13:17:19 felipegaucho Exp $";
in a real release I will replace that with a personal phrase as you suggested, and odf course I won磘 put that phrase in the CVS... but imagine how odd is such task - every new release I have to download the source code, replace the phrase, recompile, release and than undo checkout.. One can forgett to do that ... I just tough about automated strategies.
Using one or more of the CVS keys will slow down an attacker but it is hardly going to cost him more than about 10 minutes to find out what you have done!
I have tried using the SHA1 hash of the encryption class as the key but, like yoru CVS approach, once a hacker de-compiles the class he can see what has been done and after that it is easy.
The approach I have found best is to just place the passphrase/key as bytes in a byte array. This in no way stops a hacker finding the key but the casual observer cannot 'see' it as a string within the class file.
If you find a good approach then please post it as there are many people trying to solve this problem. Of course if you do publish the approach then much of it's value will be lost!
i'm a bit confused by your scenario you are describing but, of course, a hard-coded password is always a bad idea.
perhaps you could describe your situation a little better, but i think the solution is to have the server/system accept an "initiation" password and then it can use _that_ for all on-going functions.
the advantage would be that upon server restart/etc the password is gone and, of course, the password is not hard-coded :)
maybe it doesn't meet your requirements; if it doesn't pleasy try and give more details :)
the scenario is simple:
how to avoid a person with access to server to read the web.xml of your web application?
In my project, the system uses a mail server to notify the users about some situations.... The systema acces the mail server through SMTP protocol, and it need a login and a password in order to acces this mail server.
Where to store this information ? I choosed the web.xml <contex-param> tags to do that. How to avoid a curious people to spy my configuration file ?
here comes a fragment of my web.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="cejug-classifieds" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd ">
<servlet>
<servlet-mapping>
<servlet-name>classifieds</servlet-name>
<url-pattern>/classifieds</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>classifieds</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<context-param>
<param-name>mail.smtp.host</param-name>
<param-value>gmail-smtp.l.google.com</param-value>
</context-param>
<context-param>
<param-name>mail.smtp.user</param-name>
<param-value>cejug.classifieds@gmail.com</param-value>
</context-param>
<context-param>
<param-name>mail.smtp.password</param-name>
<param-value>notthistime</param-value>
</context-param>
</web-app>
solution is simple; as i describe - a "setup" phase.
consider:
you visit https://www.com/SETUP.jsp
it prompts YOU (admin) for the mail server password.
it can then save in memory and use it as required.
the disadvantage is that each time the server is restarted you must initialise it this way. the advantage is that if the mail server password changes you don't need to re-upload that file :)
