Wednesday, October 08, 2014

Social Media 2 Factor authentication


Premise

A user can authenticate to a web application (or a federation server) by sending an update (tweet, Facebook update, etc) with a randomly generated hashtag previously delivered to the user in the login interface. 

The fundamental requirement is that 

  1. the user be able to demonstrate ownership of the social account previously connected to their account at the authentication server by including a challenge string in a tweet, update etc
  2. the authentication server be able to determine that a particular challenge string was added to a tweet, update etc associated with a particular social account 

User Experience


Step 1 :


User binds their social account to the authentication server

Screen Shot 2014-05-22 at 3.12.58 PM.png

Alternatively, the ‘binding’ could consist solely of the user telling the authentication server their Twitter handle.

Step 2:


Later, User visits login page

User logs in with first factor, ie password, or SSO

Login UI displays randomly generated challenge string
Screen Shot 2014-05-22 at 3.33.01 PM.png

Authentication server stores away challenge string against that user’s account

Alternatively, the challenge mechanism could be via Twitter, ie the authentication server sends the user a tweet, and the User response would be a RT.

Step 3:


User sends tweet , including challenge hashtag from Step 2

Screen Shot 2014-05-22 at 3.35.27 PM.png

The response format & channel will depend on the nature of the challenge and how the user’s social media account were bound to the account at the authentication server.

Step 4:

After displaying the hashtag challenge to the user , the authentication server polls the user’s tweet stream (or equivalent) on some schedule for a tweet (or post) containing the challenge hashtag.

If such a tweet is found within some time period, the authentication page displays successful login.

Discussion


  1. The default would be for the user to manually type the challenge string into their tweet. Might it be possible for the authentication server to instead/also display a QR code, for the user to scan and so launch their mobile Twitter client with the tweet ready to send?
  2. Instead of a string, the challenge could consist of a link to a specific picture or some other media
  3. If the user has previously authorized other applications to be able to send tweets on their behalf, then those other applications would potentially be able to send a response tweet, but only if they were able to know the challenge. Consequently, the authentication model is likely only relevant for a 2nd factor, as having the user first authenticated with the other factor would prevent other applications from knowing the challenge string.
  4. if the authentication server were able to determine how many applications the user has granted the ability to tweet on their behalf, then conceivably it could factor that into it’s assessment of assurance
  5. There could be a viral component to the marketing of the authentication service, as the user’s followers would see the authentication tweets
  6. Is there a risk of violating Twitter ToS?

No comments: