Which warning are you referring to? The warning about "unknown certificate
authority?" DO NOT tell people to ignore this warning. It might be benign
in your case, but knowing how most employees think, they would ignore it
for all other sites that may not be benign.
Instead, there are two other options. First, you can actually get a
certificate from Verisign or Thawte. Done.
Or you can self-sign the certificate (which of course is quite a bit
cheaper), and then go around to all machines in your company and install
the certificate (usually, it is fairly easy to do: visit one of the
HTTPS-protected Web sites, and then the warning message should give you
the option to install the certificate).
On Mon, 28 Jul 2003 18:57:46 +0000, Aaron wrote:
Thanks for the info.
https may work then, the only people that are going to be using this are
employees, so we can just ignore the warning (but that does not look
very professional).
I am still going to try to figure out how to configure Tomcat, as I
believe this is the most secure way - but I have tried to sort through
"The Apache Jakarta Project: The Tomcat 4 Servlet JSP Container" @
http://jakarta.apache.org, but have not been able to make it work yet.
If you know of any good books or links that explain this process step by
step, the info would be most appreciated.
Thanks again
Aaron.
"Silvio Bierman" <sb******@idfix.nl> wrote in message
news:3f***********************@news.xs4all.nl... Aaron,
The most important security issue involved here is the submission of
the login-parameters. If it is a plain HTTP form the data can easily be
intercepted and the login-parameters can be extracted.
There are several ways to prevent this. One would be to use HTTPS
instead
of HTTP for submitting the form. This has the disadvantage that you need
an (expensive) certificate.
Another solution is to do the following. When you generate the
login-form
on the server-side generate some random key with it. On the page, put some
JavaScript that will hash-encode the entered username/password using
the random key in the hash algorithm. Make sure you use a destructive
hash function with sufficient spreading. Do not post the
username/password but submit the username/hashresult. Since on the
server you know the random
key and the hashfunction and the users password you can recalculate the
hashvalue from that data. If the hashvalues match you allow the logon
attempt, otherwise you reject it. This way if someone captures the
posted data he can not use it to attempt a successive logon since the
random-key that was used is no longer valid on the server.
It is not as secure as HTTPS would be but it comes close enough for
most situations. Using a good hash function and random-generator can
make it a pretty secure mathod.
Regards,
Silvio Bierman
--
Keep American Families united! Support H.R. 539 and H.R. 832
For more information, see
http://www.kkeane.com/lobbyspousal-faq.shtml