Can the FCC Defeat SIM Swap Attacks?

On September 30, 2021, the US Federal Communications Commission issued a rulemaking notice for proposed new rules to address SIM swapping and number porting fraud.

The Notice of Proposed Rulemaking proposes various actions to proactively address the risk of follow-on attacks using stolen data to reduce the risk of additional harm to consumers from recent data breaches. It proposes to amend the Customer Proprietary Network Information (CPNI) and Local Number Portability rules to require carriers to adopt secure methods of authenticating a customer before redirecting a customer’s phone number to a new device or carrier. It also proposes requiring providers to immediately notify customers whenever a SIM change or port request is made on customers’ accounts.

The full notice has an interesting history of prior FCC actions and more details on the specifics of requiring more secure methods of authenticating customers before a SIM swap or number port out.

For SIM swaps, for example, the FCC is considering requiring mobile companies to affirmatively reach out to a customer using a one-time passcode sent via text message, email, or voice call to authenticate the SIM swap. This would likely reduce, though not prevent altogether, SIM swap fraud.

It would also, however, likely create a customer service nightmare for mobile carriers. After all, there is already a significant issue where people find carriers are unwilling to fulfill their legitimate number porting requests. There will be any number of reasons a customer might make a legitimate SIM change or number port out where they are unable to comply with the secure authentication provision.

The real problem, largely unmentioned in the FCC’s notice, is that the telephone number has become the new Social Security Number. It is routinely used as a method of authentication for a wide swath of services, even though the flaws in doing so are numerous and obvious at this point.

Making it harder to steal someone’s phone number will help somewhat. Still, given that hijacking a person’s phone number can potentially allow criminals to hijack that person’s entire life, the incentives to that sort of fraud are going to be immense as long as that remains the status quo.

It’s 2021 and the FAO Can’t Be Bothered to Install a Cert

Both food security and cybersecurity appear to be on the decline at the Food and Agriculture Organization of the United Nation’s website.

Mind you, this is an organization with an annual budget north of US $1 billion.

Food and Agriculture Organization of the United States
Food and Agriculture Organization of the United States

Privacy Pass Extension for Chrome and Firefox

Privacy Pass is an extension for Chrome and Firefox that reduces the number of CAPTCHAs users are presented with while browsing.

Privacy Pass interacts with supporting websites to introduce an anonymous user-authentication mechanism. In particular, Privacy Pass is suitable for cases where a user is required to complete some proof-of-work (e.g. solving an internet challenge) to authenticate to a service. In short, the extension receives blindly signed ‘passes’ for each authentication and these passes can be used to bypass future challenge solutions using an anonymous redemption procedure. For example, Privacy Pass is supported by Cloudflare to enable users to redeem passes instead of having to solve CAPTCHAs to visit Cloudflare-protected websites.

The blind signing procedure ensures that passes that are redeemed in the future are not feasibly linkable to those that are signed. We use a privacy-preserving cryptographic protocol based on ‘Verifiable, Oblivious Pseudorandom Functions’ (VOPRFs) built from elliptic curves to enforce unlinkability. The protocol is exceptionally fast and guarantees privacy for the user. As such, Privacy Pass is safe to use for those with strict anonymity restrictions.

The developers wrote a 2018 paper describing in detail how the protocol works to preserve user privacy while not compromising the security of sites that rely on CAPTCHAs to limit brute force and DDOS attacks.

Cloudflare Wants to Replace CAPTCHAs with FIDO Keys

Cloudflare is testing a system to allow users to use FIDO keys to skip CAPTCHAs.

From a user perspective, a Cryptographic Attestation of Personhood works as follows:

1. The user accesses a website protected by Cryptographic Attestation of Personhood, such as

2. Cloudflare serves a challenge.

3. The user clicks I am human (beta) and gets prompted for a security device.

4. User decides to use a Hardware Security Key.

5. The user plugs the device into their computer or taps it to their phone for wireless signature (using NFC).

6. A cryptographic attestation is sent to Cloudflare, which allows the user in upon verification of the user presence test.

Completing this flow takes five seconds. More importantly, this challenge protects users’ privacy since the attestation is not uniquely linked to the user device. All device manufacturers trusted by Cloudflare are part of the FIDO Alliance. As such, each hardware key shares its identifier with other keys manufactured in the same batch (see Universal 2nd Factor Overview, Section 8). From Cloudflare’s perspective, your key looks like all other keys in the batch.

Cloudflare says it is primarily interested in reducing the amount of time users spend on CAPTCHAs, which it estimates currently take up 500 years of user time every day.

CAPTCHAs are certainly frustrating, and anything that can be done to replace them while still mitigating brute force and DDOS attacks is great. But it would also be great to see FIDO keys become more accepted and normalized across the Internet.

Bellingcat: US Soldiers Inadvertently Leaked Nuclear Security Secrets via Flashcard Apps


For US soldiers tasked with the custody of nuclear weapons in Europe, the stakes are high. Security protocols are lengthy, detailed and need to be known by heart. To simplify this process, some service members have been using publicly visible flashcard learning apps — inadvertently revealing a multitude of sensitive security protocols about US nuclear weapons and the bases at which they are stored.

. . .

However, the flashcards studied by soldiers tasked with guarding these devices reveal not just the bases, but even identify the exact shelters with “hot” vaults that likely contain nuclear weapons.

They also detail intricate security details and protocols such as the positions of cameras, the frequency of patrols around the vaults, secret duress words that signal when a guard is being threatened and the unique identifiers that a restricted area badge needs to have.

The entire article is well worth a read, especially for the sheer amount of information Bellingcat uncovered, including locations of cameras and backup generators at specific sites, detailed information on equipment carried on bases, and schedules for checking aircraft shelters containing nuclear weapons vaults.

This information was publicly searchable because most of the flashcard/quizzing tools that the soldiers used made content public by default. This is similar to how credentials are inadvertently leaked on Github by developers apparently unaware or misunderstanding the implications of hosting those on public repositories.

One change that would help a lot would be if online applications start defaulting to private and requiring users to enable public access, rather than the current approach of defaulting to public and requiring the user to intervene to make content private.

For example, although Github has been the source of numerous credential links, all new personal repositories default to “Public.” The user has to choose the “Private” option manually. This practically guarantees a high level of ongoing leaks at sites such as Github.

Github did make a change in July 2020 so that all repositories created by users accessing Github via an organizational SSO service will be defaulted to private. So they realize that defaulting to public is a problem. Yet, they decided to stick with that behavior for personal repositories, even though a huge segment of Github-related credential leaks are from individuals using personal repositories.

This should be unacceptable given the well known security and privacy problems with this practice.