Could a Decentralized Login Have Prevented @Jack's Hack?

A possible solution to single-factor and multi-factor authentication methodologies using decentralized login (DLI).

Not all hacking involves sophisticated technical hacking skills. Sometimes the easiest way to hack someone is through social hacking. A process through which, hackers socially engineer ways to exploit users into providing them with their account credentials.

Over the past few days, hackers going by the hashtag #ChucklingSquad, have been hacking into popular twitter accounts including Twitter’s CEO, Jack Dorsey, influencers such as Zane Hijazi, Zane and Heath podcast, and Anthony Brown, who goes by BigJigglyPanda and more. They even posted messages mocking popular YouTubers who have passed away.

But how could this happen to one of the world’s leading tech innovators? The fault is not with Twitter per se, nor with its CEO. Really it lies with the mobile telecommunications companies — in this case, AT&T. Hackers find it easier to attack their victims starting with the path of least resistance. In this case, the weak link was AT&T and their process to port over phone numbers to a new SIM card.

The hackers used a technique called a SIM Swap Attack, a well known exploit of the low-security methods telecom companies use for account recovery, done by simply providing the customer support agent with the victim’s date-of-birth and other similar identifiers that are often easily obtainable.

Why is Twitter receiving so much heat over this attack if AT&T allowed the hack to occur? In order to understand why Twitter is to blame for the attacks on their CEO and users, we first must understand the decades of issues engineers have worked tirelessly to solve…

Netscape, the first web browser, was invented in the mid-1990's. It was also the first time we needed encryption, and later a way to send data, ie. credit card information, from one point to another point securely. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols were created to securely handle communications over the public Internet infrastructure.

Secure communication in these protocols is achieved using asymmetric cryptography, commonly explained by the analogy of a padlock (the public key) and the key to unlock it (the private key). In practice these are both long strings of numbers that result from a cryptographic function.

The locks are communicated over the protocol, essentially announcing “messages directed at me can be encrypted using this and only I will be able to read them”. The problem, however, is that humans can’t remember a long string of numbers for every service they want to log in to.

The widely used solution is simple, single-factor authentication. Users create a memorable password upon sign-up to the service, and is used as a seed to generate a lock and key. It is as intuitive as saying the secret code to be let through the door of a private club.

Perhaps passwords are too simple, though. People use passwords they can easily remember, often a combination of some word common to their lives (i.e. favorite holiday, birthday, wedding anniversary, etc.) resulting in guessable passwords like `May041995`.

To make matters worse, laziness often results in the reusing of the same password for many services, exposing all accounts associated with it to each service’s security vulnerabilities.

This brings us to modern attempts to add layers of security. Multi-factor authentication methods such as SMS-based second-factor authentication (SMS 2FA) and software-based second-factor authentication applications (Google Authenticator App, Duo, Authy, etc.) were invented to add a layer of security for the end-user.

Problem solved. Yes? — Well, No. While multi-factor authentication does technically work, it adds a higher barrier to usability that it was generally not adopted. The user experience (UX) was so bad that people do not see using the factor worth their time.

Why is it Twitter’s fault at all?

Authentication is difficult, and because of that, users seldom follow the recommended processes for securing their accounts and/or account credentials. Twitter and many other Web 2.0 applications have been trying to increase security for users.

One attempt to improve security is SMS-based second factor verification. Unlike its close cousin, software-based authenticators, SMS-based second factor authentication is friendlier to users as it allows users to access codes via convenient SMS messages.

The trouble with SMS second factor authentication is that hackers know that they can access user accounts by gaining access to their phone number. Twitter, one of the world’s leading technology’s influencing politics, sports, breaking news, and more, is fully aware of this. They employ some of the world’s top engineers who have not only studied these well-known exploits. Even Twitter’s first engineer, Blaine Cook, was one of the co-author’s of OAuth and was working to solve some of these attack vectors back in 2006.

Where do we go from here and what are some solutions?

Twitter and other app developers can simply remove the feature and no longer offer users the option to use SMS second-factor authentication. But this brings us right back to using only passwords, and with that the plethora of problems they bring.

The decentralized web or Web 3.0 has brought an even more complex security model, forcing us to revisit the authentication process in its entirety. The irrevocable nature of blockchain transactions requires higher security than that which passwords can provide, bringing us back to the problem of managing private keys. Moreover, the decentralized nature of these systems complicates the recovery of lost keys by removing the authority which could previously reset users’ credentials (though, at the benefit of not requiring said authority’s trust).

The biggest hindrance to the growth of Web 3.0 to date is that users have to either remember 24-word mnemonic phrases or write them down in order to recover their account(s) for when they are required. Although this is a much worse user experience, it is in this key recovery process that lays the secret to providing a much better solution to authentication (login).

A decentralized login (DLI) and recovery platform

One of the best login experiences to date is single sign-on (SSO), “Sign in with Facebook, Twitter, Google, etc.” Users do not have to devise passwords, or go through the sign-up process for services. Great experience? Yes. The trouble with SSO with Facebook is that then you’re logging in with Facebook and logging in with Facebook gives them the opportunity to collect your data.

However, these services are still based on passwords, in addition to serving as honeypots for data leaks. Moreover, integration is usually conditioned on data sharing policies, ensuring Facebook, Google, or whoever have access to all of your browsing data from any website implementing SSO.

How do we achieve such an experience using a more secure set of tools? One such way could be a framework for managing these keys in a manner which is seamless to the user and painless for web developers to implement and support. A service that would run locally, rather than on a remote server, protecting from both data leaks and censorship.

Services like SSH have used private keys to authenticate for years, and with the rise of secure enclaves on smartphones we now can leverage them for added security of storage. It can be exposed to websites through a simple API, allowing any web developer to add support for a better authentication scheme.

The real challenge in this proposed framework is recovering lost keys securely. Recovery is hard because you need to allow for a spectrum of use cases and security models. Do users want to go through a complicated KYC verification process to recover their social media credentials? Probably not. Are they willing to go through a comprehensive process to ensure that only they can recover their cryptocurrency keys?

Most likely, yes.

Luckily, markets are very good tools at matching consumers to the service that fits their use case the most. In the context of credential recovery, we want to allow a user the ability to select any provider that fits their needs, and be able to verify with them in order to recover the lost keys. The keys would be shared (but encrypted) on a decentralized network, and users would select the provider whose verification they will use in order to recover. Providers will provide a proof to the network, and the shards would be sent to the user for reconstruction.

There is an open source community called Universe Labs, working on defining and building this decentralized login (DLI) framework and recovery platform. We’d love for folks to join and work together to provide both the Web 2.0 and decentralized Web 3.0 with a much better, more secure method of authentication and identity.

Comments? Tweet them @guylepage3, @itamarreif or @gadikian .