Privacy-Preserving Social Login with Hypersign

Demo

Feel free to watch the demo before proceeding…

Introduction

Social logins such as Facebook, Google which are common Single Sign-On (SSO) mechanisms for authentication in websites (also called service providers) these days, help service providers to quickly onboard an user without demanding them to go through the registration process. Through this process, on one hand, the service providers can provide seamless onboarding to their user and on the other hand, there is no requirement for the user to type his details for instance name, email, phone number, every time he avails a service from a new provider. Along with this the user does not have to remember multiple usernames and passwords for each of these service providers, just one for social login. With this kind of mechanism the service provider gets access to user data directly from the social login provider (also called identity provider i.e. IDP) to build a user profile in their portal.

Apart from these above mentioned provisions, there are two major problems which can be traced in the social login authentication flow. Most of the social logins providers such as Facebook, Google etc still rely on password-based authentication which gives rise to the prolonged known issues or problems with passwords such as password resetting, password hacks, password forgetting etc.

Along with this the other issue is that the identity provider stores data of millions of users which can become a honeypot for many hackers. The identity provider also has the ability to misuse the userdata without users’ consent in many different ways starting from analytics or by selling them to the third party etc. The case of Facebook and Cambridge Analytica is not hidden from anyone where millions of Facebook users’ data was acquired without the individuals’ consent by Cambridge Analytica, predominantly to be used for political advertising.

This whole scenario brings about the immediate pondering about the kind of impact it can have on each and everyone’s life, it does not just affect a service provider but can even participate in the decision to choose the government. This is a serious problem for the users who are really concerned about their data privacy and protection as they have to fully trust these IDPs on how they store and manage their data.

To add on to these innumerable troubles, the social login providers can track, what and all other things a user is doing;

Facebook would know if you are traveling using MakeMyTrip or buying something from Amazon!

and that becomes another privacy concern for the user.

Why Social login not being used in enterprises?

The social login is not being used in serious enterprises since it does not tell the one who is using the credential (i.e. username and password) possesses it, as the credential can be easily shared with peers. This means, it answers the question of What you know? (i.e Proof of Knowledge) but not to What you have? (i.e. Proof of Possession) or Who you are? (i.e. Proof of characteristics). Additionally, service providers still have to add another layer of authentication based on One Time Password (OTP) apart from usernames and passwords for better security. But again OTP itself deals with its own set of problems which will be discussed in detail in some upcoming blog posts. Also, not to mention it adds up the cost and complexity of the IAM system.

Overloading social login provider with a lot of authentication requests

Lastly, the IDP system can be flooded with a huge number of verification requests since social logins are used in most consumer-facing applications which usually have a large customer base. Now, any of the problems related to authentication in social logins costs the service providers a user loss and hence loss in business. A user might not be able to use the service if he/she is not able to authenticate himself/herself to the IDP. Think, you have an e-commerce site where a user wants to log in to buy a product during festive sales. Due to some reason (say outage or any other verification problem) if the user is not able to log in, how much can it impact the user experience and hence the business?

Problem Statement

To summarize there are two sides of it:

End-user perspective

• Control: The end-user does not have control of his data. Although usernames and passwords are given, the actual data reside with IDP which gives them the ability to misuse.
• Consent: These IDPs often do not take the consent of the user before sharing their data. i.e. case of Cambridge analytica.
• Tracking: IDP can even track where and what user is doing.

Service provider perspective:

• High trust: The provider has to trust IDP how they store and manage their users’ data.
• Too much dependency: The provider has to be dependent on the IDP as it needs to be online when a user is trying to access the provider’s system.

There has to be an end to these kinds of ongoing problems where these entities do not value the privacy and protection of user data. Having said that, not all identity providers are evil, they ask for user’s information so that a user can avail seamless user experience, for instance, no registration required every time a user accesses a new application.

It is not that we can remove the IDP completely (that’s what we had right? when we did not have SSO). The role of IPDs are crucial since they verify data and as a result, the service provider gets pre-verified data hence both SP and user need not to go through the verification process again. But the question is:

“Is it reasonable to think about a solution where IDP do not hold any user-data (hence acts like a stateless server) but the service provider (or relying party) gets verified data directly from end-user?”

Hypersign

Though the above question does not seem to be realistic but just for the sake of conversation, imagine if that be the case then what would happen?

• The Identity provider would not have to store any data, meaning no fear of data breaches. It verifies user data (upon request from user) and gives him some kind of document which might contains the proof of verification (think of signature)
• The end user always gets to control his or her data and he or she decides how, where, with whom and to what extent he or she needs to share his/her data.
• The service provider gets the verified data thus it needs not to verify the user data again, maybe it can just verify the fact that this data was issued by the right issuer and to the right owner.

Hypersign is a privacy-preserving authentication protocol for an enterprise. It leverages technologies like PKI and blockchain to provide end-users with the ability to control their data and the service providers the ability to verify credentials without making a request to the identity provider. Furthermore, the Hypersign can easily be integrated with existing IAM systems like Okta, Auth0, and Keycloak to provide passwordless authentication.

The Hypersign protocol works on the concept of the Issuance-verification paradigm which can fit into many different use cases.

Most of the concepts are self-explanatory in the above figure. Notice, the user directly shares his data (step 5) with the service providers, from the user-agent (such as mobile device), as opposed to the legacy system where IDP used to share that. This gives full control to the user about his or her data. Moreover, this data is verified by IDP (step 2) hence the provider can trust the data as long as he trusts the provider. Finally, data is cryptographically signed not just by the issuer but also by the user (steps 2 and 4) which gives guarantee about the data authenticity and integrity to the provider.

Superhero.com implements Hypersign

Although Hypersign comes with its own mobile authenticator app, we wanted to prove that how easily the protocol can be implemented with existing solutions so that they can leverage the benefits of the Hypersign protocol in their ecosystem without making much changes. Hence, we integrated with Superhero.

What is superhero.com?

Superhero mobile wallet

Superhero is a decentralized social networking web application built on top of AeTernity blockchain. In Superhero, a user can make posts and curate others’ posts if they like using cryptocurrency. Think of Facebook on the blockchain with a tipping feature instead of likes. Because Superhero is a decentralized application, it comes with a Superhero mobile wallet where an end-user can store their private key to use it to sign transactions on the blockchain when they curate any content. See the above figure.

Architecture

Here,

• Superhero server becomes IDP which verifies user data and issues SuperheroAuthCredential.
• Superhero mobile wallet becomes a user-agent which holds SuperheroAuthCredential.
• Website1 and Website2 are service providers who verify credentials.

Superhero Auth Credential architecture

Let us understand the above architecture with the user journey below.

User journey

• Once Hypersign is integrated, two new features get added to the Superhero wallet, profile, and credentials. A user downloads the wallet and enters his details on the profile page. The user data goes to the Superhero server.

HOME PAGE

PROFILE PAGE

• The Superhero server verifies the user-data, say by sending an email or sending OTP on phone depending on what data needed to be verified. In this step, the Superhero server acts as a stateless server — meaning it does not store the user data. Based on this data, the Superhero server issues a cryptographically signed document (called SuperheroAuthCredential) to the user via email.
• The end-user downloads SuperheroAuthCredential from his email into the mobile app by scanning a QR code. Further, the end-user can view the credential detail in the app itself.

CREDENTIAL LIST PAGE

CREDENTIAL DETAIL PAGE

Now, whenever the end-user wants to authenticate himself into a website, he can use this credential to be able to login into the website using a QR code scanning mechanism. He can further use the same and different credentials to login into more than one website hence using an SSO environment. Take a look at the figure below.

BEFORE LOGIN

AFTER LOGIN

Key differentiator

Conclusion

• We eliminated passwords, so no password related problems at all.
• Users now being able to share the verified data directly with the service provider. Hence privacy is protected.
• The IDPs verifies user data and provide credentials without storing any user information hence data is protected as the IDP system can not become a honey pot for hackers.
• The user still be able to log in even though the IDP system is down or not working as the issuer can verify the issued credentials on its own hence the system is scalable.
• No multi-factor authentication complexity is required because the private key in a wallet does answers the question of What I have?. Further, if biometric is implemented in the mobile app then it also answers the question Who I am?. Hence the system is secured.
• Finally, a user feels confident in using the authentication mechanism, hence the system is trustworthy.

— — — — — -

Follow us

Telegram: https://t.me/hypersignchain
Twitter: https://twitter.com/hypersignchain

— — — — — — — — — — — — — — — — — — — — — — — — — —

Hypersign is a product of Hypermine Labs

About Hypermine:
Hypermine is an avant-garde technology and research organization that is dedicated to building trust and transparency in the real world.

Using ‘Distributed Ledgers’ as our core technology coupled with ‘Machine Learning’, we are creating digital economies to create a new world for enterprise, government, and consumers.

Our vision is to create a world where privacy is a fundamental right, where our data is secure and belongs to us. A global currency that has real value; where piracy does not exist and freedom of expression is encouraged. Where wealth is shared to reduce poverty and all governance is transparent and trusted to make life better for everyone.

This document is copyright and belongs to Hypermine ©, 2020.
All Rights Reserved.

— — — — — — — — — — — — — — — — — — — — — — — — — —

#authentication #verification #digitalsignature #authorization #decentralization #rsa #encryption #blockchain #bitcoin #cryptocurrency #crypto #btc #ethereum #defi #crossfi #bitcoinmining #money #trading #business #bitcoinnews #bitcoins #investment #cryptocurrencies #coinbase #blockchaintechnology #litecoin #entrepreneur #forextrader #cryptonews #cryptotrading #eth #bitcoincash #invest #binaryoptions #investing #trader #binance #bhfyp #identity #digitalidentity #securitycamera #programming #seguridad #military #it #cctvcamera #alarm #cybercrime #love #camera #iot #ethicalhacking #secure #instagood #safe #sicurezza #safetyfirst #closeprotection #hackers #userdataprotection #dataprotection #securityservices #a #network #innovation #software #tactical #networking #privatesecurity #selfdefense #coding