Wie WhatsApp mit Passkeys die Anmeldung für 1 Milliarde Nutzer sicherer und einfacher gemacht hat

WhatsApp ist die weltweit größte Messaging-Plattform mit Milliarden von Nutzern weltweit. Es ist das Standardkommunikationstool für Menschen in verschiedenen Regionen und verbindet Nutzer über private, zuverlässige und sichere Nachrichten.

„Was mich am meisten begeistert, ist die schiere Größe der Wirkung von WhatsApp. Selbst eine kleine Verbesserung bei WhatsApp betrifft Milliarden von Nutzern weltweit“, sagt Mayank Manuja, Android Engineer im WhatsApp Registration and Access-Team, der die Entwicklung und Implementierung der Passkey-basierten Authentifizierung für WhatsApp geleitet hat. 

Wenn Sie für eine Zielgruppe dieser Größenordnung entwickeln, müssen Sie eine Vielzahl von Netzwerkbedingungen, Gerätefunktionen und digitalen Kompetenzen berücksichtigen. WhatsApp erkannte das Potenzial frühzeitig und verpflichtete sich 2023, Passkeys einzuführen. Damit war es eine der ersten großen Verbraucher-Apps, die die Technologie integrierte. Mit der Implementierung von Passkeys wollte WhatsApp eine schnelle, phishingresistente Option anbieten, die die Reibung für Nutzer erheblich reduziert und gleichzeitig einen robusten Schutz vor Kontoübernahmen und dem Diebstahl von Anmeldedaten bietet.   

Die Entscheidung für Passkeys

Für WhatsApp ist es wichtig, mehrere Zugriffsmethoden anzubieten, damit Nutzer leichter in Verbindung bleiben und bei Bedarf wieder Zugriff erhalten können. Passkeys bieten Nutzern eine optimierte Anmeldung mit nur einem Tippen, die Phishing-Risiken eliminiert und auch in Regionen, in denen die Zustellung von OTP-Nachrichten unzuverlässig sein kann, zuverlässig funktioniert. 

Passkeys nutzen die Public-Key-Kryptografie, um die manuelle Eingabe durch eine Authentifizierung per biometrischer Daten oder Displaysperre zu ersetzen. Dieser Workflow verbessert die Anmeldegeschwindigkeit drastisch, da der Vorgang auf ein einziges Tippen über eine einheitliche Ansicht am unteren Rand reduziert wird, sodass Nutzer im Kontext der App bleiben. Die Vorteile sind zweifach: Passkeys bieten Nutzern eine optimierte Anmeldung und gleichzeitig einen robusten, nativen Schutz vor Phishing-Angriffen. Sie funktionieren auch in Regionen zuverlässig, in denen die herkömmliche Zustellung von OTPs per SMS unzuverlässig sein kann.

Mit robusten und vielfältigen Methoden für den Kontozugriff wird sichergestellt, dass Nutzer immer Zugriff auf das haben, was ihnen am wichtigsten ist.

Clientseitige Integration

Aus Sicht der WhatsApp-Entwickler bot die Credential Manager API eine übersichtliche, einheitliche Oberfläche, die die Komplexität der zugrunde liegenden Anbieter von Anmeldedaten abstrahierte. Nachdem die ersten Integrationsabläufe festgelegt waren, wurde die API-Oberfläche unkompliziert. Die Erstellung und der Abruf von Anmeldedaten folgten klar definierten Anfrage- und Antwortmustern. Den Implementierungsleitfaden finden Sie in der Android-Entwicklerdokumentation. 

Der Happy Path funktionierte von Anfang an, aber die Navigation durch eine vielfältige Nutzerbasis mit unterschiedlichen OEMs, mehreren Android-Versionen und verschiedenen Gerätekonfigurationen (z. B. nur PIN im Vergleich zu biometrischen Daten oder Android 13 im Vergleich zu Android 14+) brachte beispiellose Grenzfälle ans Licht. Dazu gehörten Nutzer ohne Displaysperre, unerwartete Ausnahmetypen, veraltete Play-Dienste und inkonsistentes Verhalten des Anmeldedatenanbieters.

Um diese Hürden zu überwinden, haben die Teams von WhatsApp und Google eng zusammengearbeitet und mehrere Herausforderungen gemeistert:

• Optimierung des Ablaufs für die Suche nach Anmeldedaten: Der anfängliche Ablauf für die Suche nach Anmeldedaten war mit einer hohen Latenz verbunden, insbesondere für Nutzer, die noch keinen Passkey erstellt hatten. Da die meisten WhatsApp-Nutzer in der Anfangsphase in diese Kategorie fielen, führte dies bei fast jeder Anmeldung zu einer spürbaren Verzögerung. Durch die Instrumentierung des Aufrufpfads und die gemeinsame Identifizierung von Engpässen konnte WhatsApp den Prozess erheblich beschleunigen und Leistungssteigerungen erzielen, von denen letztendlich das gesamte Android-Ökosystem profitierte.
• Umgang mit vorübergehenden Zuständen: WhatsApp hat eine umfassende Fehlerbehandlungsebene entwickelt, um gerätespezifische Probleme wie die Verfügbarkeit des Passwortmanagers, eine nicht konfigurierte Displaysperre, zeitweilige Verbindungsprobleme, inkompatible Hardware und veraltete Play-Dienste zu bewältigen. Ausnahmen werden dabei in behebbare und nicht behebbare Zustände kategorisiert. Dies ermöglichte eine graduelle Fehlertoleranz: Wenn ein Passkey-Ablauf nicht abgeschlossen werden konnte, fiel das System sicher auf die herkömmliche Authentifizierung zurück, ohne dass der Nutzer in einem fehlerhaften Zustand verblieb.
• Umgang mit betriebssystemspezifischen Ausnahmen:Als die Telemetrie gerätespezifische Probleme wie „GetPublicKeyCredentialDomException“ (Anmeldedaten konnten nicht entschlüsselt werden) auf bestimmten Android 13-Geräten und „CreatePublicKeyCredentialDomException“ (Konto für die Synchronisierung konnte nicht abgerufen werden) bei der Passkey-Erstellung auf Android 14 aufdeckte, untersuchten Google und das WhatsApp-Team die Ursachen und implementierten Verbesserungen auf Plattformebene, um die Erstellung zu vereinfachen. Hier finden Sie einen umfassenden Leitfaden mit häufigen Fehlercodes und Beschreibungen im Zusammenhang mit dem Credential Manager sowie Informationen zu den Ursachen. 

Nutzererfahrung optimieren

Da Passkeys Anfang 2023 ein völlig neues Konzept waren, gab es keine etablierten Muster für die Aufforderung, sie zu erstellen. Durch umfangreiche A/B-Tests hat WhatsApp ein kontextbezogenes Framework entwickelt, das auf Nutzer abzielt, die am meisten davon profitieren würden. Diese Strategie wurde kontinuierlich weiterentwickelt: Als die Abläufe im Android-Betriebssystem zu einer optimierten, einseitigen Benutzeroberfläche wurden, vereinfachte WhatsApp seine eigenen Aufforderungen, um redundante oder verwirrende Benutzeroberflächen zu vermeiden.

Serverseitige Architektur und plattformübergreifende Hürden

Im Backend implementiert der WhatsApp-Server die standardmäßigen WebAuthn-/FIDO2-Prozesse. Das Backend ist in Erlang geschrieben und ruft die Rust-Bibliothek webauthn-rs über eine native Schnittstelle auf. Diese Rust-Bibliothek übernimmt die Signaturprüfung und das Parsen von Anmeldedaten, sodass sich der interne Code auf Orchestrierung, Speicherung und Produktregeln wie Berechtigung, Ratenbegrenzung und Lebenszyklus von Anmeldedaten konzentrieren kann.

Die Serverarchitektur orchestriert diese Kernzeremonien über vier primäre Einstiegspunkte, die für die Registrierung und Authentifizierung in Begin- und Finish-Sequenzen unterteilt sind:

1. Passkey-Registrierung

In dieser Sequenz werden Erstellungsoptionen an den Client ausgegeben, die Attestierung überprüft, sobald der Client die erfolgreiche Erstellung bestätigt, und die Anmeldedaten sicher gespeichert.

Erlang: Registrierung starten

begin_registration(UserId) ->
    Existing = list_credentials(UserId),
    %% reuse the existing user handle, or mint a new one
    {UserHandle, IsNew} = user_handle(Existing),
    %% returns the client creation options and the server-side challenge state
    #{client_safe := CreationOptions, server_only := ChallengeState} =
        webauthn:start_registration(UserId, UserHandle, rp_config()),
    %% excludeCredentials: the user's existing credential IDs, so the device won't re-enroll one
    Options = with_exclude_credentials(CreationOptions, credential_ids(Existing)),
    store_challenge(UserId, ChallengeState),          %% short TTL
    IsNew andalso reserve_user_handle(UserId, UserHandle),
    Options.

• Nutzer identifizieren:Der Server prüft zuerst, ob bereits Anmeldedaten vorhanden sind, um entweder ein vorhandenes Nutzer-Handle wiederzuverwenden oder ein neues zu generieren.
• Optionen und Challenge generieren:Die WebAuthn-Bibliothek wird aufgerufen, um die Erstellungsoptionen für den Client und einen sicheren Challenge-Status für den Server zu generieren.
• Duplikate verhindern:Die vorhandenen Anmeldedaten-IDs des Nutzers werden explizit ausgeschlossen, damit das Gerät nicht versehentlich einen bereits registrierten Passkey noch einmal registriert.
• Challenge speichern:Der Server speichert die Challenge vorübergehend mit einer kurzen Gültigkeitsdauer (TTL) und sendet die Optionen an das Clientgerät zurück.

Erlang: Registrierung abschließen

finish_registration(UserId, Attestation) ->
    ChallengeState = get_challenge(UserId),          %% must exist and be unexpired
    #{credential_id := CredId, public_key := PubKey} =
        webauthn:finish_registration(Attestation, ChallengeState, rp_config()),
    ok = index_credential(CredId, UserId),            %% map credential_id -> account
    case multi_passkey_enabled(UserId) of
        true  -> add_credential(UserId, CredId, PubKey);      %% append (oldest evicted past the cap)
        false -> replace_credential(UserId, CredId, PubKey)   %% single-passkey mode
    end,
    notify_client(UserId, {passkey_created, CredId}),
    ok.

• Challenge abrufen:Der Server ruft die gespeicherte Challenge ab und prüft, ob sie noch vorhanden und nicht abgelaufen ist.
• Attestierung überprüfen: Die Antwort des Clients (Attestierung) und die Challenge werden an die WebAuthn-Bibliothek übergeben, um die Anfrage zu überprüfen und die neue Anmeldedaten-ID und den öffentlichen Schlüssel zu extrahieren.
• Anmeldedaten indexieren:Die neue Anmeldedaten-ID wird direkt dem Konto des Nutzers zugeordnet, damit sie später schnell gefunden werden kann.
• Limits speichern und verwalten:Je nachdem, ob die Funktion für mehrere Passkeys aktiviert ist, hängt der Server die neuen Anmeldedaten an die Liste des Nutzers an (wobei die ältesten entfernt werden, wenn ein Limit erreicht ist) oder ersetzt die vorhandenen Anmeldedaten im Modus für einen einzelnen Passkey.

2. Anmeldedatenauthentifizierung

Ähnlich wie bei der Erstellung übernimmt der Anwendungsserver den Authentifizierungsablauf, indem er die Anmeldesequenz orchestriert. Dazu gehört die Überprüfung der Assertion nach erfolgreicher Clientauthentifizierung und die dynamische Aktualisierung gespeicherter Anmeldedaten, wenn WebAuthn signalisiert, dass eine Aktualisierung erforderlich ist.

Erlang: Authentifizierung starten

begin_authentication(UserId) ->
    Credentials = list_valid_credentials(UserId),
    #{client_safe := RequestOptions, server_only := ChallengeState} =
        webauthn:start_authentication(Credentials, rp_config()),
    store_challenge(UserId, ChallengeState),          %% short TTL
    RequestOptions.

• Gültige Anmeldedaten abrufen:Der Server sucht nach allen derzeit gültigen Anmeldedaten, die mit dem Nutzer verknüpft sind.
• Challenge generieren:Mit diesen Anmeldedaten werden Anfrageoptionen für den Client erstellt und eine neue serverseitige Challenge generiert.
• Speichern und zurückgeben:Wie bei der Registrierung wird die Challenge vorübergehend gespeichert und die Anfrageoptionen werden an die Client-App übergeben.

Erlang: Authentifizierung abschließen

finish_authentication(UserId, Assertion) ->
    ChallengeState = get_challenge(UserId),
    Credentials = list_valid_credentials(UserId),
    case webauthn:finish_authentication(Credentials, Assertion, ChallengeState) of
        #{user_verified := true, credential_id := CredId, needs_update := NeedsUpdate} = Result ->
            %% webauthn tells us when the stored credential should be refreshed
            NeedsUpdate andalso refresh_credential(UserId, CredId, Result),
            mark_credential_used(UserId, CredId),
            {ok, CredId};
        _ ->
            {error, not_allowed}
    end.

• Assertion überprüfen:Der Server ruft die gespeicherte Challenge und die gültigen Anmeldedaten ab und fordert dann die WebAuthn-Bibliothek auf, die Assertion des Clients zu überprüfen.
• Bei Bedarf aktualisieren:Wenn der Nutzer erfolgreich bestätigt wurde, prüft der Server das Flag „needs_update“. Die WebAuthn-Bibliothek verwendet dieses Flag, um zu signalisieren, ob der gespeicherte Status der Anmeldedaten auf dem Server aktualisiert werden muss.
• Abschließen:Der Server markiert die Anmeldedaten als verwendet und schließt den Anmeldevorgang erfolgreich ab.

Weitere Informationen zur Serverregistrierung finden Sie im Integrationsleitfaden. 

Erweiterte Überlegungen zur Architektur 

Die Implementierung von Passkeys auf dem Server in großem Umfang stellte besondere Herausforderungen dar, insbesondere im Hinblick auf die Kontoarchitektur und die Gerätesynchronisierung. Ashish Choudhary vom WhatsApp-Backend-Team nannte die größten Herausforderungen:

1. Migration zu mehreren Passkeys pro Konto:Die alte Serverlogik von WhatsApp war eng mit der Annahme verknüpft, dass pro Nutzer nur ein Satz von Anmeldedaten vorhanden ist. Um die moderne Realität für verschiedene Geräte zu unterstützen, haben sie ein System mit einer begrenzten Liste entwickelt, das die ältesten Anmeldedaten intelligent entfernt, sobald ein Limit erreicht ist. Um absolute Stabilität zu gewährleisten, wurde diese wichtige strukturelle Änderung nach und nach durch strenge Tests eingeführt.
2. Lebenszyklus von Anmeldedaten: Die Verwaltung der Gültigkeit von Anmeldedaten erforderte Fingerspitzengefühl. Wenn Sie Anmeldedaten zu aggressiv für ungültig erklären, sind unnötige Neuregistrierungen erforderlich. Wenn Sie zu nachsichtig sind, häufen sich veraltete Anmeldedaten an. WhatsApp hat dieses Problem gelöst, indem es ausgewogene Lebenszyklusstatus implementiert hat, um die Sicherheit zu gewährleisten, ohne die Nutzer zu frustrieren. Ergänzt wird dies durch eine automatische Hintergrundbereinigung für inaktive Passkeys.

Geräteübergreifende Synchronisierung neu gedacht

Diese robuste Architektur mit mehreren Passkeys ermöglichte es WhatsApp auch, die plattformübergreifende Nutzerfreundlichkeit völlig neu zu gestalten. Beim standardmäßigen geräteübergreifenden WebAuthn-Verfahren muss ein QR-Code auf einem Gerät gescannt und die Authentifizierung über Bluetooth auf einem anderen Gerät durchgeführt werden. WhatsApp stellte jedoch fest, dass die Bluetooth-Abhängigkeit unzuverlässig war und Nutzer die neuen QR-Codes oft mit dem bestehenden WhatsApp Web-Verknüpfungsprozess verwechselten.

Anstatt einen anfälligen geräteübergreifenden Übertragungsmechanismus zu erzwingen, ermöglicht WhatsApp Nutzern, Passkeys nativ in mehreren Ökosystemen wie dem Google Passwortmanager unter Android und dem iCloud-Schlüsselbund unter iOS zu speichern. Wenn Nutzer zu einer neuen Plattform migrieren, erstellen sie bei der nächsten Anmeldung einfach einen neuen Passkey. Dieser Ansatz ist für den Nutzer völlig unkompliziert und funktioniert nahtlos auf der neuen Serverinfrastruktur für mehrere Passkeys.

Unsere Zukunftspläne

Seit der Einführung von Passkeys hat WhatsApp eine starke organische Akzeptanz bei seiner großen Nutzerbasis verzeichnet. Durch die Umwandlung des herkömmlichen mehrstufigen Anmeldevorgangs in eine einzige, reibungslose biometrische Geste hat die App die Nutzerfreundlichkeit erheblich verbessert. Aufbauend auf diesem Erfolg erweitert WhatsApp jetzt die Passkey-Nutzung über die Erstanmeldung hinaus und untersucht die nahtlose In-App-Neuauthentifizierung für sensible Kontoaktionen wie passkey-verschlüsselte Backups.

WhatsApp arbeitet aktiv mit Plattformpartnern zusammen, um die Erstellung von Anmeldedaten zu vereinfachen. Es wird erwartet, dass die Einstiegshürden mit der Weiterentwicklung der biometrischen Funktionen von Geräten auf natürliche Weise sinken werden. 

Empfehlung für Entwickler, die in großem Umfang entwickeln

Für Entwickler, die Passkeys in großem Umfang integrieren möchten, hat das WhatsApp-Team die folgenden wichtigen Empfehlungen:

• Investieren Sie frühzeitig in eine Fehlertaxonomie:Kategorisieren Sie die verschiedenen Ausnahmen des Credential Managers in behebbare und nicht behebbare Zustände und definieren Sie für jedes Szenario klare, reibungslose Fallback-Pfade.
• Voraussetzungen prüfen:Prüfen Sie die Gerätefunktionen, z. B. ob eine Displaysperre vorhanden ist, ob biometrische Hardware vorhanden ist und welche Version der Google Play-Dienste installiert ist. Gestalten Sie die Abläufe so, dass nicht berechtigte Nutzer proaktiv ausgeschlossen werden, anstatt den Vorgang mittendrin abzubrechen.
• App auf Fallback vorbereiten:Verwenden Sie Passkeys als optimale primäre Authentifizierungsmethode für kompatible Geräte, behalten Sie aber immer herkömmliche Methoden als zuverlässiges, universelles Fallback bei.
• Fragmentierung der Betriebssystemversionen berücksichtigen:Das Verhalten von Passkeys kann je nach Betriebssystem variieren. Führen Sie gründliche Tests unter Android 13, 14 und 15+ durch und berücksichtigen Sie OEM-spezifische Abweichungen in der Benutzeroberfläche für die Auswahl von Anmeldedaten.
• Kontextbezogene Upselling-Angebote und Informationen:Bieten Sie die Passkey-Erstellung bei sicherheitsrelevanten Aktionen an. Betonen Sie die Vorzüge (Geschwindigkeit und Sicherheit) in verständlicher Sprache, um die Akzeptanz bei den Nutzern zu erhöhen.
• Proaktiv überwachen:Das Ökosystem entwickelt sich mit jedem Betriebssystemupdate weiter. Behalten Sie Latenz- und Fehlermuster im Blick, um auf sich ändernde Gerätelandschaften vorbereitet zu sein.

Erste Schritte mit Passkeys und dem Credential Manager

In unserem Integrationsleitfaden und dem öffentlichen Beispielcode erfährst du, wie du Passkeys und den Credential Manager unter Android verwendest.

Wenn Sie Fragen oder Probleme haben, können Sie uns diese über den Issue Tracker für Android-Anmeldedaten mitteilen.