Occasionally someone on Hacker News or Reddit wonders whether or not a YubiKey (or other FIDO/U2F security key) could be duplicated in transit.
Never say never, but FIDO/U2F has specific mitigations designed to make it easy to quickly detect duplicate keys.
A U2F token must increase a counter each time it performs an authentication operation. This counter may be ‘global’ (i.e., the same counter is incremented regardless of the application parameter in Authentication Request message), or per-application (i.e., one counter for each value of application parameter in the Authentication Request message).
U2F token counters should start at 0.
The counter allows relying parties to detect token cloning in certain situations. Relying parties should implement their own remediation strategies if they suspect token cloning due to non-increasing counter values.
Similarly, while it would be possible to create a fake YubiKey, actual YubiKeys are signed with an attestation certificate. The certificate chain of a given key can be checked to ensure it is genuine.
Yubico has an online YubiKey Verification site that will tell you whether a given YubiKey is genuine.
ProtonMail goes in-depth about how Gmail blocked emails coming from its services after an attacker used a DKIM replay attack to target Proton.
On 1 December 2021, we began receiving sporadic reports of delivery failures from protonmail.com addresses to Gmail. This corresponded with a dramatic decline in protonmail.com’s domain reputation as seen via Gmail Postmaster Tools and an increase in sending from known bad IP addresses.
. . .
We suspected a DKIM replay attack, where a single spam email originally sent from ProtonMail was being resent to many Gmail users in an attempt to exploit our deliverability and reputation to get around Google’s anti-spam measures. At one point, roughly 98% of the emails Gmail received that claimed to be from ProtonMail were actually spam, meaning the spammers were sending an amount of emails that was equivalent to 50 times our normal outgoing traffic to Google.
The ProtonMail blog post discusses what DKIM replay attacks are, what allows them, and what can be done to mitigate them.
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.
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.