Nic Ferrier wrote:
> 2. [SSL is] quite compelx for users to setup (they have to go an get
> certificates and so on - people are just confused by all of this)
This solution is simple? Yikes! It's pretty convoluted, and I have to agree
with Miles; it isn't secure.
> 3. one can have trouble using ANY ports other than 80 across ultra
> conservative firewalls.
Bad firewall administrators should not dictate security on *your* server!
> Drawbacks are:
>
> - you probably MUST have users you know about outside of the web (ie:
> sending them postal keys)
This limits the applicability critically.
> I don't see this... There are all sorts of tricks you can use to see
> if someone alters the applet as it crosses the wire... remember that
> it is only the first instance that is important (because after that
> you're just using the same applet)
If I have the control needed to modify the applet in transit, none of the
approaches you suggest to detect it will work. The only thing that you can be
certain of would be a signed Applet... which requires a certificate, so why not
use SSL?
> What I meant by my "nearlly as good" statement was that, considering
> the problems with SSL (including no servlet engine) and considering
> that this method works then it's not a bad fit.
Here's why it doesn't work:
What the client sends to the server is a static password encrypted with a
static key. The result will be the same each and every time. This makes it
subject to a replay attack. You don't need to know the password or the key,
you just need to correct resulting ciphertext.
A better approach is this:
Step #1
WWW Server downloads page with "seed" text and MD5 in JavaScript.
I have a Free Software MD5 written in JavaScript if anyone wants it.
The seed causes the MD5 hash to change every time, preventing
replay attacks.
Step #2
User types in password and submits form.
JavaScript calculates MD5(password + seed) and sends it with the POST
Step #3
Servlet compares its MD5(password + seed) to that of the user.
NOTES:
1. This can only be used to verify that the user knows his or her password,
it does not work to encrypt new information, as the MD5 hash
cannot be reversed.
This method is what Nic's method is spiralling towards. It's also the exact
same system used for HTTP "Digest" authentication. Digest authentication is
not supported very well (IE5 or Netscape4.x do not both support it, but I
forget which is missing it). This approach allows you to do digest
authenitcation without using the HTTP authentication header or relying on
broswer support.
-- Charles
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
