A Smarter Approach to Account Security
Fixes Providers Need to Implement for Online Accounts
Introduction
I’m hesitant to use the term “manifesto”, as I don’t think I am qualified to make such as proclamation. I am not formally trained in any aspect of cyber security, but during my thirty plus years in the IT/engineering/data science world, I was able to read and study a substantial amount on the topic.
In terms of the word manifesto, Marc Andreesen recently (2023) published The Techno-Optimist Manifesto, and the Agile Software Development Manifesto is another well-known example I often refer to. The manifesto approach is often a document designed to share beliefs or vision. As a result, I’ll roll with that format for this document.
As mentioned, I’m a big believer in good security practices. I haven’t lost access to any of my key accounts via a phish attempt or whatnot, but I can only imagine the headache and stress this may cause if this did happen to an individual or organization. I imagine a scenario where someone gains access to an email password (let’s say Gmail) – and as a result can take control of other accounts via a password reset. Fortunately, two factor authentication (2FA) is a key solution to this problem. Nevertheless, it makes sense to put all the best practices into play.
But why don’t all organizations offer a multitude of security options, or allow users to configure the security in a manner that works the best for them? The answer would likely be cost of implementation, changes to existing infrastructure, or concerns of support or confusion for those less-security minded.
I believe that there are enough believers out there that would support at least being able to opt-in to advanced security features.
Item #1: 2FA should not be limited to SMS
More specifically, SMS should be avoided altogether if possible. I know of several accounts that limit 2FA authentication exclusively to SMS (text message) verification. On the surface, you may think to yoruself “Well, someone needs to have access to my phone to get these six-digit codes that are needed.” That’s true, but there are two big vulnerabilities here.
SIM Swapping. In short, this is where an attacker uses some form of social engineering to convince your carrier that they are you and need a new SIM for a replacement phone. Perhaps they’ve obtained information about you from one of these well-known data breaches and/or they have harnessed enough information via your public social media profiles. If this attack is successful, your real phone would possibly be removed from service and the attacker would have claim to your phone number (intercepting any texts). This may then allow them to contact your bank or financial institution while impersonating you and validating this identity by intercepting a six-digit pin number that the bank may send to verify who you say you are. A Microsoft Blog has a detailed write up on this type of attack. Carriers have made improvements in preventing this. It is important to have a good understanding of online security and options of your mobile account as well.
SMSC compromise. SMSC (Short Message Service Center) is the infrastructure used to receive and send messages within and between carriers. ZDNET reported on malware designed to attack these SMSCs. Further, Reuters recently reported that some of these foreign hacking campaigns infiltrated deeper than was previously documented. There isn’t much evidence that there were a great number of attacks on individuals; the campaign seemed more focused on corporate or government entities. However, the risk to the general population is still present.
The best option here is app-based authentication, such as Google Authenticator. With this approach, the account provider will generate a shared secret and offer this secret to the user (often in the form of a QR code that can be decoded by Goggle Authenticator). The uses TOTP (Time-based One Time Password) – which generates these temporary codes (generally every 30 seconds).
App-based authentication can also come in the form of biometrics. For example, Microsoft’s authenticator will remotely send a validation request to their authenticator app that you have previously authorized on your device.
The amount of security with app-based authentication is greater and generally removes risks introduced by other attack vectors. The largest risk in the case of app-based password is loss or theft of your mobile device containing the app. In the case of loss, a handful of one-time recovery keys are offered to the user generally during setup (these should be stored in a safe place). In the case of theft, your 2FA app-based authentication will likely be protected by other biometrics installed on the phone. The 2FA shared secrets can generally be removed and regenerated in the case of theft or loss.
You could also argue that a well secured Email account would be a better form of 2FA than SMS, though this may depend on your level of confidence in your email provider’s security.
Finally, for this to work – it’s important that the account provider allows the user to specify what forms of 2FA are used and limit these accordingly. It makes little sense to allow a user to offer multiple forms 2FA to use on a single login screen, as an attacker must only have access to one. The concern from providers here is preventing hassle if users inadvertently lock themselves out from the account. However, I have seen where some accounts basically nag you to provide a phone number for initial validation – and then leave this as the primary method for 2FA. Providers should allow their users to remove SMS validation as one of the methods for account validation.
Google, to their credit, recognizes these concerns on SMS and is phasing this out as an option.
This expectation also goes for financial institutions (or cable companies) that want to send you a six-digit number to verify they are speaking or dealing with you as an identity check. The same vulnerabilities exist. As a result, the same TOTP codes from Google Authenticator should be just as adequate for account validation.
As I state later, it should not be permissible for the same SMS Short Code identity send you six-digit codes that say “Company X will never ask you for this code” … and then use the same SMS Short Code texting number for in-person/phone validation and not expect your users to be confused. I’ve even had conversations with reps from the companies that do this that explain how much more difficult their daily work is because of this confusing messaging to customers.
To be fair, these companies that do this are trying to provide more security for you. Part of this is that they too realize that too many companies have fallen victim to various data breaches and need some other mechanism than “last four digits of SSN” to verify identity. Using SSN to link to credit reports and other financial information in the United States was a huge mistake that led to much of this hassle. This entire system needs to be massively re-engineered.
Item #2: Let me use my static home IP / geolocation to my advantage
Many account providers may hesitate to rely on a specific IP address for authentication. However, I’m not suggesting that IP alone should dictate security—I’m advocating for it to be a factor in determining whether a login attempt, or account change is valid.
For home-based users, not everyone has a static IP. But for those who do, it should be possible to mark that IP as a “familiar location” within their account settings. Apple’s Stolen Device Protection is a great example of how this can be handled effectively. Even if a static IP changes, users should still be able to access their account, perhaps with a time delay on critical account modifications as an added security measure.
In the case where a specific IP Address isn’t an option, general geolocation should be offered as well. If 99% of my logins happen from my home state, I don’t mind being inconvenienced that 1% of the time I travel. The system should again let me log in but only make major account changes after a specified time duration.
I don’t understand why more vendors don’t offer this level of protection. Microsoft’s security dashboard shows where login attempts (failed or successful) originate. After a data breach, I observed multiple brute-force attacks from international locations. If Microsoft can detect and log these attempts, they should also provide an option to block login attempts from specific regions entirely.
Item #3: Let me manage where I’m logged in
Some services, like Google and Meta, provide visibility into where you're currently logged in. More account providers need to do this.
The best implementations of these interfaces offer a detailed login history, including the time and date of activity, the location (preferably with an IP address), and the device or operating system used. Ideally, they also allow you to log out of any session that seems suspicious or unfamiliar.
This feature is especially useful for removing access from old devices—whether it’s a corporate-issued machine you once used for personal logins or an older device you've since given to a family member or friend. Having the ability to remotely log out ensures that only your trusted devices retain access.
Account providers should retain this information and let users view and manage these sessions to their liking.
At the very least, send users the information by email when a new system is used to access an account. If you provide no means for users to understand where they are logged in, they are not fully enabled to maintain security of their account.
Item #4: Don’t penalize me for someone else’s deeds
A well-known data breach results in personal information being sold on the dark web. Malicious actors then use this information to either guess or directly apply the exposed passwords on various websites. Their strategy hinges on the possibility that you might reuse the same password across multiple accounts—using a low-value account’s credentials to access a higher-value one that might have financial access.
Take my experience with FanDuel as an example. After a data breach, one of my email addresses was exposed. I confirmed this when I noticed a spike in login attempts via Microsoft’s account security pages. Someone was trying to access my FanDuel account using my email. Despite having two-factor authentication enabled, FanDuel’s response was to “freeze my account” and force a password reset via email. (I made sure this wasn’t a phishing attempt by checking directly on the official FanDuel website and app, and others reported similar issues.).
After I unlocked my account with a password change—mind you, my passwords are very strong—FanDuel would lock me out again within 24 to 48 hours. The recurring issue was that my email address remained constant across the password resets. This is a poor security practice because if an attacker knows your email, they can repeatedly submit incorrect passwords to cause lockouts, creating unnecessary hassle for the actual account holder.
To test this, I created a unique email address solely for FanDuel and updated my account preferences after regaining access. Once I did that, the unwanted lockouts ceased.
Ideally, FanDuel should have monitored multiple failed login attempts from the same IP address, a specific range of addresses (CIDR block), or a particular geographic location, and then automatically quarantined that source from future login attempts.
While I’m focusing on FanDuel here, I suspect similar brute-force and dictionary attack strategies are employed against other providers. Fortunately, many seem to have smarter systems in place to detect and mitigate these attacks without inconveniencing their users.
In fact, you could make an argument that forcing a password change could possibly make the account weaker in certain scenarios.
This concept is also relevant to other scenarios, such as when someone mistakenly enters your email address for a "Forgot my password" request. If you have an email address prone to errors or typos, this can occur frequently. While many systems do not necessarily lock your account for such incidents, some still include confusing messages in their correspondence, such as "If you did not make this request, you should immediately change your password". If the email link is required to change the password, my email is secure, and I have 2FA enabled, why is there risk that I should immediately change my password.
Item #5: Audit your systems for clarity, modern standards, and transparency
Account creation should always require email validation, ideally through a six-digit verification code rather than a clickable link. No secondary or marketing emails should be sent until the email address has been verified. This step is especially important when an email address could be mistaken for someone else’s, as failing to validate can create unnecessary confusion and a hassle for everyone involved.
If you’re a legitimate company, design your systems so that users never have to click a link in an email for security-related actions. A password reset or account maintenance process should direct users to a webpage where they are prompted to "Enter the six-digit code we just sent you", pausing until further action is taken. If there’s a security concern with my account, the email should simply instruct me to log into the website or app to view notices—not to click a link. The goal should be to reduce reliance on email links, helping users become less likely to fall for phishing attempts.
In the case of a data breach requiring a password reset, the email should clearly state:
"Upon your next login, we will send you a six-digit code to verify your identity before allowing you to reset your password. You will not be able to proceed until this step is completed."
Lastly, another item of concern I have is being unexpectedly logged out of a persistent session that I had already saved in my browser. The browser plays a role in this, but I’d like to know why I need to log in again. Did my session expire? Was there suspicious activity on another device? The more transparency and information I have, the better I can assess the security of my account and act if needed.
Conclusion
Both the user and the account provider have a role in ensuring security. Many accounts involve direct financial implications for both parties. If providers consider offering these five items as a minimum, their customers will benefit from enhanced security measures.
The individual must also practice good security hygiene. I recommend password managers. However, it’s possible for Google to store both your passwords and your Google Authenticator TOTP shared secrets. If your Google account were to be compromised, an attacker would have access to both pieces of information. As a result, I tend to recommend a password manager that deals only in password management, such as NordPass or 1Password.
Feel free to share any additional thoughts or ideas.