Google dumps keys, passwords; secures services with standards, certs

Google dumps keys, passwords; secures services with standards, certs

Summary: Google is improving security for Web applications connecting to its server-based platforms by dropping keys and passwords and turning to certificates and an emerging protocol called OAuth 2.0.

SHARE:
TOPICS: Security, Google
3

Google is throwing away the shared keys and passwords that developers use to access its server platforms in favor of a pioneering combination of open standards and certificates to boost security.

The search giant Wednesday unveiled Service Accounts, which provide certificate-based authentication using an emerging identity standard and a variety of access token types to secure server-to-server communication. The certificates support stronger security when web applications interact with Google services such as Cloud Storage. With certificates, the application requesting data has to validate its identity before accessing an application programming interface (API).

The certificate authentication does not require any end-user interaction.

In a blog post authored by Google product manager Justin Smith, the company said that certificates offer better security because unlike shared keys and passwords they cannot be read or guessed by humans.

Google is the first service provider to implement certificate-based authentication on the back of the emerging OAuth 2.0 protocol, which is nearing final approval as a standard at the Internet Engineering Task Force (IETF).

The flow of information to obtain and validate the certificate and its payload uses JavaScript Object Notation Web tokens (JWT), which are exchanged for OAuth 2.0 access tokens on Google's site.  JavaScript Object Notation (JSON) is a lightweight data-interchange format.

"The benefits are fewer passwords, stronger authentication, better security, interoperability, and choice of vendors," said Brian Campbell, a co-author of the IETF draft specification the outlines how a JWT token requests an OAuth 2.0 token. (Disclosure: Campbell is a senior architect for my employer - Ping Identity.)

Google's move to certificate-based authentication shows how OAuth can be integrated with PKI and existing corporate certificate tools. The design also supports asymmetrical crypto so Google never has a copy of a company's private key.

Campbell and other experts contend that Google's implementation shows that OAuth 2.0 is an enterprise-ready security standard, and given the fact it does not specify token types provides corporate IT with quicker implementations and more flexible integration options.

Google's Service Accounts capabilities are initially being added to a host of its developer services, including Google Prediction API, Google URL Shortener, Google OAuth 2.0 Authorization Server, Google APIs Console, and Google APIs Client Libraries for Python, Java, and PHP.

Google will make integration easy for developers by offering a few lines of code that can be dropped into applications. Service Accounts supports Google APIs Client Libraries for Python, Java and PHP. The company plans to add Ruby and .NET support at a later date.

Integrating authentication technologies into applications can prove tricky and expose vulnerabilities as highlighted in a recent technical paper released by Microsoft Research. The paper showed API integration based on poor code written by web site developers led to fatal security flaws in Web-based SSO.

To wit, Google is strongly advising developers not to write their own logic for creating and cryptographically signing the JWT access tokens used with the OAuth 2.0 specification. Google suggests using libraries instead.

"Writing the code that abstracts token creation and signing is prone to errors that can have a severe impact on the security of your application," Google said in its Service Accounts documentation.

Topics: Security, Google

About

John Fontana is a journalist focusing in identity, privacy and security issues. Currently, he is the Identity Evangelist for cloud identity security vendor Ping Identity, where he blogs about relevant issues related to digital identity.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • Fuzzy terms here

    Oauth involves key exchanges between trusted providers. So, to say that they "dumped" keys is a bit misleading as key exchange is a mandatory component of Oauth.

    Nor is Google the first service provider to implement Oauth 2.0. It's been an evolving standard for quite some time with any number of service providers.

    But, otherwise -- great article.
    Your Non Advocate
  • Passwords are evil.

    I usually don't say it too much, but good job Google. I've been following OAuth for the past few months and do believe it is better to go with identity based authentication over passwords. This technology will probably emerge as 'the' alternative (and soon to be favored) method for authenticating in the future.

    MS has added support into their frameworks for it in the past year, I wonder if Apple has even considered this yet.

    Now I just need to get over the fear of never knowing my passwords and get something like a YubiKey for my personal accounts.
    dtdono0
    • That's all fine ..

      .. 'n dandy.

      [i]" ... I've been following OAuth for the past few months and do believe it is better to go with identity based authentication over passwords. "[/i]

      As great a security transition as this move appears (on the surface) to be, it's also an 'all the eggs in one basket' type solution. Need we be reminded of how RSA was breached and *anything* could have eventuated from that scenario which could easily have derailed a seemingly rock solid move like this and render it's defenses toothless.

      [i]" ... Google???s move to certificate-based authentication shows how OAuth can be integrated with PKI and existing corporate certificate tools. The design also supports asymmetrical crypto so Google never has a copy of a company???s private key. "[/i]

      ... and there it is right there: we're effectively on the clock already. Inevitably, anything related to PKI obviously shares the inherent pitfalls (esp. loopholes and back-door vulnerabilities) that have clearly been discovered by the black-hat community to date in the shared-key, PKI and ultimately the entire certification authority process.

      Don't get me wrong - this was always a necessary security step for Google (and eventually most/all search providers), it gives a very good platform for secure and ultra-reliable certification and authentication negotiation. But there's the inevitable asterisk placed alongside: as like so many steps made before by many other parties, this move simply puts Google, *temporarily* mind you, a step ahead of the black-hats.
      thx-1138_