tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <...@teamware.com>
Subject Re: Client-Cert authentication with Tomcat 4
Date Tue, 06 Nov 2001 15:58:23 GMT
Tim,

Very clearly put, however...

Timothy Fisher wrote:
> 
> I think your confusing a few elements.

Quite likely :)

> In a client-cert authentication mechanism, the fact
> that you possess the private key associated with the
> certificate is what is used to authenticate you.  This
> is a much stronger security policy than a pure
> password authentication scheme.

but it doesn't prove that you are entitled to hold that key.

> Antoher point of clarification, passwords are not used
> to encrypt/decrypt the certificates.  They are used to
> protect (encrypt/decrypt) the private key.  The
> private key is the key to the security of this
> mechanism.  The certificate itself can be made public
> with no dire consequences.  In fact, it is often
> advantageous to make the certificate publicly
> available.
> 
> Comparing client-cert with a password scheme, such as
> form or digested.
> 
> - with client-cert, you must have possession of the
> private key and the passoword protecting it.  This is
> 2-factor authentication.
> - with form and digest mechanisms, you only need to
> know/guess the password.  This is single factor
> authentication.

With client-cert you just have to guess the browser password, at that
point you have access to all the systems that recognise the key.

> - with form/digest mechanisms, the passwords or a
> digested form of them must be centrally stored.  This
> always adds another security risk, and eliminates the
> possibility of achieving non-repudiation.
> - with client-cert, the password needs to reside NO
> WHERE except in the private key owners head.  There is
> no central authority that needs to have any knowledge
> of the password.
> - form/digest mechanisms are not scalable.   They can
> only be used to authenticate with users who already
> know them (i.e. know a form of their password for
> checking against)
> - with client-cert, you can authenticate against any
> server.  There does not have to be any pre-established
> relationship.
> 
> If you have the capability of choosing between
> client-cert and digest/form based authentication,
> client-cert is vastly more secure.

I agree with most of your points about storage of password, but given
current browser technology there is no mechanism to force things such as
minumum length, password rotation and required password changes whereas
this may be possible in the server.  It seems like client-cert combined
with form/digest mechanism would provide the most secure means.

Antony
> 
> --- Antony Bowesman <adb@teamware.com> wrote:
> > Thanks Richard, that made things clearer.  I was
> > confused by statements
> > such as
> >
> > "Currently the most robust form of client
> > authentication"
> >
> > as in many cases the accompanying phrase
> >
> > "as long as physical access to the private key (and
> > the computer where
> > it is stored) is restricted to the user who owns the
> > key"
> >
> > was not included.
> >
> > Antony
> >
> > Richard Troy wrote:
> > >
> > > Antony,
> > >
> > > unless I'm mistaken, and I could be, the password
> > on the client side is
> > > used for encrypting and decrypting the clients
> > certificate. When the
> > > certificate is first created, the password is
> > given. without the password,
> > > there's no authentication that the user of the
> > certificate really is the
> > > user, so it's required. This puts confidence of
> > the certificates
> > > authenticity in the hands of the user - it's no
> > more nor any less secure
> > > than any other password scheme, except as you
> > point out, there's no way
> > > for the server-side to enforce password selection
> > criteria. That would
> > > have to come from the certificate generation
> > process...
> > >
> > > Hope this helps,
> > >
> > > RT
> > >
> > > --
> > > Richard Troy, Chief Scientist
> > > Science Tools Corporation
> > > rtroy@ScienceTools.com, 510-567-9957,
> > http://ScienceTools.com/
> > >
> > > On Tue, 6 Nov 2001, Antony Bowesman wrote:
> > >
> > > > Date: Tue, 06 Nov 2001 08:30:38 +0200
> > > > From: Antony Bowesman <adb@teamware.com>
> > > > Reply-To: Tomcat Users List
> > <tomcat-user@jakarta.apache.org>
> > > > To: Tomcat Users List
> > <tomcat-user@jakarta.apache.org>
> > > > Subject: Re: Client-Cert authentication with
> > Tomcat 4
> > > >
> > > > Timothy Fisher wrote:
> > > > >
> > > > > You will get prompted for your password by the
> > browser
> > > > > when using client-cert authentication.  The
> > password
> > > > > is necessary to unlock your private key.
> > > >
> > > > Oh yes.  It never asked me because it was set to
> > the default of only ask
> > > > the 'first' time the cert is needed.  (Netscape)
> > Anyway, it still seems
> > > > odd to delegate password security to the
> > workstation where there is no
> > > > way of an administrator enforced password policy
> > (e.g. min length,
> > > > alpha/numeric, forced changes) such as would be
> > available by a back end
> > > > password mechanism.
> > > >
> > > > Once you have access to the browser via a
> > possibly guessable password it
> > > > gives you access to the powerful certificate
> > with no further
> > > > authentication done by the server to
> > authenticate the user.
> > > >
> > > > I can't see the use for CLIENT-CERT
> > authentication, it seems like form
> > > > or digest authentication over SSL with
> > clientAuth=true set in server.xml
> > > > would achieve better security.
> > > >
> > > > Rgds
> > > > Antony
> > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have followed the comments in server.xml
> > to get
> > > > > > SSL working and have
> > > > > > set up the security example to have
> > client-cert as
> > > > > > the auth method in
> > > > > > web.xml.  When I first connect to my host,
> > the
> > > > > > browser asks which
> > > > > > certificate I want to send.  However, the
> > browser
> > > > > > then prompts me for a
> > > > > > username/password (as in basic
> > authentication) when
> > > > > > I try to connect to
> > > > > > the protected page.
> > > > > >
> > > > > > I am using my own realm, however, from the
> > Realm
> > > > > > code, it seems that
> > > > > > none of the realm implementations (including
> > my own)
> > > > > > implement the
> > > > > > abstract getPrincipal)() method in
> > RealmBase.java,
> > > > > > i.e. they all return
> > > > > > null so it seems that this will never work
> > with the
> > > > > > supplied realms.
> > > > > >
> > > > > > Am I missing something, does anyone have
> > this
> > > > > > working?
> > > > > >
> > > > > > Rgds
> > > > > > --
> > > > > > Antony Bowesman
> >
> > --
> > To unsubscribe:
> > <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands:
> > <mailto:tomcat-user-help@jakarta.apache.org>
> > Troubles with the list:
> > <mailto:tomcat-user-owner@jakarta.apache.org>
> >
> 
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
> 
> --
> To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>

-- 
Antony Bowesman
Teamware Group 
adb@teamware.com
phone: +358 9 5128 2562
fax  : +358 9 5128 2705

intra / extra / Internet solutions at www.teamware.com

--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message