Endpoint
1/27/2012
02:10 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%
Repost This

The Future of Web Authentication

Many security experts believe the Internet's trust model is broken. Figuring out how to fix it will take time and collaboration

Web authentication protocols took a pounding last year. Problems with the Secure Sockets Layer and Transport Layer Security protocols, which encrypt all sorts of communication among websites, were at the center of several security breaches. Hacks of high-profile certificate authority providers undermined the security of some of the Internet's biggest brands, including Google and Yahoo; new man-in-the-middle attacks hit the Web; and the powerful Beast vulnerability exposed the most commonly used versions of SSL and TLS.

Taken as a whole, it appears the Internet's trust model is broken. However, many security experts aren't ready to scrap SSL. Rather than starting over, they recommend fixing the existing system. It's clear that we need to evolve the way we authenticate on the Web; the question is, how?

"Anything that requires us to migrate the entire Internet to a different protocol isn't going to happen," says Moxie Marlinspike, a noted SSL researcher and co-founder of Whisper Systems, a mobile security software developer that Twitter acquired in November. "Right now, particularly in this space, ideas are easy, but it's getting it done that's the hard part."

How We Got Here

Netscape created SSL in the 1990s as a way to encrypt sensitive information transmitted as part of online transactions--from login credentials to financial transactions. TLS 1.0 came out in 1999 (nearly identical to the then-current SSL version), and new versions have followed. While TLS is the most advanced protocol for authenticating online transactions, common parlance often refers to it as SSL.

Web authentication rests on the integrity of the certificate authorities. CAs check the identities of websites and issue public key infrastructure certificates, which are then used to verify websites' authenticity and enable the transmission of encrypted information between Web browsers and SSL servers.

When a person wants to view or interact with an HTTPS site--a secure site that uses the SSL protocol--the Web browser requests that the Web server identify itself. The server provides a copy of its SSL certificate, and the browser decides if it trusts the certificate and the site before agreeing to exchange encrypted data (see diagram, below).

The weak links in the SSL scheme are that there's no overarching system or authority to rate, rank, or approve CAs, and there are no standards for how certificates are issued. It's up to the browser vendor to decide whether to trust a specific CA, and those vendors haven't been careful enough with those decisions.

HowSSL certificates enable encryption

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Previous
1 of 3
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MS8699
50%
50%
MS8699,
User Rank: Apprentice
1/31/2012 | 12:04:36 PM
re: The Future of Web Authentication
Strong Authentication: Entrust IdentityGuardSingle Sign On (SSO): Entrust GetAccessEncryption & Authentication for Internet Applications: Entrust TruePassWeb Site Authentication: Entrust Advantage SSL Certificates and Entrust Extended Validation SSL Certificates.COMODO SSL certificates E-commerce merchants are going beyond the gold padlock to go green with
Extended Validation SSL certificates, the e-commerce standard for trust
and security. The green browser address bar, exclusive to EV SSL
certificates, assures website visitors that they are transacting on a
highly trusted and secured domain.
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1421
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Craig Knudsen WebCalendar before 1.2.5, 1.2.6, and other versions before 1.2.7 allows remote attackers to inject arbitrary web script or HTML via the Category Name field to category.php.

CVE-2013-2105
Published: 2014-04-22
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on /tmp/browser.html.

CVE-2013-2187
Published: 2014-04-22
Cross-site scripting (XSS) vulnerability in Apache Archiva 1.2 through 1.2.2 and 1.3 before 1.3.8 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, related to the home page.

CVE-2013-4116
Published: 2014-04-22
lib/npm.js in Node Packaged Modules (npm) before 1.3.3 allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names that are created when unpacking archives.

CVE-2013-4472
Published: 2014-04-22
The openTempFile function in goo/gfile.cc in Xpdf and Poppler 0.24.3 and earlier, when running on a system other than Unix, allows local users to overwrite arbitrary files via a symlink attack on temporary files with predictable names.

Best of the Web