Repository navigation
Yubikey 2FA support #18
Description
Is there a plan to support 2FA by a FIDO key (Yubikey)? Is it even possible?
Unfortunately if keys are added to an Apple acoount other 2FA methods are automatically disabled.
Thanks for developing an awesome app!
Activity
parawanderer commentedon Jul 8, 2025
Hi @milenovic so I'm open to it, but it will need to happen upstream from me in the FindMy.py python library.
Not sure if they have this implemented yet there. If they don't, I personally don't really have time nowadays to try and reverse engineer whatever is required to make this work there unfortunately
parawanderer commentedon Aug 6, 2025
Forwarded the request here: malmeloo/FindMy.py#159
Olafejs commentedon Sep 9, 2026
Hi everyone — we’ve submitted an experimental implementation of Apple Account hardware-security-key authentication:
malmeloo/FindMy.py#267
The original adapter successfully completed login on Linux with a Yubico USB Security Key, without removing security keys or weakening account security. The resulting session was also successfully reused.
The PR includes an opt-in FIDO2/WebAuthn login example and 104 new tests. All GitHub checks passed, including tests on Python 3.10–3.14. It is now awaiting review and has not been merged yet.
This is still experimental, verified with one real account/key setup—not a claim of compatibility with every security key.
parawanderer commentedon Sep 16, 2026
Update, since this has been quiet for a while and the position has genuinely changed.
The work exists now. @Olafejs opened malmeloo/FindMy.py#267 on 2026-09-09 — an integration of Apple's HSA2 security-key flow into FindMy.py's existing second-factor model, so a security key sits alongside SMS and trusted-device rather than in an example. It is open, not a draft, and was last updated 2026-09-15.
They report it completing a real login: a Yubico USB key on Linux, assertion accepted, GrandSlam authenticated, MobileMe issuing a Find My session, and that session reused afterwards — without removing keys or weakening the account. They are equally clear about what is not established: no claim of universal hardware or account compatibility, no legacy U2F, and no second real-account trial of the extracted branch.
The part that matters for this app is how the dependency boundary is drawn. The library validates the challenge and hands the caller a
SecurityKeyChallenge; the caller returns aSecurityKeyAssertion.python-fido2is optional and used only by their Linux example.That shape suits Android well. The app would not need USB CTAP inside Python — Android's own FIDO APIs can produce the assertion in Java, and the bridge already carries structured values between Java and Python for other things. It becomes a normal app feature rather than a reverse-engineering project.
So the blocker has moved rather than lifted. This is still
🔴 BLOCKED: FindMy.py, but the block is now "that pull request needs review and merging upstream", not "nobody has written it". It currently has no reviews. malmeloo/FindMy.py#159 is the upstream issue.Nothing to test here yet, and no timeline being promised. Worth following #267 if this affects you — Apple disables the other second factors once a security key is on the account, so for anybody in that position this app does not work at all today.
parawanderer commentedon Oct 11, 2026
This issue is still
🔴 BLOCKED: FindMy.py, but the blocker has moved: the work now exists and is waiting on upstream review.@Olafejs opened malmeloo/FindMy.py#267 on 2026-09-09. It integrates Apple's HSA2 hardware-security-key flow into FindMy.py's existing second-factor model rather than as a standalone example: it adds
SecurityKeyChallenge/SecurityKeyAssertiontypes and a security-key factor returned byget_2fa_methods(), with an additiveauthenticate(signer)method.python-fido2stays optional and is used only by the Linux USB example.As of 2026-10-11 the PR is still open and unmerged, with no reviews. The maintainer's last word (2026-09-15) agreed the approach is correct, said a detailed review is still to come, and asked for the example additions to be dropped before it lands.
We are waiting on #267 to be merged upstream (or pulled into the fork) before implementing this here. The dependency boundary suits Android: the app can produce the assertion with Android's own FIDO APIs in Java and bridge it to Python through the existing bridge, so no USB CTAP work inside Python is needed.