A hardware authentication key still produced a one-time password employees could type into the wrong site. That is how CircleCI-themed phishing against Dropbox harvested GitHub usernames, passwords, and hardware OTPs on a fake login page, reached at least one Dropbox GitHub organization, and led to about 130 private repositories being copied. According to the Dropbox Security Team, the credential-phase path was the live OTP hand-off at the impostor page in October 2022. Phishing-resistant WebAuthn binds the assertion to the real login origin, so a spoofed page cannot collect a usable second factor the way phishable hardware OTP can. Phishing-proof MFA 2.0 removes phishable factors across the full identity lifecycle, not only at that login step. Once a live session already exists, repository copy is containment work, not another MFA prompt.
For the full attack chain and timeline, read the companion on legacymfa.sucks.
FAQ
Would WebAuthn have stopped the Dropbox CircleCI phishing login?
Yes. Origin-bound WebAuthn would have stopped the Dropbox CircleCI phishing login from completing on the fake page. Dropbox's disclosure said employees entered a GitHub username and password, then used a hardware authentication key to pass a one-time password to the malicious site. A WebAuthn assertion is bound to the real login origin, so a CircleCI-styled impostor page cannot obtain a usable second factor the way a phishable OTP can. Dropbox called WebAuthn the gold standard and accelerated environment-wide adoption with hardware tokens or biometrics after the incident. Phishing-proof MFA 2.0 extends that idea across the identity lifecycle: no transferable factor is used at registration, device onboarding, authorisation, authentication, or decommissioning, so a fake origin never receives a second factor to replay.
Why did hardware OTP fail if the token was physical hardware?
Hardware OTP failed at Dropbox because the one-time password is still a transferable code the employee can hand to the wrong site. Physical possession of the key does not bind the ceremony to the legitimate GitHub origin. Dropbox wrote that threat actors had moved beyond harvesting usernames and passwords to harvesting multi-factor authentication codes, and that not all types of multi-factor authentication are created equal. That is the classic credential-phase failure of OTP, whether the generator sits on a phone or a hardware token. Device-bound, origin-bound signatures remove the code the fake page needs.
Does phishing-proof MFA stop copying repos after GitHub access?
No. Phishing-proof MFA does not undo repository copy after attackers already hold a live authenticated GitHub session. In the Dropbox incident, about 130 private repositories were copied once the compromised account was in, including developer API keys in code and a few thousand names and email addresses. Closing the phishable login stops this path from ever minting that session. Malware after a legitimate login is a harder, separate problem. After a successful harvest, defenders still need session kill, credential rotation, and secret scrubbing in repos. Revoke is hygiene; it is not a substitute for preventing the OTP hand-off at the fake page.
How do phishing-resistant passkeys compare to phishing-proof MFA here?
Phishing-resistant factors such as FIDO2, passkeys, and WebAuthn harden the login ceremony with origin-bound signatures and no reusable secret to type. That alone stops the Dropbox-style fake page from collecting a hardware OTP. Phishing-proof MFA 2.0 means no phishable factor at any lifecycle stage: registration, device onboarding, authorisation, authentication, or decommissioning. Public reporting does not establish an enrollment or helpdesk path in this Dropbox case, so origin-bound login cryptography is the decisive control for the harvest that occurred. The strength ladder still holds: password, then OTP or SMS, then push, then phishing-resistant login, then phishing-proof coverage across the lifecycle.
What remains after you close phishable OTP on workforce GitHub login?
After you close phishable OTP on workforce GitHub login paths like Dropbox's, residual secrets and sessions stay separate work. Dropbox disabled the threat actor's access the same day GitHub alerted on 14 October 2022, rotated credentials, and reported no evidence of successful abuse of exposed credentials after log review and external forensics. Public reporting does not establish later external abuse of residual repository secrets. Inventory API keys that lived in copied repos, force session revocation, and prefer prevention, not detection so a spoofed origin never receives a factor in the first place.
