The fundamental flaw with Federated Identity and SSO
Single Sign-On (SSO) Technology has gained quite some momentum in the last few years, despite an obvious flaw
Update: As of Feb 14th 2019, nearly two weeks after I wrote this piece, Myki claims to have discovered the same SSO functionality being exploited using even more sophisticated tactic — an imitation ‘lightbox’ or modal-style DOM- popup which is not an actual “window.”
Today almost every website offers a convenient way for the end-users to sign-in with Facebook, Twitter or Google. That’s SSO: using an existing identity to get into multiple services of same or different organizations.
An obvious advantage is the convenience of not having to fill-in sign up forms all over again, verifying emails, and setting up a password (although that largely depends on how SSO has been implemented). The user can simply “login with an existing account” to an entirely new website.
The disadvantage, however is to do with how most SSOs are being implemented today.
Typically, clicking on one of the buttons either launches a “pop up” from the desired login service, or redirects the user there. But, unless the user is vigilant and savvy enough, this same kind of functionality has been abused in phishing attacks!
For example, an unsuspecting user can “trust” and enter their Twitter credentials on a copycat page. But, in case of popups, even savvy users can be fooled. The popup below displays a partial URL with an SSL padlock sign. A lazy user — technologically versed or not, will likely trust the URL, padlock and the page visuals and key in their credentials away. If you are more careful, you will likely expand the popup to reveal whether the address bar contains a legitimate or a copycat domain. In this case the apparent text api.twitter.com could have been:
The biggest risk with the SSO implementations today is a high probability of their abuse by hackers to conduct phishing attacks.
A Better Solution
Better — not as in convenient for the user, but as in more secure; less prone to phishing.
Instead of making the user enter their username and password — credentials for that service, why not ask the user to go directly to that service, and retrieve a “temporary security token” aka one-time password (OTP) ?
This ensures the user actually would have to type, in this case, “twitter.com” into a separate window and log in to retrieve a one-time token from their Twitter account. The user could then copy-and-paste this token back to the service requesting access. The service could then make an API call using this access token to retrieve the user details — at least the very first time. Subsequent logins need remain unchanged: as long as you are logged in to Twitter, the workflow may automatically log you in onto the websites you had signed up for using Twitter earlier.
Of course, a hacker can abuse this functionality too — by pretending they are a legitimate website, but in this case, giving away a “one-time token” to a malicious actor is a better accident than typing away your username and password, which could lead to a total compromise.
Yes, I’m aware the process is not without its flaws and could be a pain in the long run. It is not the most superior solution but provides additional security and deters phishing, compared to the reckless manner in which most SSO workflows have been implemented today.