tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Fisher <trfishe...@yahoo.com>
Subject Re: Client-Cert authentication with Tomcat 4
Date Tue, 06 Nov 2001 15:04:55 GMT
I think your confusing a few elements.

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.  

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 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.

Tim

--- 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>


Mime
View raw message