If I can see your encrypted passwords, then I can see the
code that decrypts
them. And with that I have your passwords. It only adds a
step to my effort
to crack your security.
Is that strictly true? If you use the method that is used to encrypt Unix
passwords (google for JCrypt for
Tomcat must send the unencrypted password to the database. Thus it must
decrypt it. The whole issue is that Tomcat must act like a user in the role
of the database. So it must know the password. The best method is to lock
the user away in a room, then it doesn't matter if the password is
Your argument about short duration attacks is optimistic at best. Most
systems are so poorly secured and monitored, that breakins aren't detected
anywhere near that quickly.
Let's face reality here. The only safe way to hide the JDBC information is
to have the SECRET (encryption password) not
George Sexton wrote:
If you really want to do this, then you will need to have your application
startup have a method that permits an operator to enter in the password for
the JDBC information at startup.
Whatever - the key is to be able to insert an application-defined
processing step between
Please do not start the flame war. Check what I have to say. I am really
not a beginner in this area.
First, feature I mentioned is commonly implemented on every major
application server platform that I know- JBoss, WebSphere, WebLogic,
Oracle AS.
It's purpose is not to permanently protect the
I won't argue any of these points. They are all valid. Often the request for
encryption comes from individuals who want to lock there goods in a safe but
leave the safe in the back of a truck with the keys in the ignition. In your
case you want to hide the keys and disable the truck.
Since
Edmon,
I am not sure if I understand, but perhaps you should tak a look at Matt
Raible's Appfuse application framework at: https://appfuse.dev.java.net/
His solution uses:
- SSL (optional of course, just a servlet parameter);
- Container Managed Authentication;
- a custom login servlet that
Why do you give your webapp access to a sql user with all this dangerous
and unneccessary access? The user name / password on the
externally-accessible machine could have a sql login that only granted
access to views (or better yet) procedures, that allowed for the minimal
necessary access: that's
Okay, I know I am starting a flame war but why go through the effort?
If I can see your encrypted passwords, then I can see the code that decrypts
them. And with that I have your passwords. It only adds a step to my effort
to crack your security.
The only way to really secure them is to secure
