[WEB SECURITY] Ajax and secure web communications

Lyal Collins lyal.collins at key2it.com.au
Tue May 17 20:00:20 EDT 2005


I'm not sure of you definition of "client-side authentication", but there
are at least 2 situations
A. Verifying the user is someone permitted to access some service or content
B. the remote client verifying the server is the expected one.

PKI and SSL/TLS might be useful for low security uses in case B, since that
is all browsers do today.  Since the user is abstracted from Ajax layer
certs, client side certs in the Ajax engine does, at best, tell the server
this is the same client that connected recently, provided the client-side
cert hasn't changed somehow.  Until clients that are trusted, locked down
and 'only functionality permitted by the manufacturer' come along, that is -
just like the old bank ATM and POS devices.

In the case A situation, anything that is based upon password authentication
or eventually biometrics will work fine, which includes PKI, Kerberos,
Radius etc in the near term (PKI is just a password verifying tool, albeit
remote verification of password and local trust of the cert used, which is
not the same as trusting the user).  SSL may still play a role of minimal
confidentiality, but not user authentication.

In short, Ajax allows passwords and existing application trust processes to
remain valid, regardless of the extra technology wrapped around passwords,
such as high cost PKI and at a less costly level, Kerberos, radius etc, or
simply use the same password rust processes that backend systems have done
for the past 30 years.


If you are looking for better mechanisms than SSL/TLS, then the 2-party
trust model works much better and lest costly that the multi-party PKI model
(federated identity is simply a sub-component of 2-party trust - relying
parties have always been able to use added trust indicators in addition to
password + ID).
However, the 2party trust model is more reliable, security wise, than
distributed multi-party models, and far easier to implement
cryptographically.  

If you are seeking innovative ideas on the latter, then we need a new
industry approach to look at existing models and solutions.

Lyal




-----Original Message-----
From: Chris Hammond-Thrasher [mailto:chris.hammond-thrasher at hushmail.com] 
Sent: Wednesday, 18 May 2005 8:38 AM
To: websecurity at webappsec.org
Subject: [WEB SECURITY] Ajax and secure web communications


Hi,

I recently blogged about Ajax and secure web communications. While 
SSL/TLS is great, sometimes another cryptographic solution is 
needed to solve the problem at hand - I use Hushmail as an example 
of this. I would appreciate comments on the idea that I put 
forward. Here is an excerpt:

"While the Ajax model was not conceived by the geniuses at Google, 
Adaptive Path, or wherever, as an information security tool, I 
believe it may hold the key to reconceiving secure web 
communications... With encryption and signature services, and key 
management and/or client side authentication services embedded in 
the Ajax Engine layer, combined with identity management and access 
control on the server side, one can envision a powerful new class 
of secure web communications. And authentication could be handled 
through a PKI-based mechanism, kerberos, or something else."

http://thrashor.blogspot.com/2005/05/ajax-and-secure-web-
communications.html

-CHT

blog - http://thrashor.blogspot.com


---------------------------------------------------------------------
The Web Security Mailing List http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



More information about the websecurity mailing list