[2606] in cryptography@c2.net mail archive
Web Authentication (was: SSL3 info leak)
daemon@ATHENA.MIT.EDU (Rick Smith)
Wed Apr 29 22:54:30 1998
In-Reply-To:
<6B5344C210C7D011835C0000F8012766017A75C2@exna01.securitydynamics.com>
Date: Wed, 29 Apr 1998 11:17:47 -0500
To: cryptography@c2.net
From: Rick Smith <rick_smith@securecomputing.com>
Cc: "Trei, Peter" <ptrei@securitydynamics.com>
At 2:56 PM -0400 4/28/98, Trei, Peter wrote:
>In SSL3, the server sends it's public cert to the client in the clear
>(has to be, since the cert is required before the session key can
>be exchanged). ......
>
>This is an identity leak, since the client's cert contains a lot
>more info about the client than could be garnered from the TCP &
>IP headers alone.
That's an interesting point. I've been thinking a bit recently about the
subtle differences between alternative Web authentication methods. There
seem to be the following choices:
1) Forms based authentication
2) Client password prompt
3) Client SSL authentication
So, here's a "draft" of my analysis of the significant security
differences. Comments, additions, corrections, and disputes are welcome.
I. Forms based authentication
- where the site has an application with its own authentication mechanism,
and the authentication data is passed through the Web software to this app.
One obvious example would be a back end DBMS that collects the
authentication data (name and password or OTP), makes the authentication
decision, and then performs the operation based on the authenticated
identity. Arguably this is the same model used for credit card payments,
except that the "authentication" consists of validating card identification
details and the account balance.
Problems:
1) Passwords might go in the clear, which could be a problem unless a One
Time Password (OTP) system is used.
2) If SSL is used to protect passwords from sniffing, you have to worry
about the weakness of 40 bit exportable crypto.
Benefits:
1) Client isn't involved in the authentication process at all, so mistakes
by the client software won't accidentally authenticate the wrong
transaction.
2) If strong SSL is used, the user's ID isn't visible to sniffers. However,
this assumes that the user has "scrubbed" the client environment so that it
doesn't provide other identifying information, or privacy may be
compromised in other ways.
II. Client password prompt
- where a page "authentiation failure" causes the Web browser to put up a
password prompt, and then puts the userid and password into subsequent HTTP
messages sent to that host.
Problems:
1) Passwords might go in the clear, which could be a problem unless a One
Time Password (OTP) system is used.
2) If SSL is used to protect passwords from sniffing, you have to worry
about the weakness of 40 bit exportable crypto.
3) Passwords are often cached so they might be used to authenticate an
unintended HTTP transaction.
Benefits:
1) A given userid-password pair is generally only sent to a single
destination host, so it won't be used to authenticate transactions with
other hosts.
2) If strong SSL is used, the user's ID isn't visible to sniffers. However,
this assumes that the user has "scrubbed" the client environment so that it
doesn't provide other identifying information, or privacy may be
compromised in other ways.
III. Client SSL authentication
- where the client and server use a public key certificate to authenticate
the client.
Problems:
1) Once the user has unlocked the wallet (or whatever) that holds the
certificate, it will be used to authenticate Web transactions on the behalf
of the client software. It's not clear how much awareness or control a
naive user will have of this process. [I haven't personally looked at this
in the context of Java applets, but it seems like a potential source of
real risk].
2) User identification information is provided in sniffable form when the
client certificate is sent as part of the SSL authentication protocol
(Thanks to Peter Trei for this one, and derived ones above).
Benefits:
1) A sniffer will not recover information that allows trivial spoofing of
identity. The authentication is more akin to a typical OTP authentication
than the provision of a simple password. This level of strength holds true
even if you're using "export grade" SSL. Arguably it's easier to attack an
export grade PK certificate (512 bit modulus), but it's still hard.
2) Strong authentication becomes user friendly since it's integrated into
the browser. The user may be able to authenticate to a variety of sites
without having to keep track of multiple passwords and userids. The user
gets the strength of OTP authentication without a separate software package
or handheld token.
I haven't mentioned the possible roles of cookies in password management.
The systems I've seen doing this seem to be a blend of techniques 1) and
2). But I'm not sure if they combine the benefits or the problems :->
Comments?
Rick.
smith@securecomputing.com
