Tale of two breaches shows passwords not the real problem

So it's not the password that's the problem, it's really the breach.

It is far less painful to remember or reuse passwords than to have yours stolen from the service entrusted to protect it.

Having users create and store passwords at every site is the security crack in the Internet model, not the digital relic that is the password. Should we kill the messenger (passwords) or fix the process?

Users don't want new complicated authentication flow instructions to ponder; they want shopping sites, social media, online apps, and to dodge password-breach bullets while moving forward like nothing happened.

This week, that scenario didn't play out when hackers struck the MacRumors Forum, and made off with 860,000 passwords and other personal data. But in another breach involving the online service Buffer, users walked away with only scratches.

"In situations like this, it's best to assume that your MacRumors Forum username, email address and (hashed) password is now known, " wrote Arnold Kim on the Forum site. His advice was all to familiar: change your password; if you reuse that password on other sites, change it there also; and craft "secure" passwords from the get go.

The MacRumors episode follows a similar breach in July of the Ubuntu Forum, where nearly 2 million passwords were hacked, and an October incident where Adobe lost some estimated 150 million encrypted passwords to thieves.

The question is can the fallout from these episodes be lessened? Eliminated is much too strong a word given the current data security climate.

There is a recent episode that hints at a better world, where access can be centrally shut down, and doesn't require users to hunt down and eliminate their reused passwords while fearing spin-off attacks.

When the online service Buffer, which is used to schedule social media posts, had its database hacked late last month it stemmed the bleeding by revoking tokens hackers had stolen and used to access Facebook and Twitter and post messages on behalf of Buffer's users.

Those tokens were based on OAuth, an authentication/authorization framework that is emerging as a valuable mobile and Web building block for identity and security geeks but garners blank stares from social media addicts.

Unless, of course, those addicts understood that the Buffer revocation was actualy a protective shield around their diigtal world.

Buffer sits between the user and a social network and passes authentication tokens via Application Programming Interfaces (APIs). When hackers snatched Buffer OAuth tokens it was open season for them as evidenced by their activity on Facebook and Twitter.

Buffer did make mistakes along the way with its security and token storage, which were detailed by ProgrammableWeb and OAuth expert John Bradley. And to be fair, OAuth itself is undergoing some upgrades and revisions. But one thing did go right.

Buffer ended the carnage and saved users without having to recommend they change their password everywhere it was reused or offer free fraud service.  

Users only needed to re-authenticate to Facebook and Twitter to create a new token.

While Buffer doesn't prevent Twitter and Facebook users from losing their passwords via a hack on those specific networks, the third-party authentication OAuth model shows the solution end-users really want in case of emergency.

No tedious remediation, no new and mysterious log-in patterns to learn, no complex authentication flows they can't remember how to execute, but instead a corrective system that minimizes their exposure and gets them back to baseline in a way that follows their normal course of behavior.

Of course, the lesson to hackers is that their payday is not in tokens but in passwords.

I'm not suggesting OAuth is a panacea for password hacks, and it has its own specific use cases, but its model hints at satisfying two constituencies with one action — providing shutdown capabilities desired by administrators and companies in crisis, and giving end-users protections that require little effort on their part during and after the fact.

(Disclosure: I work for the same employer as John Bradley)