The National Security Case for Email Plus Addressing

Discussion on X, LinkedIn, lobste.rs and r/netsec.

TL;DR

• OSINT firms and attackers exploit password recovery flows to confirm account existence and leak partial personal data (phone digits, email patterns, etc.).
• Single Sign-On (SSO) services often use the same email address everywhere, making it easier to correlate accounts.
• This becomes a national security issue when adversaries build large-scale dossiers on government and military personnel.
• Simple email “plus addressing” or masked email solutions can help compartmentalize accounts, thwarting large-scale OSINT.
• Websites should standardize their password reset responses and limit info leakage; policymakers and security pros should push for aliasing tools and privacy-first defaults.

Note: Parts of this article were developed with the assistance of AI Deep Research.

Here’s an AI Audio Overview of the blog post (hat tip to NotebookLM):

Imagine a foreign intelligence agent or cybercriminal can find out every online service you use, just by knowing your email address. By exploiting the password recovery features of websites – those “Forgot Password” flows we all rely on – specialized Open Source Intelligence (OSINT) firms and threat actors are quietly mapping users’ online accounts and even extracting snippets of personal data. This isn’t a hypothetical scare story; it’s an everyday reality in the world of digital espionage and cybercrime. And it’s not just a privacy nightmare for individuals – it’s a growing national security concern when adversaries can assemble detailed profiles of government officials, military personnel, and corporate leaders through openly available mechanisms.

In this deep dive, we explore how password reset and single sign-on mechanisms have become an intelligence goldmine for attackers. We’ll see how OSINT companies exploit password recovery flows to infer account existence and grab partial personal identifiers (like phone number fragments and credit card digits). We’ll examine the role of Single Sign-On (SSO) services (like “Sign in with Google”) in inadvertently standardizing our identities across the web, making it easier to track targets. We’ll also uncover some sneaky side-channel leaks that give away even more information to prying eyes. Most importantly, we’ll explain why all of this matters for national security – how hostile nation-states or organized cybercriminals could weaponize this data for phishing, identity theft, social engineering, or large-scale intelligence gathering. Finally, we’ll discuss mitigation strategies: from simple tricks like email “plus addressing” (e.g. [email protected]) to more advanced solutions like masked email services and policy changes that can help harden our authentication systems.

Whether you’re a policymaker crafting cybersecurity regulations or a security professional looking to close an underrated leak, this article will shed light on a silent threat – and how a tweak as small as how we use our email addresses can make a big difference.

How OSINT Firms Exploit Password Recovery Flows

When you click “Forgot password?” on a website, the response you get can tell an attacker a lot more than you’d expect. OSINT investigators routinely abuse password reset flows as an information source. In fact, some commercial OSINT platforms boast the ability to input a single email address and check it against hundreds of sites automatically (Inbox Intel: How to Use Emails for OSINT). If an account exists on, say, a fitness app or a travel site under that email, the tool will find it – and often scrape whatever tidbits the password reset page reveals.

Why are password reset pages so revealing? Consider what happens when you initiate a password reset on a typical site. Often, the site doesn’t outright show the email or phone number on the account (for security), but it does show partial information as a hint. For example, it might say “We’ve sent a verification code to phone number ending in 67” or “An email has been sent to j***@gmail.com*.” These hints are meant to help a legitimate user remember which contact info they used – but they also hand a clever attacker confirmation that an account *does\ exist, plus fragments of sensitive data.

Researchers have demonstrated just how dangerous these fragments can be when combined. In a DEF CON talk, security researcher Martin Vigo showed that different websites reveal different parts of your phone number during password resets (New OSINT technique exploits password reset process to obtain users’ phone numbers | The Daily Swig). eBay might show the first 3 and last 2 digits, PayPal gives the first and last 4, and another site might leak a different combination (New OSINT technique exploits password reset process to obtain users’ phone numbers | The Daily Swig). An attacker who runs your email through a gauntlet of sites could piece together nearly your entire phone number from these overlapping snippets. Vigo noted that by using multiple password reset forms, an attacker could reduce the uncertainty of guessing a phone number from “one billion possibilities to one thousand” (New OSINT technique exploits password reset process to obtain users’ phone numbers | The Daily Swig) – effectively mapping out a target’s full number with a bit of smart jigsaw work.

It’s not only phone numbers. Some password recovery flows will hint at email addresses or usernames, show profile names, or even reveal partial credit card digits if a credit card is on file as a recovery option. In one infamous case, hackers exploited account recovery procedures at Amazon and Apple: Amazon’s customer support revealed the last four digits of a credit card, which Apple accepted as proof of identity to reset an AppleID. The same four digits that Amazon considered too trivial to hide were considered secure verification by Apple, creating an unintended backdoor into a journalist’s Apple iCloud account (Mat Honan: How Apple and Amazon Security Flaws Led to My Epic Hacking - MacStories). This chain-reaction attack (known from Wired journalist Mat Honan’s 2012 hack) illustrates how partial info leaks can be combined across services to compromise accounts (Mat Honan: How Apple and Amazon Security Flaws Led to My Epic Hacking - MacStories). While that attack involved social engineering customer support, the principle is the same for automated OSINT: bits of personal data exposed in one context can be the key to unlock another.

Specialized OSINT companies have weaponized these password reset quirks. They maintain large databases of websites and their account-recovery behaviors, and they run targeted queries en masse. For instance, the OSINT firm “OSINT Industries” describes how their platform can verify if an email is registered on popular services via password resets, often revealing associated usernames or partial phone numbers without ever logging in (Inbox Intel: How to Use Emails for OSINT) (Inbox Intel: How to Use Emails for OSINT). Their tool will, behind the scenes, go to Facebook, Twitter, Instagram, and hundreds of other platforms, enter the email in “Forgot Password,” and record the response. If Twitter’s reset page returns a masked email like j*****[email protected] and says a code was sent to phone **67, the OSINT analyst learns two valuable facts: the person has a Gmail address starting with “j” and ending with “5”, and a phone number ending in 67. They can then pivot – perhaps trying that Gmail address on Google’s own account recovery to see if it asks for a phone number ending in 67, confirming it’s the same person. This technique was documented step-by-step by one OSINT enthusiast who managed to enumerate a target’s Gmail address by stitching together clues from a Facebook reset (which showed an obfuscated Gmail) and a Google reset page (Using Password Resets for OSINT) (Using Password Resets for OSINT).

Not all websites are leaky in the same way. Interestingly, some sites’ password reset forms are more “chatty” than others about user details. A mini-study posted on Exploits.run noted that Microsoft’s password reset will display a phone number with only the last 2 digits revealed, while Pinterest’s will show a partially redacted email _and even the user’s public profile name** (Using Password Resets for OSINT). Twitter will show a partially masked email (with an accurate mask length matching the email length), whereas Instagram and LinkedIn won’t show anything useful (they directly send a reset email, tipping off the user) (Using Password Resets for OSINT) (Using Password Resets for OSINT). This lack of standardization is exactly what makes the attack surface so broad – an OSINT attacker can simply gravitate toward the services that give the most revealing responses. As one security article put it, there is a _“lack of standardization in handling private info”* in these flows, creating a security chasm that attackers can exploit (New OSINT technique exploits password reset process to obtain users’ phone numbers | The Daily Swig). In short, the password reset feature – intended to help users – has become a quiet informer, spilling secrets about which online accounts you hold and pieces of your personal data.

The Role of Single Sign-On in Privacy Erosion

The proliferation of Single Sign-On (SSO) options (like “Sign in with Google”, Facebook, or Apple) was supposed to make our lives easier and more secure by reducing password reuse. However, SSO has a side effect that plays straight into the hands of adversaries: it encourages us to use one centralized identity (often our primary email address) across many sites. If you always click “Sign in with Google,” you’re always using the same Google account email on each service – and that consistency makes it much easier for someone tracking you to connect the dots between different accounts.

Think about it: when you use Google to log into, say, a discussion forum or a shopping site, that site typically gets access to your Google profile basics – your verified email, maybe your name (Getting profile information | Authentication - Google Developers). It always sees the same email address because Google doesn’t generate site-specific aliases in that process. Now, if any of those third-party sites suffers a data breach or carelessly exposes your email, an attacker can take that email and immediately know it’s the key to all the other services where you used Google SSO. In other words, SSO can become a single point of correlation. From a privacy perspective, using a single email everywhere (which SSO by design does) creates the ultimate breadcrumb trail for OSINT.

Furthermore, some SSO providers themselves have experienced information leaks that bolster OSINT efforts. A notable example: a security researcher found that Google’s account login page had an unauthenticated API that would reveal alternate email addresses associated with an account ( Google Leaks Your Alternate Email Addresses to Unauthenticated Users · Embrace The Red ) ( Google Leaks Your Alternate Email Addresses to Unauthenticated Users · Embrace The Red ). By sending a query with a target’s Gmail address, an attacker could retrieve that user’s recovery email (often a secondary address or an old email) without logging in. Google ultimately decided this was “not an issue worth fixing” ( Google Leaks Your Alternate Email Addresses to Unauthenticated Users · Embrace The Red ) – meaning this side-channel remained open for abuse. The implication is that an OSINT agent with someone’s primary email could quietly discover their secondary emails or accounts, which might in turn be used to find accounts on other platforms. It’s another example of how a unified identity (the Google account) can radiate information through indirect channels.

It’s not all bad news, though. There are emerging SSO models that aim to minimize the cross-site correlation. Apple’s “Sign in with Apple” is a compelling counter-example focused on privacy. Whenever you use Apple SSO, you have the option to “Hide My Email,” which generates a unique random email address just for that app or website (How to use Hide My Email with Sign in with Apple - Apple Support). Mail sent to this address forwards to your real email, but the app never sees your actual address. Only Apple (as the intermediary) knows the mapping, and Apple asserts that it doesn’t scan or store the content of emails in this relay (How to use Hide My Email with Sign in with Apple - Apple Support). In practice, this means if you use “Sign in with Apple” on, say, Example.com, they might see an identifier like [email protected] instead of [email protected]. If Jane uses a different relay address for each site, those sites can’t as easily determine that it’s the same Jane behind them. More importantly, if one relay address leaks or is checked by an OSINT operative, it won’t directly reveal all the other places Jane has accounts – each one has a distinct identifier. Apple’s approach shows that SSO doesn’t have to mean using the same email everywhere – it’s possible to have the convenience of single sign-on while still protecting identity siloing. Unfortunately, outside the Apple ecosystem, such aliasing features are not common. Google and Facebook logins still use a single email identity, so unless you take extra steps yourself, you’re leaving a consistent trail.

In summary, Single Sign-On services, while great for reducing password headaches, often trade away a chunk of privacy. They tether your accounts together via one email, making OSINT correlation much easier. A diligent adversary who learns your primary email (from a breach, a leak, or even a guess) can assume that email is your username everywhere – and then leverage password reset flows or other tricks on those sites to gather more intel. Until mainstream SSO providers offer aliasing or better privacy options, users may need to create their own segmentation (through multiple emails or plus-addressing) to break the linkability that SSO inadvertently encourages.

Side-Channel Attacks and Information Leaks

Beyond the obvious password reset pages, attackers have a toolkit of side-channel methods to ferret out account information. “Side-channel” in this context means obtaining data indirectly – not through an official profile or leak, but via some quirky behavior of a system that wasn’t meant to divulge information. We already saw a side-channel with Google’s alternate email leak. Here are a few other ways OSINT practitioners and malicious actors can gather intel beyond the standard password reset:

• Account Enumeration via Error Messages: Many websites inadvertently allow attackers to test whether a user account exists by comparing error messages or response times. For example, a login page might say “Invalid password” when a correct username is entered but “Username not found” when the username doesn’t exist. A “Forgot username” or registration form might outright say an email is already registered (confirming a user’s presence). These differences, however subtle, let an attacker enumerate valid accounts. Security professionals consider this a design flaw – best practice is to keep responses uniform so as not to give attackers an enumeration vector (Remediating Account Enumeration Vulnerabilities - Raxis) (Account Enumeration How To Harden Your SSO Solution). Yet, in the wild, many sites still have this weakness. To an OSINT agent, a list of emails and a site with such responses is all that’s needed to start mapping out who has an account there.
• Timing and CAPTCHA Bypasses: Even when sites try to be coy (for instance, always saying “If an account exists, we’ve sent an email”), attackers might use timing differences (how long the request takes, or subtle differences in behavior) to infer a true/false behind the scenes. In some cases, sites implement CAPTCHAs or rate limiting on password reset to deter mass querying – but dedicated attackers can distribute queries over time or use bot networks to avoid detection. These aren’t so much leaks as they are brute-force recon, yet they qualify as side-channel when the service doesn’t explicitly confirm anything, but patterns still emerge that betray information. For example, an API might take a few milliseconds longer to return the “non-existent” response than the “email sent” response, effectively leaking the truth to those measuring carefully.
• Abusing Linked Accounts and Contacts: Some platforms allow users to find friends by contacts or link accounts. A crafty actor might, for instance, take a list of phone numbers or emails and upload it to a service’s “find friends” feature. If the service (e.g., a messaging app or social network) then tells which of those contacts are registered users, voila – you’ve enumerated who is on the platform. There have been cases where dating apps or messaging services accidentally allowed querying in this way, essentially acting as an oracle of user existence. While many companies have tightened these features (often requiring the querying account to have a verified profile or limiting lookups), they remain a potential avenue for information leakage if not properly secured.
• Cross-Service Data Combos: We touched on the Mat Honan example – that was a chain of Amazon and Apple giving out different pieces of info. In the OSINT realm, similar chaining can occur entirely through open sources. For example, a password reset on Facebook might give an obfuscated email that hints at a Gmail address; an attacker can then go to Gmail’s account recovery and input variations of that email until one of them doesn’t return “No such account” – now they’ve confirmed the exact email. Next, that Gmail address might be run through HaveIBeenPwned (a breach-checking service) to see if it appears in any known data breaches, possibly revealing if it was used on other hacked services and what username was linked to it. Each step is a side-channel that provides a piece, and the attacker assembles the puzzle. None of this requires logging in to any account – it’s all based on how services respond to outsiders.

One illustrative case involved a researcher compiling someone’s data just by resets and search: after getting partial info from a Facebook reset (which revealed a profile name and a bit of an email), they guessed the person’s Gmail address by matching the pattern and confirmed it via Google’s reset page. With the confirmed Gmail in hand, they then likely leveraged Google search and other public databases to find the person’s phone number (since they already knew it ended in certain digits from the Facebook hint) (Using Password Resets for OSINT) (Using Password Resets for OSINT). It’s a cascading waterfall of tiny leaks, each one opening the door a little further.

The key takeaway is that information wants to be free – even systems that are not supposed to give any user data to unauthenticated queries often do so indirectly. OSINT actors are adept at noticing these side doors. A seemingly innocuous feature or error message can become an intelligence coup when exploited cleverly.

Why This is a National Security Issue

Up to now, we’ve discussed how individual user accounts can be discovered and profiled by adversaries. It’s clearly a personal privacy issue – but how does this escalate to the level of national security? The answer lies in scale and intent. When those conducting the reconnaissance are not just curious hackers, but nation-state intelligence agencies or well-funded cybercriminal groups, the stakes are much higher. These actors aren’t looking at one person or one account in isolation; they are building massive maps of who’s who in the digital world, seeking strategic advantages.

Consider a foreign adversary aiming to target government and military personnel. One way to do that is by phishing or social engineering – but phishing is far more effective when you know your target’s digital habits. If an attacker knows that a certain official has an account on a specific cryptocurrency exchange (say Binance) and that the account’s recovery phone ends in 4321, they could craft a very convincing spear-phishing email or SMS pretending to be from Binance, referencing those last four digits (“Your account ending in 4321…”). Such a message immediately looks more legit because it matches the victim’s real experience. Adversaries can use OSINT-gathered data (like phone fragments or account existence) to add credibility to phishing attempts and tailor the lure to something the target actually uses. This dramatically increases the success rate of compromises.

Now multiply this by thousands of officials. It’s been reported that nation-state hacking units actively target the personal accounts of diplomats, defense contractors, journalists, and even their families, not just official work accounts (Disrupting SEABORGIUM’s ongoing phishing operations | Microsoft Security Blog) (Disrupting SEABORGIUM’s ongoing phishing operations | Microsoft Security Blog). Russian groups like “SEABORGIUM,” for instance, have been observed targeting personal Gmail and Microsoft accounts of people of interest (former intelligence officials, experts in specific fields, etc.) as part of their espionage campaigns (Disrupting SEABORGIUM’s ongoing phishing operations | Microsoft Security Blog). How do they know which personal accounts to target? Open-source recon like we’ve described is one likely method. By scraping online services, an attacker can compile a list like: “All emails that belong to employees of Agency X which also have accounts on foreign forums or use certain apps.” Those individuals might be approached or surveilled through those very accounts.

Another national security dimension is identity theft and impersonation at scale. If cybercriminal syndicates (which sometimes collaborate with or are tolerated by hostile governments) harvest these account details, they could conduct wide-reaching fraud or infiltration. For example, knowing that a senior engineer at a defense company uses the same email for a hobby drone forum gives an attacker a path to impersonate a fellow hobbyist and strike up a conversation that leads to trust – classic social engineering. Or consider how partial data like phone numbers and credit card suffixes can be used: an attacker armed with the last 4 digits of a target’s card (gleaned from a breached site or a careless reset form) plus knowledge of their email and maybe home address (from public records) could call a bank pretending to be the target. Those little data points are often used by customer support as verification. In essence, partial PII leaks are the jigsaw pieces for full-on identity theft or impersonation.

From a pure intelligence standpoint, the aggregation of such data is a goldmine. We know that certain nation-states have invested heavily in compiling personal data on Americans and others. The 2015 OPM (Office of Personnel Management) breach, attributed to China, exposed sensitive personal information (including detailed background checks) of over 21 million U.S. government employees and contractors (OPM Hack Poses Overlooked Counterintelligence Risk for Economic Espionage | RAND). Analysts noted that a trove like that could be used to identify individuals’ vulnerabilities – financial troubles, contacts, etc. – to potentially blackmail or recruit them (OPM Hack Poses Overlooked Counterintelligence Risk for Economic Espionage | RAND). While the OPM hack was a direct breach, imagine augmenting that data with OSINT-collected details: personal email addresses of each person, what online services they use, which social networks or dating sites they’re on (valuable for leverage or approaches), and fragments of phone or backup info. It paints a comprehensive picture of each target’s digital footprint. For an intelligence service, this is incredibly useful. It means they don’t have to start from scratch when targeting someone – they already know which angle might work best, which accounts to try compromising first, or what kind of lure might bait the person.

Even outside of government targets, consider corporate espionage. A rival nation’s spies might gather account-reset data on employees of a defense contractor or a critical infrastructure company. If they see that many engineers use a certain file-sharing service or personal Gmail, those become prime targets for phishing that could ultimately lead to corporate network breaches. Or, by seeing which vendors or banks those employees use (via account enumeration), they could impersonate those businesses in fraudulent communications (this method has been used in many “supplier payment fraud” scams). The possibilities go on – all rooted in that initial scraping of publicly accessible account information.

In summary, the danger is in the aggregation and application of this data. What might seem like harmless slivers of info (a phone ending in 67 here, an email that shows up on a fitness app there) can be aggregated into robust dossiers. When assembled by adversaries with strategic goals – whether espionage, influence, or large-scale fraud – these dossiers become powerful weapons. The U.S. Cyberspace Solarium Commission and other policy groups have warned that personal data exposure is a national security risk, not just a privacy one. The case of password reset OSINT is a perfect example: it’s an exploit that can operate quietly at massive scale, potentially profiling millions. Defending against it isn’t just about individual hygiene; it requires systemic changes and awareness at the highest levels.

Mitigation Strategies

Faced with this rather sobering landscape, what can be done? The good news is that there are strategies – both for individuals and for organizations – to mitigate these risks. Some solutions are as simple as changing how we use our email addresses, while others involve changes to web services and policies. Mitigation falls into two broad categories: empowering users to be less trackable and making systems leak less information. Let’s explore a few key strategies:

Email “Plus Addressing” – Unique Identifiers per Service

One of the simplest yet most effective steps individuals can take is to use email aliases or “plus addresses” when registering for services. Most email providers (like Gmail, Outlook, etc.) allow you to add a “+tag” to your email address. For example, if John Doe’s email is [email protected], he can sign up for Twitter as [email protected], and for Amazon as [email protected]. Emails will still reach his main inbox (Gmail ignores anything after the “+”), but now each account of his has a slightly different username. This means that if an OSINT tool or attacker only knows [email protected] and tries that on a site where John used [email protected], it won’t register as the same address. Essentially, plus addressing allows you to create unlimited unique identifiers that all funnel to you, without needing separate accounts.

From a security standpoint, this is powerful. You are nullifying the attacker’s biggest advantage: the fact that you use one consistent email everywhere. With plus aliases, even if they figure out one of your addresses, it doesn’t open the doors to your other accounts (unless the attacker somehow guesses the exact aliases, which is unlikely if you use varied or non-obvious ones). An added bonus – if you start getting spam to [email protected], you immediately know which site leaked or sold your address, because you’ve uniquely tagged it (The Security Pros and Cons of Using Email Aliases – Krebs on Security) (The Security Pros and Cons of Using Email Aliases – Krebs on Security). Security journalist Brian Krebs notes that using unique aliases per site can help users detect breaches: if an email address that was only given to one company gets out, it strongly suggests that company was compromised (The Security Pros and Cons of Using Email Aliases – Krebs on Security). Indeed, some savvy users have caught major breaches early this way.

However, there are some caveats and challenges with plus addressing. First, not all websites allow “+” in email addresses (some outdated or poorly coded systems reject them thinking they’re invalid). This is getting better as plus-addressing becomes more common, but it still happens occasionally. Second, if you ever need to verbally tell someone your email for support, a plus address can confuse agents (“john.doe plus sign something?”). And third, some attackers may try to strip or ignore the plus part if they see it. In fact, some threat actors, when they obtain breached email lists, will remove any “+alias” portions, assuming it might be a trap or an indicator of a security-conscious user (The Security Pros and Cons of Using Email Aliases – Krebs on Security) (The Security Pros and Cons of Using Email Aliases – Krebs on Security). Alex Holden of Hold Security noted that in underground markets, hacked data is often sanitized to drop the “+tag” so that only the base email remains (The Security Pros and Cons of Using Email Aliases – Krebs on Security). This means if a breach of “[email protected]” occurs, the hacker might sell it as just “[email protected]” to appear more generic. While that defeats the purpose of identifying the source of spam, the good news is the attacker still has only your base email – they won’t automatically know the plus addresses you used elsewhere.

Despite these minor drawbacks, sub-addressing (plus aliases) is highly recommended by many security experts for improving privacy and security (The Security Pros and Cons of Using Email Aliases – Krebs on Security). It’s a low-effort, no-cost tactic. Policymakers and IT departments could encourage the use of aliases especially for officials or employees who need to interact with external websites. For example, a government agency could train staff to use [email protected] for work-related third-party services, and [email protected] for personal sites. If nothing else, it creates speed bumps for OSINT correlation – and sometimes a speed bump is all you need to deter broad sweeps. An attacker might move on to easier targets who use a single email everywhere.

Masked Email Services and Trusted Forwarders

Plus addressing still relies on one root email that’s discoverable (everything before the “+” is constant). For those wanting to take identity separation to the next level, masked email services offer a more robust solution. A masked email service (or alias email service) gives you the ability to generate entirely different email addresses (often with different domains) that forward to your real email. Unlike the built-in “+” trick, these aliases don’t contain your real address at all – so a human or even an automated system can’t immediately tell that two different aliases belong to the same person.

Examples of such services include SimpleLogin, AnonAddy, Firefox Relay, and Apple’s Hide My Email (as discussed). For instance, SimpleLogin might let Jane Doe create [email protected] which forwards to her real Gmail. She could also create [email protected] for her airline accounts. To any OSINT observer, those look like two unrelated emails on different domains. If one gets leaked, it cannot be connected to the other unless the attacker somehow breaches the alias service itself (which is designed not to reveal mappings). Apple’s system, which uses the privaterelay.appleid.com domain, is a specific case where Apple manages the forwarding in a tightly controlled way (How to use Hide My Email with Sign in with Apple - Apple Support).

A forwarder service adds an extra layer of indirection – essentially acting as a shield. The security of this approach, of course, hinges on the trustworthiness of the forwarding service. If the alias provider were malicious or got hacked, they could expose the link between your aliases and your real identity. This is where the idea of running such a service in a Trusted Execution Environment (TEE) comes in. Imagine a company (or government IT department) operating an alias email server that runs inside a hardware-enforced secure enclave. The server knows the mapping of aliases to real emails in memory, but even the server admins or a hacker breaking into the OS can’t easily extract that data, thanks to the TEE protections. All emails are encrypted and processed in that secure enclave, then forwarded out. This would minimize the risk of the alias service itself becoming a point of failure or surveillance.

While that might sound very high-tech, it’s an extension of existing ideas. Apple essentially promises a similar concept (they claim they don’t store or read the content of Hide My Email messages, and they delete relay emails shortly after forwarding (How to use Hide My Email with Sign in with Apple - Apple Support)). A TEE-based approach would just add extra cryptographic assurance to that promise. For corporate or government use, one could envision an internal service where every employee gets an @mask.myagency.gov alias domain, and for any external site they register, they generate a unique address. That alias forwards to their real inbox, but externally it’s hard to tie aliases together. If this system is properly secured (via TEE or strict policies), even if an attacker compromised the alias domain or one of the addresses, they couldn’t enumerate others or find the real user easily.

In practical terms, even consumers today can use non-TEE but reliable services: for example, Firefox Relay (by Mozilla) provides a browser extension to create random aliases on the fly, and DuckDuckGo’s Email Protection does similarly, blocking trackers in the emails it forwards. These masked emails fulfill a similar role as plus-addresses but with the benefit that they’re completely different strings. So, if earlier an attacker could strip “+amazon” and try just the base, here there is no base to try – [email protected] might use an alias [email protected] for one site and [email protected] for another, with no obvious relation.

The bottom line: Unique emails per service – whether via plus addressing or full-fledged masking – is one of the strongest defenses against the kind of OSINT enumeration we discussed. It turns the attacker’s one-to-many mapping (one email -> many accounts) into a one-to-one mapping (one alias per account). Even if they compromise or figure out one account, they hit a dead end; it doesn’t reveal what other accounts the person has. For high-value targets, this could thwart broad profiling. It’s like each of your online personas wears a different disguise. It might be a little more effort to manage, but for those in sensitive positions, it can be well worth it.

Policy and Technical Recommendations for Web Services

Ultimately, the burden shouldn’t fall entirely on users to hack around these problems. Web services and platform providers should recognize the privacy and security pitfalls of their current password recovery and authentication designs. Here are some recommendations – both policy-level and technical – that could make a big difference if widely adopted:

• Stop Leaking Data in Password Reset Flow: The most direct fix is for websites to standardize their password reset responses. Ideally, no personally identifiable information (even partial) should be exposed to someone who is not fully authenticated. As Martin Vigo urged, “Ideally we don’t leak anything to unauthorized users, such as those who simply know your email address.” (New OSINT technique exploits password reset process to obtain users’ phone numbers | The Daily Swig). Instead of showing “Phone number ending in 4321”, a site could simply say “We’ve sent a verification code to your registered contact.” If the user forgot which contact that is, they’ll find out when that device or email gets the code. Some might argue this harms user experience, but it’s a trade-off for security. At minimum, companies should agree on best practices for masking: for instance, always show only the last 2 digits of a phone (no more first digits), or allow users to customize a hint phrase. Vigo even proposed using user-chosen labels for recovery options (New OSINT technique exploits password reset process to obtain users’ phone numbers | The Daily Swig). For example, I could label my phone “Work cell” and the reset page would just say “Code sent to your Work cell.” This gives me a hint but reveals nothing useful to an outsider. Such ideas should be further explored by the industry.
• Uniform Responses for Account Existence: To combat enumeration attacks, login and account recovery endpoints should give identical replies or behaviors whether or not an account exists (Remediating Account Enumeration Vulnerabilities - Raxis). For instance, when entering an email on a reset form, always show a generic message like “If an account with that email exists, a reset link will be sent.” Do not indicate “email not found” in a distinct way. Many big providers (like Microsoft, Google) adopted this language years ago, but inconsistencies remain across the web. Regulators or industry groups could push for this as a basic security standard, since it’s a well-known issue (OWASP lists user enumeration as a common vulnerability). Similarly, APIs should refrain from distinct error codes for “no such user”. By eliminating those telltale signs, we make automated mass-scan OSINT much harder. An attacker then cannot easily confirm if an email is registered without actually having access to that email’s inbox or phone (to receive a code).
• Rate Limiting and Monitoring: Web services should implement rate limiting on account lookups and password reset attempts. If one IP (or a small range) is hitting the password reset page for thousands of different usernames or emails, that’s a red flag of enumeration. Throttling those requests or presenting CAPTCHAs after a few tries can slow down OSINT scrapers significantly. Companies could also monitor and flag unusual patterns – e.g., an attempt to cycle through many phone number combinations on the reset page – and share such intel within the security community.
• Encouraging 2FA and Unique Identifiers: Another mitigation for the phone-number-leaking issue is encouraging the use of authenticator apps or security keys for two-factor authentication (2FA) rather than SMS. If SMS isn’t used, the reset flow might not even have a phone number on file to leak. Likewise, services could allow users to opt-out of SMS resets or choose an alternative verification method that doesn’t involve showing digits (for instance, backup codes or email-only recovery). For financial info like credit cards, companies should never use credit card numbers alone as identity verification (the Mat Honan case showed why). Policy could mandate that partial financial info not be reused across services for auth – or that if one service exposes a piece (like last 4 digits), another service cannot accept just that piece as proof. This is more in the realm of inter-company policy or even regulation (to avoid insecure cross-service trust).
• Promote Adoption of Alias and Forwarding Solutions: Platforms that handle identity (especially email providers and SSO providers) should consider building in alias management for users. Microsoft, Google, and others could follow Apple’s lead and integrate an option to “use an alias email for this site.” Even if it’s not as seamless as Apple’s, providing a simple UI to manage plus-addresses or alternate addresses would go a long way. From a policy perspective, making sure plus-addressing is supported (as some legislation of digital services might require compatibility with standard email formats) would help. Companies should not treat “[email protected]” as invalid input – perhaps a compliance test could be introduced for major services to ensure they accept sub-addressing, thus encouraging users to actually use this feature.
• Education and Policy for High-Risk Individuals: For those in sensitive roles (government, defense, critical infrastructure), internal policies could mandate or strongly encourage using unique emails for external accounts. Government agencies might even issue their staff a set of pre-made alias addresses for common services or training on how to set them up. The idea is to treat personal digital footprint as an extension of security training. If an official knows that using the same email for their work and personal life could endanger them or their colleagues, they may take steps to segregate identities. At the national policy level, awareness campaigns about OSINT risks (similar to how there are warnings about social media oversharing) could include this less obvious angle of account enumeration.

In essence, web services need to reduce the information spillage, and users need better tools to diversify their online identities. Both halves are required to address the issue. If we can make it standard that password reset pages are tight-lipped and that using a unique email per site is easy, the whole OSINT password-reset gambit could be largely defanged. This might even push OSINT collectors toward more difficult avenues, raising the cost and effort for our adversaries to conduct large-scale reconnaissance.

Conclusion

The humble email address was never meant to be a national security linchpin, yet in our interconnected world it has become exactly that. When a single identifier ties together a person’s banking, social media, work logins, and more, the stakes of that identifier being discoverable are enormous. We’ve seen how specialized OSINT companies and threat actors exploit password recovery mechanisms to unmask these linkages, correlating accounts and scraping partial personal data in the process. What might seem like trivial details – a couple digits of a phone number, an obfuscated email prefix – can, in the aggregate, enable precision attacks and surveillance. This is a classic example of how convenience features (like helpful password hints or one-click logins) can backfire when abused, tipping the balance in favor of attackers.

From a national security perspective, the ability for adversaries to quietly compile dossiers on officials or citizens is deeply concerning. We worry (rightly) about stolen databases and hacked secrets, but we should equally worry about the “ossified” data that leaks by design through everyday web features. The case for Email Plus Addressing and other alias techniques is not just about stopping spam or organizing your inbox – it’s about throwing a wrench into an adversary’s OSINT machinery. By embracing unique email per service and advocating for privacy-preserving login mechanisms, we make it exponentially harder for malicious actors to capitalize on the current ecosystem’s transparency.

Policymakers can play a role by pushing for standards that limit information disclosure in authentication flows and perhaps by incentivizing the development of secure identity management tools (like that masked email in a TEE idea). Cybersecurity professionals, on the other hand, can lead by example – employing these techniques themselves and educating users about them. After all, our community often preaches about password managers and 2FA; maybe it’s time we add “unique email addresses for important accounts” to the list of best practices we disseminate.

In the cat-and-mouse game of cybersecurity, there is no permanent solution – but we’ve learned that raising the bar even a little can deter a large chunk of attacks. Email aliases and better recovery flows are not terribly hard to implement, yet they could foil automated OSINT reconnaissance and blunt the effectiveness of phishing campaigns that rely on that intel. It’s a rare win-win: improving user privacy and national security posture in one go.

The national security case for email plus addressing ultimately boils down to this: diversity is strength. Just as we avoid single points of failure in infrastructure, we should avoid single points of exposure in our digital identities. By fragmenting the trail we leave online, we deny attackers the easy, cheap intel they’ve been feasting on. It’s time to close these side-channel leaks and take back some privacy – one “+alias” at a time, if need be. The security of not just individuals, but potentially a nation, might depend on it.

Comments and thoughts are also welcome on this tweet:

I wanted to write this for years.

Our humble email address was never meant to be a national security linchpin, yet in our interconnected world it’s become exactly that.

Check out my latest blog and the NotebookLM Podcast to help break it all down!

Link below. pic.twitter.com/Y4QSrJFcri

— Sagi Kedmi (@SagiKedmi) March 20, 2025