Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

  C O L U M N

In Clients We Trust

July 26, 1999
By BRIAN WALSH

Instead of all their hand-wringing about client security, operators of consumer Web sites should implement support for client certificates, thereby replacing or enhancing the registration process. And instead of waiting for the user to obtain a client certificate, ISPs should just issue one when the user signs up. Client certificates are no less secure than the consumer authentication methods used today. CA (Certificate Authority) and e-business sites should provide incentives for users to obtain stronger certificates as needed.

There. I've solved all the problems of user registration, privacy, cookies and security. All you have to do is execute the plan.

Printer Print this Page
E-Mail E-mail this URL
Related Links
arrow  XML: Revenge of the Nerds,
April 5, 1999

arrow  XML: An API for Every Web Site,
May 3, 1999

arrow  Understanding Internet Payment Protocols,
Workshops, May 3, 1999

arrow  Searching for Online Customer Service,
May 31, 1999

arrow  Microsoft Won't Kill XML,
June 28, 1999


Part of certificate registration is the collection of user information--name, address, organization--that becomes part of the key. The server site reads this certificate and maps it to user-registration information. The certificate is then used to set up the SSL (Secure Sockets Layer) session, in which the server applications can read the client certificate and take action based on user particulars and authorization strength.

Sound easy? It's not. While server certificates are common because SSL insists upon them, client certificates have languished because they're optional. It's shameful how rarely we use client certificates, given that they're standard and browsers have supported them for years. As a result, the user ID process has become convoluted, relying on constant cooperation from users and vigilance from site designers. While consumers can shop anonymously, they often choose--or are convinced via coercion or incentive--to register. We've traded a single dose of complexity during browser setup for a constant stream of user IDs, passwords and cookies.

Enterprises and ISPs typically deal with applications requiring strong authentication, such as storefront administration, by creating "out-of-band" solutions for secure access. This assumes both user population control (by forcing users to employ a particular authentication device) and responsibility for maintaining the secure out-of-band communication. Client certificates are a more elegant solution.

In addition to the standardization of the protocols provided by x.509 and SSL, vendors have offered decent tools at the higher layers. At April's Internet Security Conference in San Jose, Network Computing and CyberSafe cobbled together a demo that illustrated the use of client authentication in an e-commerce application. We used NT, IIS and Intershop to create the prototypical e-commerce site. Our demo aimed to show that strong client-side authentication is secure and reliable for practical enterprisewide deployment. We wanted all "store administrators" to authenticate via a CyberSafe-provided client certificate.

We mapped certificates to users via Microsoft's IIS. Its ASP scripting provides a Request.ClientCertificate object making it easy for any programmer to retrieve information about the certificate. On your (intranet) site, if appropriate, you could map certificates to user accounts and eliminate some coding. Supporting client certificates in your application isn't rocket science and shouldn't take much time or many tools.

Using client certificates requires a few changes in orientation from e-commerce packages. In today's status quo, we've separated user ID and the establishment of a secure communications channel. These two operations belong in one function that should occur when someone enters a site.

Soon, client-side authentication will become as commonplace for e-commerce as server-side authentication is today. And it will succeed for the same reasons server certificates have--standardized implementations and competitive service. But it will fail without the support that accompanied the introduction of SSL for e-commerce. Unless a site insists on client certificates for access, or provides an incentive for presenting one, no one will ever bother with client certificates.

Send your comments on this column to Brian Walsh at bwalsh@nwc.com.



 

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers