Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4E8B56D0.7030506@ice-sa.com>
Date: Tue, 04 Oct 2011 20:56:16 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Using multiple login pages
References: <1317746617.4e8b37b9f03d5@netmail.pipex.net>
 <99C8B2929B39C24493377AC7A121E21FB0038543D8@USEA-EXCH8.na.uis.unisys.com>
 <1317748330.4e8b3e6aefdcb@netmail.pipex.net>
 <4E8B46DA.6020605@christopherschultz.net> <4E8B4A01.4080709@ice-sa.com>
 <1317751568.4e8b4b103edd5@netmail.pipex.net>
In-Reply-To: <1317751568.4e8b4b103edd5@netmail.pipex.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

appy74@dsl.pipex.com wrote:
> Not sure about which version of security I will use but I would like to accommodate MD5 
> verification into things. There's no sensitive or confidential info in the system either so 
> protected page access may not be required. 
> 
I don't know what you have in mind, but there are some basic principles to avoid wasting
your time :

1) In Tomcat (and other servlet engines), there are 2 different ways of doing authentication :
- declarative, as per web.xml. In that case Tomcat, /before it evens calls the webapp or
any filter in it/, intercepts a non-authenticated call and returns *the* login form to the
browser.  It then (later) intercepts the submit of that form by the browser, checks the
credentials, and if they pass muster, it allows the call to proceed to the webapp which
the user wanted in the first place.
- application- or filter-based authentication : in this case, Tomcat is not aware that
there is an authentication taking place.  It forwards the call to the webapp, and a filter
/in the webapp/ intercepts the call and does whatever is needed to check the
authentication, return a login form etc..
This second authentication scheme is probably more flexible for doing the kind of thing
you seem to want to do (but also more complex to do).

2) There already exist a number of authentication systems on the market.  Unless this is 
considered as an exercise, re-use an existing one instead of rolling you own.  Web 
authentication looks deceptively simple, but is in fact quite complex and delicate, and 
open to many mistakes which completely defeat the purpose.
(This being said, if it is an exercise, it is an interesting area).

3) anything that your server sends to a browser should be considered "open and lost".
Once you send something out there, the recipient can do with it what
he wants : save it, analyse it, copy it, decompile it, falsify it, re-send it to your
server and whatnot.  There is no practical way to avoid that.
(You don't even know that it is really a browser out there).

4) the only good way to secure things if you do form authentication, is to work over HTTPS.
The customer is going to type a login-id and a password, in the form, in clear.
The browser is going to send this over HTTP to the server.
Anyone who can "sniff" this traffic is going to see what is sent.
And even if he does not understand it, he can record it and replay it.
But not under HTTPS.

5) users always take the easy path.  That means that, if they can choose their password,
they will pick the same one as the one they use already for their network login, for their 
email account, for their bank account, etc.. So if anyone subverts /your/ login system - 
even if on /your/ server there is nothing vital to grab - the damage is probably not 
limited to your server.  You don't want to be accused of facilitating the bad guy's job.

6) If you are thinking of encrypting the data in the browser, it's probably not worth the
effort. For that, you will have to write some special code, and download it to the
browser to run it there. Once you do that, it can be saved, analysed, replicated, 
falsified, disabled.
So why bother ?

HTH. Been there, etc..


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org