Futaba _ Webs 🕸🕸🎃🕸🕸

🎃 Danger! SSO and OpenAuth

Premise 🕸🕸🎃🕸🕸

For the sake of the argument, I will be focusing on the initial main premise of the two, and NOT advanced versions of them which have received some security upgrades for obvious reasons. I want to focus more on talking about the overall design of the two methods and the BIG flaws in them.

This article is a part of the new Danger! Series I’m launching, which is where I raise more Cyber Security awareness about critical flaws and vulnerabilities that exist within various system infrastructures, including any protocols and data communication methods, and the Dangers of what could happen should they be exploited to the fullest extent. I also go over various mitigation strategies that can be used to prevent them as well. If by chance there is an exploit video for me showing the full potential risk, it will be included in the advance version of this article for PAID patreon members only!

As always, any and all advanced versions of this article with a video guide if given will be for PAID patreon members only!!

Accessibility vs Convenience in Cyber Security! 🕸🕸🎃🕸🕸

One of the biggest challenges we face when implementing new security features in an infrastructure is accessibility vs convenience, the overall means to implement a new security method while also making it convenient to use.

Accessibility allows the end user to easily understand and interpret/apply the new approach to security, allowing it to be seamlessly implemented into the security infrastructure in various ways.

This in return would require it to be more convenient in order to make it more accessible to them. Take token based MFA for example. All it is, is a simple pin code that is sent to the end user, so that they can input it into a system and authenticate on top of pre-existing knowledge factors that are set in place by default. For the sake of convenience, we have it set up so that the end user can receive the code in a variety of different ways: mobile SMS messages, email, authenticator apps, etc etc, various means spread out to allow them to use the method, which in the process, also makes it more accessible for them.

Sounds harmless right? WRONG. By making the method more convenient and accessible, we in fact increase the overall attack surface, making it more convenient and accessible for hackers to have options in order to exploit the security method that we’ve introduced. Don’t believe me? Check out my “DANGER!Your Mobile Devices are VULNERABLE!” article to learn about how one of these endpoints allows attackers to easily bypass the security method if needed. This of course, like all forms of MFA, varies depending on the layers that are within it. I’m of course ONLY talking about scenarios that involve the pin code method.

We need to be mindful that when implementing other endpoints for accessibility that can also apply the security method, we need to think several steps ahead, stuff like “is said endpoint secure enough to handle this feature?”, “what would happen in the event that it’s compromised”. We consistently get full of ourselves, thinking that the implementation of the method itself will suffice, that it is impenetrable, yet overlook the stuff like this, weaknesses that can turn it into rumble.

In terms of overall convenience, as harsh as this may sound, sometimes you need to limit how convenient it is to apply the method in order to ensure it's not easily exploitable. This can include from a wide range of stuff like either limiting how the user applies it, or, I some cases, how often the end user is required to use it, which leads into stuff like "Zero-Trust", which is a complex, yet secure form of security for any system infrastructure. I'll talk about that in another article. For now, let's stick to the main topic.

You can still make it more accessible and ensure that end users are able to use and implement it, but not TOO accessible if you see my main point?

Where am I going with this argument? 🕸🕸🎃🕸🕸

Now, how does all of this apply to the topic up for discussion today? Well, believe it or not, SSO and OpenAuth, the main topic for today, as funny but not funny as this might sound, were MADE TO BE MORE CONVENIENT THAN IT IS SECURE. Don't believe me, well let me walk you through the overall concept of how these authentication methods function so that you see the point I’m trying to make.

Now, just to be CLEAR, I am NOT saying that whoever made this form of authentication method had the intention of NOT making it secure. I am simply just pointing out the major weaknesses in them based on how they were originally designed.