WebAuthn im wirklichen Leben

Im September 2019 unterstützte das Mail.ru Mail-Team die WebAuthn-Technologie. Wir waren der erste E-Mail-Dienst der Welt, der die Möglichkeit implementiert hat, sich mit elektronischen Schlüsseln anstelle von Passwörtern in Ihrem Konto anzumelden. Jetzt steht diese Möglichkeit allen unseren Benutzern zur Verfügung. Sie können den elektronischen Schlüssel in den Einstellungen an Ihr Konto binden und ihn anschließend frei zur Eingabe verwenden.



Wir haben hier auf Habré bereits Neuigkeiten zu diesem Ereignis geschrieben. In diesem Artikel möchte ich mehr über die Gründe für die Implementierung von WebAuthn in unseren Diensten und über die technischen Aspekte der Arbeit mit dieser Technologie sprechen.

Was ist WebAuthn und warum wird es benötigt?


In der modernen Welt verwenden die meisten Internetdienste Kennwörter, um Benutzer zu authentifizieren. Der Vorteil von Passwörtern ist ihre Einfachheit: Um auf die erforderliche Ressource zuzugreifen, müssen Sie nur das Passwort kennen und es korrekt eingeben.

Die Nachteile von Passwörtern überwiegen jedoch häufig ihre Vorteile:

  • Wenn das Passwort einfach ist, können Sie es abholen.
  • Wenn in mehreren Diensten dasselbe Kennwort verwendet wird, erhält der Angreifer Zugriff auf alle anderen Dienste.
  • Passwörter sind anfällig für Phishing-Angriffe.
  • Starke und eindeutige Passwörter sind schwer zu merken, daher muss der Benutzer das Passwort auf den Aufkleber schreiben und auf den Monitor kleben, von wo aus es leicht ausspioniert, gestohlen oder verloren werden kann.

Um die Mängel von Kennwörtern zu beseitigen und den Authentifizierungsprozess sicherer zu machen, werden verschiedene Möglichkeiten zum Ersetzen von Kennwörtern angezeigt. Dies ist die Verwendung von Einmalcodes, die per SMS oder PUSH-Benachrichtigungen an den Benutzer gesendet werden, oder die Verwendung spezieller TOTP-Codegeneratoranwendungen, mit denen sich der Benutzer anmelden kann Konto ohne Eingabe Ihres Passworts.

Unternehmen wie Microsoft , Yahoo und Amazon denken über die Verwendung kennwortloser Authentifizierungsmethoden nach und verzichten vollständig auf die Verwendung von Kennwörtern in ihren Diensten. Mail.ru Mail ist keine AusnahmeWir unterstützen seit langem die Anmeldung mit Einmalcodes, sodass Benutzer sich nicht an komplexe und sichere Kennwörter erinnern und schnell auf ihr Konto zugreifen können.

Eine weitere Alternative zu Passwörtern ist die Authentifizierung mit elektronischen Schlüsseln (Sicherheitsschlüssel, ein anderer Name - elektronische Authentifikatoren). Das Funktionsprinzip basiert auf der Verwendung asymmetrischer Kryptographie und ist in der FIDO2-Protokollfamilie beschrieben, die von der FIDO-Allianz (Fast IDentity Online) entwickelt wurde.

Im März 2019 veröffentlichte W3C die erste Version des Standards.Hier wird eine browserbasierte JS-API beschrieben, mit der Sie mit elektronischen Schlüsseln interagieren können. Der Standard erhielt den Empfehlungsstatus und den Namen Webauthentifizierung: API für den Zugriff auf Anmeldeinformationen mithilfe eines öffentlichen Schlüssels: Ebene 1 (Webauthentifizierung: Eine API für den Zugriff auf Anmeldeinformationen für öffentliche Schlüssel Ebene 1) - kurz WebAuthn.

Wie WebAuthn funktioniert


Die folgenden Hauptakteure im Authentifizierungsprozess mit WebAuthn werden identifiziert:

  • Client (WebAuthn Client) - ein Browser, der die WebAuthn-API unterstützt;
  • Webanwendung - Eine Anwendung, die auf dem Client ausgeführt wird und die WebAuthn-API verwendet, um mit Anmeldeinformationen zu interagieren.
  • Anmeldeinformationen (Public Key Credential) - ein Paar öffentlicher und privater kryptografischer Schlüssel, die einem Benutzerkonto zugeordnet sind;
  • Authenticator - ein Gerät oder Programm - erstellt Benutzeranmeldeinformationen und signiert Anforderungen der vertrauenden Partei mit diesen Anmeldeinformationen (ein anderer Name ist ein elektronischer Schlüssel).
  • Die vertrauende Partei (WebAuthn Relying Party) - der Webserver - speichert den dem Benutzerkonto zugeordneten öffentlichen Schlüssel und überprüft die Gültigkeit der Signatur ihrer Anforderungen mit dem im Authentifikator gespeicherten privaten Schlüssel.

Mit der WebAuthn-API können Sie nur zwei Vorgänge ausführen. Sie können neue Anmeldeinformationen erstellen und Anforderungen vom Server mit bereits erstellten Anmeldeinformationen signieren.

Erstellung von Anmeldeinformationen ( MakeCredential )



Schema der Bühne mit der Erstellung von Anmeldeinformationen, entnommen aus w3.org .

Zu diesem Zeitpunkt ist der elektronische Schlüssel im Benutzerkonto registriert. Im Authentifikator wird ein neues Paar öffentlicher und privater Schlüssel generiert, und der öffentliche Schlüssel wird gesendet und im Benutzerkonto auf dem Server gespeichert.

const credential = await navigator.credentials.create({
    publicKey: publicKeyMakeCredentialOptions
});

Signieren einer Anfrage mit bereits erstellten Anmeldeinformationen ( GetAssertion )



Schema der Bühne mit Überprüfung der Anmeldeinformationen, entnommen aus w3.org .

In diesem Schritt wird geprüft, ob der Benutzer über einen Authentifikator verfügt, dessen öffentlicher Schlüssel im Benutzerkonto gespeichert ist. Ein zufälliges Token wird mit dem privaten Schlüssel im Authentifikator signiert und an den Server gesendet, wo der Server überprüft, ob die Signatur korrekt ist. Wenn die Signatur korrekt ist, schließen wir dementsprechend, dass der Benutzer wirklich über diesen Authentifikator verfügt.

const assertion = await navigator.credentials.get({
    publicKey: publicKeyGetAssertionOptions
});

In diesem Video sehen Sie eine Demonstration der Eingabe von Mail.ru Mail mit WebAuthn .

Weitere Informationen zur WebAuthn-API selbst finden Sie in der WebAuthn-Spezifikation und beispielsweise in diesem Medium-Artikel .

Die Arbeit von WebAuthn basiert also auf der Verwendung elektronischer Schlüssel. Was ist es?

Elektronische Schlüssel


Elektronische Schlüssel (ich nenne sie manchmal auch "WebAuthn-Schlüssel", Sicherheits-Sicherheitsschlüssel) sind Geräte oder Programme, die FIDO2-Interaktionsprotokolle implementieren.

In der WebAuthn-Spezifikation und auf Haushaltsebene werden alle elektronischen Schlüssel in eine von zwei Kategorien eingeteilt:

  • plattformunabhängige Schlüssel (Roaming-Authentifikatoren);
  • Plattformauthentifizierer

Plattformunabhängige Schlüssel sind externe physische Geräte wie Yubikey von Yubico oder Titan Security Key von Google. In der Regel werden solche Authentifikatoren über USB, NFC oder BLE mit dem Computer oder Smartphone des Benutzers verbunden. Die Kommunikation mit solchen Geräten erfolgt über das spezielle CTAP-Protokoll (Client to Authenticator Protocol).

Um mit physischen elektronischen Schlüsseln arbeiten zu können, muss der Benutzer ihn einmal an sein Konto binden. Danach hat der Benutzer die Möglichkeit, mit diesem elektronischen Schlüssel auf jedem anderen Gerät und in jedem Browser einzugeben.


Beispiele für verschiedene plattformunabhängige Schlüssel von theverge.com .

Wenn der Funktionsmechanismus des ersten Schlüsseltyps mehr oder weniger klar ist, möchte ich näher auf die zweite Kategorie eingehen.

Im zweiten Fall werden öffentliche und private kryptografische Schlüssel nicht in einem externen physischen Gerät, sondern mit einem Softwaremodul in einem Computer oder Smartphone generiert und gespeichert. Dieses Softwaremodul kann auf der spezifischen Anwendungsebene oder auf Betriebssystemebene implementiert werden. Zum Beispiel in einem sicheren Chip in einem Computer, auf den Ihr Betriebssystem nur Zugriff gewährt, wenn Sie angemeldet sind und bewiesen haben, dass Sie wirklich Sie sind.

In den meisten modernen Implementierungen in verschiedenen Browsern muss sich der Benutzer vom Betriebssystem entweder mit einem Fingerabdruck oder durch Eingabe des Kennworts für das Benutzerkonto bestätigen. Es ist wichtig zu verdeutlichen, dass der Benutzer zwar seinen Finger auf den Fingerabdruckscanner legen muss, um solche Tasten zu verwenden, der Fingerabdruck selbst jedoch nirgendwo gespeichert und nirgendwo übertragen wird. Dies ist nur die Art und Weise, wie das Betriebssystem oder der Browser den Benutzer validiert.


Verwendung plattformspezifischer Authentifikatoren.

Nur verschlüsselte Informationen zu öffentlichen Schlüsseln oder ein signiertes zufälliges Token werden von der WebAuthn-API an den Webdienst zurückgegeben, der dann auf der Serverseite gespeichert und überprüft wird.

Daher ist es im Fall des integrierten Authentifikators möglich, ihn nur in dem Browser und auf dem Gerät zu verwenden, auf dem er an das Konto angehängt wurde. Mit anderen Worten, plattformabhängige Schlüssel müssen auf jedem Gerät / Browser, in dem Sie sich bei Ihrem Konto anmelden möchten, separat registriert werden.

In Zukunft werden weitere Möglichkeiten erwartet, mit denen der Benutzer die Verwendung plattformspezifischer Authentifikatoren aktivieren kann, z. B. durch Verwendung eines Gesichts-Scans oder durch Eingabe eines PIN-Codes vom Gerät.

Wenn Sie Anmeldeinformationen erstellen oder die Signatur berechnen, können Sie den bevorzugten Authentifizierungstyp in einem speziellen Parameter angeben, der zwei Werte annimmt - cross-platformund platform. In diesem Fall wird der Benutzer aufgefordert, nur einen der elektronischen Schlüsseltypen zu verwenden.

const credential = await navigator.credentials.create({
    publicKey: {
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform',
        },
        ...,
    },
});

WebAuthn-Vorteile


Was sind die Vorteile der WebAuthn-Technologie für Benutzer und Entwickler?

  • Der Benutzer muss sich keine Kennwörter merken und eingeben, und der Server speichert keine Benutzerkennwörter. Alle Mängel, die die Kennwörter hatten, sind verschwunden. Das Stehlen eines physischen Authentifikators von einem Benutzer ist viel schwieriger als das Abfangen eines Kennworts, das elektronisch über eine unsichere Verbindung übertragen wird, und ein Leck öffentlicher Schlüssel auf der Site öffnet den im Gerät versteckten privaten Schlüssel nicht.
  • origin , . origin . , (thesslstore.com, yubico.com) .
  • WebAuthn - . - web- , .
  • WebAuthn selbst als API bietet Entwicklern eine Abstraktion über die Implementierung von Authentifikatoren und ermöglicht es Ihnen, Code einmal zu schreiben, der dann mit allen Arten und Typen von elektronischen Schlüsseln funktioniert. Somit ist WebAuthn eine skalierbare Lösung für die Benutzerauthentifizierung.

Noch mehr darüber, warum WebAuthn sicherer ist als ein Passwort - WebAuthn für Entwickler: 5 Schritte zur besseren Authentifizierung , Erste Schritte mit Sicherheitsschlüsseln .

WebAuthn-Support


Ob die Dongle-Authentifizierung auf Ihrem Gerät funktioniert oder nicht, hängt von verschiedenen Faktoren ab. Angefangen davon, ob Ihr Browser die WebAuthn-API unterstützt, bis hin zu den Konnektoren auf Ihrem Computer und den von Ihrem Authentifikator unterstützten Kommunikationsmethoden. Die Leistung von WebAuthn hängt auch stark davon ab, welches Gerät und Betriebssystem Sie verwenden.

Laut caniuse.com wird die WebAuthn- API zum Zeitpunkt des Schreibens von 80,5% der Benutzer unterstützt. Laut Statistiken über Benutzer von Mail.ru hat diese Zahl die gleiche Reihenfolge - 79,8%. Um WebAuthn in all diesen Browsern verwenden zu können, benötigen Sie jedoch auf jeden Fall einen externen elektronischen Schlüssel.

Nicht alle Browser, die die WebAuthn-API unterstützen, können mit plattformabhängigen Schlüsseln arbeiten (der Einfachheit halber werde ich diese Schlüssel später als "Fingerabdrücke" bezeichnen). Um mit solchen Schlüsseln arbeiten zu können, reicht es nicht aus, einen Browser zu installieren, der mit ihnen arbeiten kann. Es ist auch erforderlich, dass Ihr Gerät und Ihr Betriebssystem über ein geeignetes Modul / einen geeigneten Sensor verfügen und mit diesem interagieren können. Von allen Mail.ru-Benutzern können nur 9,0% plattformspezifische Schlüssel hinzufügen.

Ich werde Ihnen kurz die Unterstützung von WebAuthn durch verschiedene Betriebssysteme und Browser erläutern.

Windows


Die WebAuthn-Unterstützung unter Windows ist sehr gut. Das Windows Hello-Authentifizierungssubsystem kann mit elektronischen Schlüsseln arbeiten. Daher unterstützen alle neuesten Browserversionen für dieses Betriebssystem - Microsoft Edge, Google Chrome, Opera und Mozilla Firefox - das Arbeiten mit Fremdschlüsseln und Fingerabdrücken. Internet Explorer API WebAuthn wird nicht unterstützt.


Linux


Externe Authentifikatoren werden normalerweise von modernen Linux-Distributionen sowie von Browsern wie Google Chrome, Chromium und Mozilla Firefox unterstützt. Auf einigen Systemen sind jedoch möglicherweise zusätzliche Einstellungen erforderlich , um mit Fremdschlüsseln arbeiten zu können .

Android


Die WebAuthn-Unterstützung für Android ist ebenfalls gut. Google Chrome, Opera und Mozilla Firefox - Unterstützung beim Arbeiten mit Fremdschlüsseln und Fingerabdrücken. Microsoft Edge für Android unterstützt die WebAuthn-API jedoch überhaupt nicht. Es gibt auch einen Fehler in Firefox - die Angabe des bevorzugten Authentifizierungstyps mithilfe der Option funktioniert nicht authenticatorAttachment.


iOS


Unter allen Browsern für das iOS-Betriebssystem unterstützt WebAuthn nur Mobile Safari Version 13.3. Außerdem kann er nur mit externen elektronischen Schlüsseln arbeiten. Andere Browser für iOS unterstützen WebAuthn noch überhaupt nicht.

Mac OS


Microsoft Edge, Google Chrome, Opera und Mozilla Firefox unterstützen das Arbeiten mit Fremdschlüsseln unter macOS. Google Chrome unterstützt auch Fingerabdrücke, sodass Sie WebAuthn mit Touch ID verwenden können.


Wenn in Edge, Opera und Chrome die Benutzeroberfläche für die Interaktion mit WebAuthn identisch ist, hat sich Firefox hier ausgezeichnet. Anstelle eines hübschen Popups in Firefox wird bei Verwendung von WebAuthn eine kleine Benachrichtigung in der Ecke des Bildschirms angezeigt. Wenn Sie versehentlich auf eine Seite klicken, wird diese einfach ausgeblendet, sodass der Benutzer nicht weiß, was gerade passiert.



Safari hat WebAuthn jedoch noch nicht unterstützt. Die Unterstützung von WebAuthn wurde in Safari 13 angekündigt, das unter macOS 10.15 Catalina verfügbar sein wird. Zum Zeitpunkt des Schreibens zeigten meine Überprüfungen jedoch, dass die WebAuthn-API in Safari, obwohl vorhanden, äußerst instabil ist und nicht mit allen Authentifikatoren funktioniert. Wie seine mobile Version funktioniert Safari nicht mit integrierten elektronischen Schlüsseln. Darüber hinaus werden noch keine elektronischen Fremdschlüssel unterstützt.

Daher haben wir festgestellt, dass WebAuthn neben Support-Problemen noch größere Unterschiede in der Benutzeroberfläche aufweist. Diese Unterschiede führen dazu, dass Sie dem Benutzer genauer erklären müssen, was von ihm verlangt wird, um den Eingang über elektronische Schlüssel nutzen zu können. Darüber hinaus können sich diese Popups mit jeder neuen Browserversion ändern, und der heutige Prozess der Verwendung von WebAuthn kann sich stark von dem von gestern unterscheiden.

Es ist klar, warum dies geschieht. Die WebAuthn-Technologie ist noch recht jung und Browserentwickler experimentieren noch mit verschiedenen Arten der Implementierung. Man kann nur hoffen, dass sich die Unterstützung für WebAuthn in Browsern im Laufe der Zeit stabilisiert und wir sie ohne Einschränkungen verwenden können.

Authenticator-Registrierung


Wenn wir dem Benutzer die Möglichkeit geben, verschiedene elektronische Schlüssel in seinem Konto zu registrieren, sollte er die Möglichkeit haben, deren Liste anzuzeigen und veraltete oder unnötige aus dieser zu entfernen. Dies kann beispielsweise im Falle eines Kompromisses eines der Schlüssel nützlich sein.

Die WebAuthn-API ist so konzipiert, dass dem Client beim Erstellen und Verwenden von Anmeldeinformationen keine Informationen zu Typ, Typ und Name der verwendeten Authentifikatoren zur Verfügung stehen. Dementsprechend haben wir keine Daten, anhand derer wir einen Schlüssel von einem anderen unterscheiden könnten. Alle Schlüssel in der Liste werden gleichermaßen angezeigt, ohne dass Merkmale unterschieden werden. Frage: Was tun?


Sie können einige Informationen über den verwendeten Authentifikator erhalten, wenn Sie beim Erstellen von Anmeldeinformationen die sogenannten Anmeldeinformationen anfordern. Zertifizierung. Die Zertifizierung ist eine Möglichkeit für einen Authentifizierer, seine Authentizität gegenüber einem Server nachzuweisen. In einigen Fällen erhalten Sie Informationen über den Schlüsselhersteller aus der Zertifizierung. Im allgemeinen Fall reichen die verwendeten Daten jedoch immer noch nicht aus, um einen mit einem Konto verknüpften elektronischen Schlüssel klar von einem anderen zu unterscheiden.

const credential = await navigator.credentials.create({
    publicKey: {
        attestation: 'direct',
         ...,
    },
});

Daher geben wir dem Benutzer nach dem Verbinden des Schlüssels mit dem Konto in Mail die Möglichkeit, dem neu erstellten Datensatz einen Namen zuzuweisen. Und schon weiter kann der Benutzer einen Schlüssel durch diesen Namen von einem anderen unterscheiden.

Die Tatsache, dass die Informationen, die dem Client und dem Server zur Verfügung stehen, keine Daten über den Typ des Authentifikators enthalten, führt zu einer weiteren unangenehmen Funktion von WebAuthn.

Stellen Sie sich einen Benutzer vor, der seinem Konto beispielsweise in seinem Smartphone nur einen Fingerabdruck hinzugefügt hat. Wenn wir uns mit der WebAuthn-API anmelden möchten, übergeben wir einen Funktionsaufrufnavigator.credentials.getListe aller mit einem Konto verknüpften Schlüssel. Der Browser kann anhand dieser Liste jedoch nicht feststellen, welche der Authentifikatoren auf dem Gerät vorhanden sind und welche nicht. Daher ist er gezwungen, dem Benutzer immer die Verwendung von WebAuthn anzubieten.

Selbst wenn Sie versuchen, sich bei einem Konto auf einem Computer anzumelden, der die Authentifizierung durch Fingerabdrücke nicht unterstützt, wird dem Benutzer daher weiterhin die Verwendung von WebAuthn angeboten.

Um in solchen Situationen das richtige Verhalten zu implementieren, müssen Sie den WebAuthn-Standard selbst verfeinern. Zum Beispiel, um Informationen darüber zu verschlüsseln, ob ein plattformübergreifender Schlüssel oder ein Fingerabdruck zum Erstellen verwendet wurde, und um dem WebAuthn-Benutzer keine Informationen anzubieten, wenn im Voraus bekannt ist, dass er ihn nicht verwenden kann.

In einigen Situationen gibt es Möglichkeiten, dieses Verhalten zu umgehen. Ermöglichen Sie dem Benutzer beispielsweise, Fingerabdrücke und physische Schlüssel nur einzeln zu registrieren. Filtern Sie bei der Verwendung von Schlüsseln Fingerabdrücke auf Geräten, die diese offensichtlich nicht unterstützen. Diese Methode löst das Problem jedoch nicht vollständig. Und es gibt keinen zuverlässigen Weg, um dieses Problem zu lösen.

Unsere Benutzer haben noch keine Beschwerden über dieses Verhalten erhalten. Daher untersuchen wir derzeit diese Funktion und entscheiden, was in Zukunft zu tun ist.

WebAuthn arbeitet an verschiedenen Subdomains


Wie ich bereits sagte, bietet WebAuthn einen sofortigen Schutz vor Phishing. Bei der Registrierung elektronischer Schlüssel werden Informationen gespeichert, originauf denen dieser Schlüssel registriert wurde. WebAuthn erlaubt nicht die Verwendung dieses elektronischen Schlüssels für Ressourcen mit anderen origin.

Große Webdienste wie Mail.ru verwenden häufig mehrere unterschiedliche Domänen für ihre Arbeit. Zum Beispiel haben wir eine Domain e.mail.rufür Mail und cloud.mail.rufür die Cloud. Und für jeden von ihnen haben wir eine gemeinsame Form der Autorisierung. In diesem Fall reichen die Standardeinstellungen für WebAuthn nicht aus. Damit wir die originauf der anderen Seite registrierten Schlüssel auf einer verwenden können origin, müssen diese beiden Domänen ein gemeinsames Suffix haben (eine gemeinsame Unterdomäne von mehr als der ersten Ebene).

Zum Beispiel bei Domainse.mail.ruund das cloud.mail.rugemeinsame Suffix ist mail.ru.

In diesem Fall können wir bei der Registrierung und Verwendung elektronischer Schlüssel einen rpIdgleichen Parameter in den Anforderungsoptionen angeben mail.ruund dann denselben Schlüssel für den Unterschlüssel selbst https://mail.ruund für jede seiner Unterdomänen verwenden.

const credential = await navigator.credentials.create({
    publicKey: {
        rp: {
            name: 'Mail.ru Group',
            id: 'mail.ru',
        },
        ...,
    },
});

WebAuthn arbeitet im Iframe


Aus Sicherheitsgründen ist das Aufrufen von WebAuthn-Methoden aus originenübergreifenden Iframes verboten. Unsere Projekte verwenden ein einziges Autorisierungsformular, das sich unter https://account.mail.ru/login befindet. Wenn wir das Autorisierungsformular für ein anderes Projekt anzeigen möchten, z. B. in Mail oder in der Cloud, wird der Seite tatsächlich ein Iframe hinzugefügt innerhalb dessen sich diese URL öffnet. Mit dieser Lösung können wir das Formular selbst für alle Projekte, die es verwenden, gleichzeitig aktualisieren, die Erfassung von Statistiken vereinfachen und die Benutzeroberfläche des Benutzers verbessern, sodass er auf demselben Dienst bleiben kann, auf dem er ursprünglich war.



In unserem Fall haben wir aufgrund der Einschränkung der Aufrufe von WebAuthn-Methoden innerhalb des Iframes nach Möglichkeiten gesucht, dies zu umgehen, da wir die Möglichkeit geben wollten, uns über WebAuthn überall dort anzumelden, wo wir das Autorisierungsformular anzeigen.

Was haben wir getan. Um das Autorisierungsformular für alle Dienste zu öffnen, verwenden wir eine kleine Bibliothek, die im Wesentlichen nur einen Iframe auf der Seite mit der richtigen URL erstellt und nach dem Laden des Inhalts den Iframe auf der Seite anzeigt. Diese Bibliothek unterstützt die Kommunikation mit Iframes über postMessageund verwendet sie beispielsweise, um die Größe von Iframes zu ändern, wenn die Größe des Inhalts geändert wird.

Wir haben den folgenden Mechanismus entwickelt und implementiert:

  1. In der Autorisierungsanwendung bestimmen wir bei Verwendung von WebAuthn, ob wir jetzt im iframe geöffnet sind oder nicht.
  2. Wenn wir innerhalb des Iframes geöffnet sind, serialisieren wir die Aufrufparameter, anstatt die Browser-API WebAuthn aufzurufen, und senden sie über das postMessageübergeordnete Fenster.
  3. Im übergeordneten Fenster deserialisieren wir diese Parameter und rufen die WebAuthn-Methoden auf.
  4. Wenn wir eine Antwort erhalten, serialisieren wir sie auf die gleiche Weise und senden sie durch das postMessageInnere eines Iframes, wo wir diese Antwort akzeptieren und die weitere Verarbeitung durchführen.

Daher haben wir dieses Verbot umgangen und die Möglichkeit erkannt, bei der Autorisierung in allen Diensten des Unternehmens denselben Schlüssel zu verwenden.

WebAuthn Test Automation


In unserem Team für alle neuen Projekte und Funktionen schreiben wir immer Autotests für die Integrations-Benutzeroberfläche mit selenähnlichen Lösungen und dem WebDriver-Protokoll. Während der Entwicklung von WebAuthn stellte sich daher die Frage, wie die Benutzeroberfläche für Autotests darauf geschrieben werden soll.

Die Schwierigkeit beim Schreiben solcher Autotests besteht darin, dass das WebDriver-Protokoll noch keine Methoden zur Automatisierung der Interaktion mit WebAuthn enthält. Und im Standard selbst gibt es immer noch keine Unterstützung für das Testen der WebAuthn-API für die Automatisierung (es gibt jedoch ein Problem zu diesem Thema). Die ersten Ideen, wie diese Automatisierung organisiert werden kann, werden in einem Entwurf der Webauthentifizierung beschrieben: Eine API für den Zugriff auf Anmeldeinformationen für öffentliche Schlüssel der Stufe 2, die noch nicht veröffentlicht wurde, ganz zu schweigen davon, dass sie an anderer Stelle unterstützt wird. Deshalb musste ich alternative Lösungen finden.

weil Wir können nicht mit der nativen Implementierung von WebAuthn-Funktionen in Autotests arbeiten (es gibt keine Methoden zur Steuerung des Browsers), dann mussten wir Folgendes tun.

Bevor wir versuchen, WebAuthn zu verwenden, patchen wir irgendwo im Autotest die globalen Hostobjekte des Browsers und ersetzen die nativen Funktionen durch unsere Implementierungen. Hier speichern wir die Argumente, mit denen die nativen Funktionen aufgerufen wurden, in einer Variablen und geben das Versprechen zurück.

//    WebAuthn   
navigator.credentials.create = (options) => {
    window.credentialsCreateArgs = options;

    return new Promise((resolve, reject) => {
        window.credentialsCreateSuccess = resolve;
        window.credentialsCreateFail = reject;
    });
};

Als nächstes müssen wir irgendwie das Ergebnis der Funktion erhalten, um es zurückzugeben und die Arbeit von WebAuthn in den Tests zu emulieren. Wir können immer eine Art konstante fest codierte Antwort zurückgeben.

// -    
const credentialsCreateResponse = { /* constant object */ };

window.credentialsCreateSuccess(credentialsCreateResponse);

In diesem Fall müssen wir unserem Server beibringen, diese Antwort zu akzeptieren und nicht zu validieren, sondern sie automatisch als korrekt zu betrachten.

Was sind die Nachteile solcher Tests? In diesem Fall können wir nicht:

  • Überprüfen Sie, ob der Client Parameter korrekt formt und in WebAuthn-Funktionen einfügt.
  • Überprüfen Sie die Richtigkeit der Backend-Änderungen, wenn Sie Backend-Releases rollen.

Daher sind solche Tests nicht zuverlässig genug, und dies passt nicht zu uns.

Wir haben uns für den schwierigeren Weg entschieden und deshalb unsere eigene Implementierung von FIDO2-Protokollen und -Algorithmen auf Node.js geschrieben, mit deren Hilfe wir es geschafft haben, diese Funktionen so nah wie möglich an den nativen Implementierungen zu sperren.

Das heißt, wir haben eine Funktion geschrieben, die basierend auf den Anforderungsparametern die Antwort für die gesperrten WebAuthn-Funktionen berechnet, sodass der Server sie als vollständig korrekt betrachtet.

// -    
const credentialsCreateResponse =
    calcCredentialsCreateResponse(window.credentialsCreateArgs);
 
window.credentialsCreateSuccess(credentialsCreateResponse);

Infolgedessen lautet das Autotest-Betriebsschema wie folgt:

  1. Holen Sie sich die Argumente, mit denen die WebAuthn-Methoden aufgerufen wurden.
  2. Wir führen diese Argumente durch eine Funktion, die dieselben Algorithmen wie in echten Authentifikatoren implementiert.
  3. Wir erhalten das Ergebnis und geben es von unseren ersetzten Funktionen zurück.
  4. Der gesamte Rest des Codes in unserem Service verarbeitet diese Antworten im üblichen Modus. Infolgedessen unterscheidet sich das gesamte Verhalten des Service nicht von seinem Verhalten für echte Benutzer.

Die Quellen eines solchen Autotests und die Implementierung des verdecktesten Authentifikators befinden sich im Github-Repository . Sie können ihre Arbeit später starten und untersuchen. Beim Schreiben des Authentifikators wurden wir nur von der w3.org- Spezifikation und der Node.js-Dokumentation geleitet.

Die Gegenwart und Zukunft von WebAuthn


Also was haben wir im Moment. Ende September 2019 haben

wir eine voll funktionsfähige elektronische Schlüsseleingabe eingeführt. Jetzt machen wir keine Werbung für diese Art von Eintrag und sie wird nicht sehr aktiv verwendet - weniger als hundert eindeutige Benutzer pro Tag. Wir sind jedoch zuversichtlich, dass ihre Anzahl mit der Zeit nur noch zunehmen wird und früher oder später die elektronische Schlüsselprotokollierung zu einer der Hauptarten der Protokollierung in Ihrem Konto wird.

Was uns davon abhält, einen solchen Eintrag aktiv zu bewerben, ist, dass WebAuthn selbst in Browsern immer noch nicht zuverlässig und stabil genug ist und es viele Nuancen hinsichtlich seiner Unterstützung und Funktionsweise gibt.

Warum ist WebAuthn jetzt eine Funktion, die nicht für ein breites Publikum geeignet ist?

Der grundlegendste Faktor hierbei ist, dass der Benutzer ein spezielles Gerät haben muss - einen elektronischen Schlüssel. Jetzt ist die Notwendigkeit dafür von den Benutzern nicht so akut zu spüren. Viele Benutzer sind sich ihrer Existenz nicht bewusst. Mit der Zeit wird jedoch auch die Anzahl der Benutzer mit solchen Schlüsseln zunehmen, wenn immer mehr Dienste diese Art der Anmeldung unterstützen.

Ein bedeutender Fortschritt in der Popularität von WebAuthn kann eintreten, wenn Google-Ingenieure die Entwicklung und Erprobung der Möglichkeit der Verwendung von Smartphones unter Android und iOS als externe physische elektronische Schlüssel für WebAuthn abschließen und diese Möglichkeit für alle Internetdienste eröffnen. In diesem Fall hat jeder Besitzer eines modernen Smartphones im Wesentlichen die Möglichkeit, es als WebAuthn-Schlüssel zu verwenden, und die Anzahl der WebAuthn-Benutzer steigt dramatisch an. Diese Funktion steht jetzt nur Nutzern des Google-E-Mail-Dienstes zur Verfügung.



Wie können Sie WebAuthn sonst noch verwenden?


Mail.ru verwendet WebAuthn jetzt als Alternative zu Passwörtern für die Eingabe des Kontos. Im Wesentlichen kann WebAuthn jedoch wie jeder der Autorisierungsfaktoren verwendet werden. Es kann anstelle des ersten Faktors bei der Ein-Faktor-Authentifizierung verwendet werden. Also statt der zweiten - als zusätzlicher Passwortschutz mit Zwei-Faktor. Darüber hinaus kann die Bestätigung über einen elektronischen Schlüssel verwendet werden, um beispielsweise den Zugriff auf ein Konto wiederherzustellen, wenn der Benutzer sein Passwort verloren oder vergessen hat.

WebAuthn kann als zusätzliche Sicherheitsmaßnahme beim Bearbeiten kritischer Einstellungen Ihres Kontos verwendet werden. Stellen Sie sich vor, wie bequem es ist - Sie gehen zu den Profileinstellungen in Ihrem bevorzugten Dienst und müssen sich kein Passwort merken und eingeben, um sie zu ändern! Legen Sie einfach Ihren Finger auf den Fingerabdruckscanner und Sie werden weitergeleitet.

In diesem Artikel finden Sie noch mehr verschiedene Szenarien für die Verwendung von WebAuthn .

Beliebte Fragen und Antworten


Wo kann ich einen elektronischen Schlüssel kaufen?


Bisher gibt es in Russland nicht viele Orte, an denen Sie elektronische Schlüssel erwerben können, die mit FIDO2-Protokollen kompatibel sind. Die meisten Lieferanten verkaufen sie nur in loser Schüttung, in Chargen von 10 oder mehr. Sie können elektronische Schlüssel Stück für Stück in folgenden Geschäften kaufen:


Solche Schlüssel können auch in freundlichen Online-Shops bestellt werden, beispielsweise bei Amazon . In diesem Artikel gibt es vergleichende Eigenschaften von Modellen mit elektronischen Schaltern 10 mit Links zu Geschäften, in denen sie gekauft werden können.

Was ist, wenn ich meinen elektronischen Schlüssel verliere?


Mit elektronischen Schlüsseln sollten Sie sie mit der gleichen Aufmerksamkeit behandeln wie mit den Schlüsseln für die Wohnung oder das Auto. Wenn wir die Schlüssel für die Wohnung verlieren, ändern wir normalerweise das Schloss und bekommen neue Schlüssel. Das Gleiche gilt für elektronische Schlüssel: Wenn sie verloren gehen, sollten Sie sie sofort von allen Konten entfernen, mit denen sie verknüpft waren, und allen Konten einen neuen Authentifikator hinzufügen.

Im Falle des Verlusts des elektronischen Hauptschlüssels sollten Sie über mehrere zusätzliche Authentifizierungsmethoden verfügen. Verwenden Sie beispielsweise die Anwendung zum Generieren von Codes oder einen Ersatzschlüssel, der an einem besonders geschützten Ort aufbewahrt werden kann: in einem Safe oder in einer Bankzelle.

Was soll ich tun, wenn jemand anderes Zugriff auf meinen elektronischen Schlüssel erhält?


Wenn die Zwei-Faktor-Authentifizierung in Ihrem Konto enthalten ist und der elektronische Schlüssel nur einer der Faktoren ist, ist Ihr Konto in diesem Fall vor Hacking geschützt. Es sei denn, der Angreifer hat Zugriff auf den zweiten Faktor.

Wenn der elektronische Schlüssel der einzige Faktor ist, der ausreicht, um das Konto zu betreten, muss der Angreifer auch in diesem Fall den Namen des Kontos kennen, in dem dieser elektronische Schlüssel registriert ist. Diese Informationen werden nicht im elektronischen Schlüssel gespeichert, und daher ist ein versehentlich verlorener elektronischer Schlüssel mit hoher Wahrscheinlichkeit für einen Passanten, der ihn gefunden hat, völlig nutzlos.

Es gibt jedoch Schemata, bei denen elektronische Schlüssel nicht nur als Ersatz für ein Passwort, sondern auch für ein Login verwendet werden können. In diesem Szenario stellt der Server nur Anmeldeinformationen bereit, wenn Anmeldeinformationen angefordert werden.originund die Anmeldeinformationen selbst werden vollständig im Authentifikator gespeichert. In diesem Fall kann der verlorene elektronische Schlüssel bereits problemlos zur Eingabe Ihres Kontos verwendet werden. Dann sollten Sie mit Ihrem Authentifikator vorsichtiger sein. Zum Schutz in solchen Szenarien können Sie elektronische Schlüssel mit zusätzlichen Sicherheitsmaßnahmen verwenden, z. B. Schlüssel, für deren Aktivierung Sie einen PIN-Code eingeben müssen.

Sobald Sie den Verlust Ihres Schlüssels bemerken, sollten Sie ihn in jedem Fall sofort von allen Konten in allen Diensten trennen, in die Sie ihn eingeben können. Aus diesem Grund sollten alle Dienste die Möglichkeit bieten, eine Liste gebundener Authentifikatoren zu verwalten. Je schneller Sie den Verlust bemerken, desto weniger Zeit haben die Angreifer, um auf Ihre Daten zuzugreifen.

Jetzt werden meine biometrischen Daten auf Mail.ru/Google/Microsoft-Servern gespeichert?


Wenn WebAuthn mit integrierten Authentifikatoren arbeitet (z. B. mit Touch ID unter Mac OS), haben nur der entsprechende Sensor und das Betriebssystem selbst Zugriff auf Ihre biometrischen Daten. Der Webdienst empfängt oder verarbeitet keine biometrischen Informationen, sondern arbeitet nur mit dem öffentlichen kryptografischen Schlüssel und mit Daten, die mit dem privaten Schlüssel signiert sind.

Auf dem Server selbst werden nur Informationen zum öffentlichen Schlüssel gespeichert. Daher verwendet WebAuthn Ihre biometrischen Daten in keiner Weise, um mit integrierten Authentifikatoren zu arbeiten.

Fazit


Wie wir herausgefunden haben, hat WebAuthn viele wichtige Vorteile gegenüber Passwörtern:

  • Bei Verwendung von WebAuthn ist es nicht erforderlich, sich Kennwörter zu merken und einzugeben.
  • WebAuthn - , ;
  • WebAuthn ;
  • WebAuthn — .

Passwörter sollten jedoch nicht verworfen werden. Ein physischer Schlüssel kann immer noch gestohlen werden oder verloren gehen, genau wie ein Passwort. Passwörter haben jedoch einen wichtigen Vorteil. Solange sie nur im Kopf gespeichert sind , können sie sie ohne Wissen des Eigentümers nicht erkennen.

Zusammenfassend möchte ich sagen, dass die WebAuthn-Technologie eine sehr vielversprechende Technologie ist, die ein so grundlegendes und wichtiges Element der Funktionsweise aller modernen Webdienste wie die Authentifizierung verändert. Es ist auch eine ziemlich junge Technologie und die Benutzer sind noch nicht daran gewöhnt. Aber es liegt in unserer Macht, es populärer und bequemer zu machen.

Ich hoffe, unsere Erfahrung mit der Implementierung von WebAuthn in Mail.ru Mail wird Ihnen helfen, es in Ihren Diensten zu unterstützen, und gemeinsam werden wir das Internet sicherer und moderner machen!

Zusätzliche Materialien



All Articles