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

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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4907
Published: 2014-07-11
Cross-site scripting (XSS) vulnerability in share/pnp/application/views/kohana_error_page.php in PNP4Nagios before 0.6.22 allows remote attackers to inject arbitrary web script or HTML via a parameter that is not properly handled in an error message.

CVE-2014-4908
Published: 2014-07-11
Multiple cross-site scripting (XSS) vulnerabilities in PNP4Nagios through 0.6.22 allow remote attackers to inject arbitrary web script or HTML via the URI used for reaching (1) share/pnp/application/views/kohana_error_page.php or (2) share/pnp/application/views/template.php, leading to improper hand...

CVE-2014-2963
Published: 2014-07-10
Multiple cross-site scripting (XSS) vulnerabilities in group/control_panel/manage in Liferay Portal 6.1.2 CE GA3, 6.1.X EE, and 6.2.X EE allow remote attackers to inject arbitrary web script or HTML via the (1) _2_firstName, (2) _2_lastName, or (3) _2_middleName parameter.

CVE-2014-3310
Published: 2014-07-10
The File Transfer feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center does not verify that a requested file was an offered file, which allows remote attackers to read arbitrary files via a modified request, aka Bug IDs CSCup62442 and CSCup58463.

CVE-2014-3311
Published: 2014-07-10
Heap-based buffer overflow in the file-sharing feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center allows remote attackers to execute arbitrary code via crafted data, aka Bug IDs CSCup62463 and CSCup58467.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.