Shared Responsibility of Security Controls: Battling Account Takeovers Together
In our hyperconnected world, online services are woven into the tapestry of our daily lives. But with great convenience comes great assumed responsibility, especially when we need to safeguard ourselves from cyber threats. Aside from data privacy concerns one of the most pervasive dangers lurks in the shadows: Account Takeovers (ATOs). From a provider perspective these are considered business logic flaws and exploits of vulnerabilities. From a user perspective this is unauthorized access and the perpetration of malicious acts. While providers must constantly mend the fabric of their systems, users hold the needle and thread, empowered to stitch together a robust defense through informed choices and vigilant practices.
Imagine waking up to find your financial account drained, your connected car stolen, a health care portal with incorrect medical guidance and wrong prescriptions, or your email and social media flooded with spam, or spewing malicious content — all because someone else has taken control. ATOs are a harsh reality, and combating them requires a Shared Responsibility between providers and users. These chilling scenarios are not the stuff of dystopian fiction, but a present danger demanding immediate action. Like threads left frayed, neglecting our shared duty weakens the fabric and tangles it in cyber crime. Providers must build upon their defenses, but users must acknowledge that they are solely responsible for password hygiene and re-use of online identities, controlling the use of their authentication mechanisms, and informing providers of unusual activity.
This concept of shared responsibility is not new to those in the information technology domain, I would say that it has been most recently popularized by the Cloud Security Alliance’s shared responsibility model for data security strategy, and brought to market by Amazon, Google, and Microsoft in various forms. However, I would argue that this concept transcends mere cloud computing. Shared responsibility applies to any online service where two parties — the provider and the customer — share the burden of security. Let’s delve into how this plays out in the battle against ATOs, using two insightful examples as battle cries.
Example 1: Passwords, Password Managers, and Passkeys — A Shared Battleground
Passwords are the first line of defense, and considered a weakness if they lack complexity or confidentiality. Providers have a responsibility to ensure secure password storage and hashing, but relying solely on their measures is akin to building a sandcastle against a hurricane. Users must choose strong, unique passwords, avoid reuse across platforms, and resist the temptation to share them with anyone, even for seemingly “legitimate” reasons.
Presently we rely on User Agreements to delineate the responsibilities of the customers, with phrases such as…
By accessing and utilizing this platform, you hereby acknowledge that the selection of your User Account credentials and any other necessary authentication methods, when applicable, is your sole responsibility. It is required that you maintain the confidentiality of your User Account credentials, API keys, and any other requisite authentication forms. You must ensure their segregation from each other and from any additional information, software code, or documents associated with your User Account.
Yet if we’re being honest with ourselves as providers an average user would not review and comprehend their responsibilities. And most likely this wouldn’t settle in until it’s too late from a security perspective. These statements are not mere legalese; they outline the shared responsibility pact. Providers offer the tools, but users must wield them wisely.
As a user, If you choose to install and use a second factor authentication (2FA) application, password manager, or use a passkey on a device, you are in fact choosing a security mechanism in which YOU control rather than the provider. Most providers do not receive, collect or store any users biometric passkey data in an abundance of caution for privacy. In the case where a password is used the plaintext or hashed version of a password may not be in third party breach notifications or malware intelligence sources for the provider to prevent re-use in their product or service.
Outside of agreements, disclosures, contracts, and theoretical practices the actual functions and mechanisms of what we previously considered a password are changing. This is not a doomsday scenario but rather a sign of progress in terms of security for all. However, with security for all comes responsibility for all, meaning all providers and all users.
Example 2: SMS Text Message 2FA — A Double-Edged Sword
SMS 2FA or text message 2FA, while convenient, has inherent vulnerabilities which have been exposed in many blog articles and presentations prior to this. Providers offer it for its accessibility, but users must understand its limitations. SIM swapping, hacking, and lost devices can compromise SMS codes. While SMS is more secure than passwords alone, there are important technical caveats that go over a general user’s head.
The seemingly secure fortress of SMS 2FA crumbles under closer inspection. Like a whisper spoken in a crowded public setting, SMS codes can be intercepted through a careful nefarious actor. SIM swapping, a devious ploy where bad actors waltz your number onto their phone using stolen personal data, grants them access to your digital keys. From here, cunning hackers can exploit vulnerabilities into the mobile operating system for further access and persistence.
Additionally, there is often the false comfort of lost devices with cloud synchronization providing a sense of security. A misplaced phone becomes a Trojan horse, offering a gateway to a provider’s online portal, user’s online accounts, and the fabric to our entire digital life. So beware, for even the most trusted can be mimicked, your cloud provider can be turned against you, and phishing scams can trick you with a single unsuspecting click. Remember security is not a single thread, but a meticulously woven tapestry where both providers and users must vigilantly mend every potential vulnerability.
So, what’s the shared responsibility here? Providers must offer alternative 2FA methods like authenticator apps or hardware security keys. Users, in turn, should opt for these more robust options and safeguard their devices like precious gems they have become. While we cannot remove SMS 2FA completely as there are distinct and measurable advantages such as operation in low bandwidth environments, and the added element of out of band communications, we can determine when best to use it. The cellular SMS network while interconnected is independent from the TCP/IP internet services your users are interacting with.
Beyond the Examples: Shared Vigilance is Key
The battle against ATOs goes beyond these two specific examples, that’s why I’ve built a 2FA Responsibility Model, outlining the essential roles both providers and users play in combating ATOs. You can explore it in both markdown and csv format here. Join this 2FA discussion! Share the model, spark conversations, and empower others to define their controls and responsibilities. Together, we can turn the tide on ATOs and create a multifactor fabric that is comprehensible for all.
