Webauthentifizierung mit PKI-Zertifikaten

Ich verstehe PKI aus konzeptioneller Sicht ziemlich gut - dh private Schlüssel / öffentliche Schlüssel - die Mathematik dahinter, die Verwendung von Hash & Verschlüsselung zum Signieren eines Zertifikats, das digitale Signieren von Transaktionen oder Dokumenten usw. Ich habe auch an Projekten gearbeitet, in denen openssl C-Bibliotheken wurden mit Zertifikaten zur Sicherung der Kommunikation und Authentifizierung verwendet. Ich bin auch sehr vertraut mit OpenSSL-Kommandozeilen-Tools.

Ich habe jedoch sehr wenig Erfahrung mit webbasierten PKI-fähigen Projekten und versuche daher, ein persönliches Projekt zu entwerfen und zu programmieren, um dies besser zu verstehen.

Die Anforderungen

Dies ist die Website für eine Bank. Alle Internet-Banking-Benutzer dürfen alle Zertifikate verwenden, die von einigen bekannten Zertifizierungsstellen ausgestellt wurden (Verisign, Thawte, Vertrauen usw.). Die Bank ist nicht für die Beschaffung von Zertifikaten für den Benutzer verantwortlich. Diese Zertifikate werden zur Authentifizierung gegenüber der Bank-Website verwendet. Die Plattformen / OS usw. sind noch nicht behoben.

Design

Ich habe mich gefragt, wie ich am besten authentifizieren kann.

1. Ich habe gesehen, dass Apache eine Möglichkeit bietet, 2-Wege-SSL zu aktivieren. In diesem Fall würde der Benutzer bei der Navigation zur Website automatisch nach einem Zertifikat gefragt. Ich bin mir jedoch nicht sicher, ob dies ausreicht, da anscheinend nur überprüft wird, ob ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert ist und möglicherweise auch in eine weiße Liste mit Betreffzeilen der Zertifikate usw. fällt. Dies ist jedoch nicht ausreichend für einen Bankfall, weil Sie in der Lage sein müssen, eine Bankbenutzer-ID mit einem Zertifikat zu verknüpfen.

2. IIS scheint eine Möglichkeit zu haben, mit der ich ein Zertifikat für jeden Benutzer in Active Directory speichern kann. Das habe ich verstanden, als ich einige MSDN-Artikel gelesen habe. Sie aktivieren 2-Wege-SSL in IIS. Wenn der Benutzer versucht, zur Website zu navigieren, sendet IIS eine Anforderung mit einer Liste der genehmigten Zertifizierungsstellen an den Browser. Der Browser lässt den Benutzer ein geeignetes Zertifikat aus seinem Zertifizierungsspeicher auswählen und sendet es zum Backend. Ich gehe davon aus, dass IIS zwei Dinge tun wird

   • Stellen Sie sicher, dass der Benutzer über den privaten Schlüssel verfügt, der dem Zertifikat entspricht (im Rahmen der Deckungsverhandlungen).
   • Basierend auf der AD User-Cert-Zuordnung meldet IIS den Benutzernamen an die Anwendung.

3. Führen Sie die Authentifizierung explizit durch, indem Sie Kryptofunktionen aufrufen, je nachdem, welcher Webserver dies ausführt.

   • Zeigen Sie einen Benutzerbildschirm an, auf dem er ein Zertifikat hochlädt und die Anwendung sicherstellt, dass der Benutzer über den dem Zertifikat entsprechenden privaten Schlüssel verfügt (indem Sie das Front-End auffordern, eine Zeichenfolge mit dem Zertifikat zu signieren).
   • Die Anwendung verfügt über eine Datenbank, in der einige Daten gespeichert sind, die es jedem Benutzer ermöglichen, seiner Benutzer-ID zugeordnet zu werden. Das mag sein
   • Das gesamte Zertifikat, das jeder Benutzer-ID entspricht
   • Die Seriennummer der Zertifizierungsstelle und des Zertifikats für jede Benutzer-ID.

Ich habe mich gefragt, welche Methode am häufigsten angewendet wird. Was sind die Best Practices? Wenn ich mit # 3 gehen sollte, was sind die besten Möglichkeiten, dies zu tun?

Etwas, das auch mit Smartphone-Apps problemlos funktioniert, ist ein zusätzlicher Bonus.

Aktualisieren

Lassen Sie mich meine Aussage "den Authentifizierungsteil selbst codieren" klarstellen, da einige der Antworten darauf hindeuten, dass er missverstanden wurde - mein Nachteil, dass ich nicht klar bin.

Das heißt nicht, dass ich selbst Kryptomaterial schreibe. Es bedeutet nur, dass ich Kryptoroutinen explizit aufrufen werde, anstatt dies implizit abhängig von IIS oder einem anderen Webserver zu tun.

Ich wollte wirklich Ausgabe für Ausgabe antworten, aber ich denke, ich werde dieses Thema thematisch behandeln:

Autorisierung / Authentifizierung

OK, das Wichtigste zuerst. Für Ihr Beispiel benötigen Sie beide:

• Authentifizierung - Beweis, dass der Benutzer der ist, von dem er sagt, dass er er ist. Sie haben PKI ausgewählt, mit dem implizierten Nachweis des privaten Schlüssels als Authentifizierung.
• Autorisierung - Verbindung des Benutzers mit dem, was er tun darf. Dies ist der Verbindungspunkt zwischen der Anmeldung und dem Zugriff auf die zulässigen Konten. Die Zuordnung von Zertifikat zu Konto und Kontozugriffsfunktionen ist die Autorisierung.

In Bezug auf die Autorisierung haben Sie das Problem, den Vorgang zu ermitteln, mit dem Sie die Betreff-DN Ihres Benutzers mit dessen Bankkonto verbinden. In Anbetracht der Schwere der Transaktion möchten Sie auf jeden Fall einen starken Prozess dafür haben, und es gibt hier keinen einzigen richtigen Weg. Sie müssten sich mit der Bank beraten, und wahrscheinlich sind es Anwälte, um herauszufinden, wie dies in Übereinstimmung mit den Richtlinien geschehen soll.

SSL, Client / Server-Authentifizierung, Nachweis des privaten Schlüssels

Das SSL-Protokoll umfasst immer die Serverauthentifizierung mit einer zusätzlichen optionalen Einstellung für die clientseitige Autorisierung. Mit der Nummer 1 liegen Sie richtig, da Apache eine Einstellung anbietet, die die Clientauthentifizierung durch PKI hinzufügt, und Sie können eine Liste vertrauenswürdiger Zertifizierungsstellen bereitstellen. Während der Einrichtung einer SSL-Sitzung, für die eine Clientauthentifizierung über PKI erforderlich ist, erhalten Sie einen Nachweis über den privaten Schlüssel.

Entweder Option 1 oder Option 2 bietet dies - sowohl Apache als auch IIS können auf diese Weise konfiguriert werden. In Bezug auf bewährte Methoden würde ich eine davon übernehmen, um Ihre eigene Lösung zu entwickeln. # 3 kommt der Regel "Schreiben Sie keine eigene Krypto" gefährlich nahe. Angenommen, Sie können Ihre Transaktion an das Vorhandensein einer authentifizierten SSL-Sitzung binden, dann gibt es keinen Grund, eine eigene zu erstellen.

Außerdem haben Sie in Option 1 oder Option 2 die Möglichkeit, das gesamte Zertifikat und von dort aus einen beliebigen Teil des Zertifikats in den Händen zu halten. In der Regel werden die Subjekt-DN und / oder die Zertifikatseriennummer verwendet, um die Identität des Benutzers für Autorisierungszwecke zu bestimmen.

In Bezug auf die "gemeinsame Nutzung" sind alle wichtigen Webserver ziemlich verbreitet. IIS, Apache, Tomcat und viele andere können mit Client-Authentifizierungs-SSL konfiguriert werden. Die Entscheidung von dort basiert größtenteils auf der Gesamtumsetzung. Die wichtigsten Webserver hatten alle Möglichkeiten, auf das in der SSL-Sitzung bereitgestellte Zertifikat zuzugreifen. Dies ist für eine detailliertere Überprüfung erforderlich.

Zertifikatsüberprüfungs-Add-Ons

Zumindest müssen Sie:

• Richten Sie eine SSL-Sitzung ein
• Zertifikat ziehen (die meisten Webserver prüfen die Signatur des Zertifikats und den Nachweis des privaten Schlüssels)
• Überprüfen Sie das Gültigkeitsdatum des Zertifikats (bei keinem Webserver angegeben)
• Führen Sie die Berechtigungsprüfung durch, auf welche Konten dieses Zertifikat zugreifen kann

Angesichts des hohen Bankeinsatzes möchten Sie möglicherweise auch den Sperrstatus des Zertifikats überprüfen. Wenn der private Schlüssel des Benutzers verloren geht oder gestohlen wird, sollte das Zertifikat gesperrt werden.

IIS hat möglicherweise die Haken für eine OCSP- oder CRL-Überprüfung - es handelt sich in der Regel um ein umfassenderes System (Hand-Holding!), Aber ich erinnere mich nicht ganz sicher. Ich erinnere mich auch nicht, ob Sie dazu gezwungen werden, Microsoft-Produkte zu verwenden. Für Apache müssten Sie mit ziemlicher Sicherheit eine OCSP / CRL-Prüfung codieren oder hinzufügen. Ich glaube, es hat Hooks beim Aufbau einer SSL-Sitzung - normalerweise wird diese Prüfung einmal beim Aufbau der SSL-Sitzung durchgeführt.

Genehmigung

Bei Nummer 1 und Nummer 2 haben Sie Recht, dass in IIS einige Funktionen integriert sind, die das in der SSL-Sitzung bereitgestellte Zertifikat an ein AD-Repository binden. Dies ist einer der Fälle, in denen Microsoft sich besonders anstrengt, um den Kauf und die Verwendung weiterer Produkte zu vereinfachen. :) Es gibt Nuancen, wie sich IIS mit AD verbindet, die sich dem Rahmen dieser Frage und meiner unmittelbaren Erinnerung entziehen. Ich habe ein paar ziemlich verrückte Sachen mit IIS und AD gemacht, und meine allgemeine Meinung ist, dass es Ihnen wahrscheinlich gut geht, wenn Sie etwas relativ Einfaches tun, wie den Benutzernamen basierend auf dem Zertifikat aus einem AD-Repository zu ziehen. Wenn Sie sich mit komplexeren Fragen der Datenspeicherung, ungewöhnlichen AD-Suchen und besonders verrückten (aber legitimen) Dingen bei PKI befassen,

Mit IIS müssen Sie Ihrer AD-Struktur noch etwas hinzufügen oder den Benutzernamen an ein Bankkonto binden. In der Regel verfügt ein Benutzer im Bankgeschäft über mehrere Konten. Und 2 Benutzer können ein gemeinsames Konto haben, so dass dies eine Beziehung von vielen zu vielen ist.

Für # 1 - yep müssen Sie Ihre eigene Suche schreiben. Sie müssen Folgendes codieren: - Eine Datenbank- oder LDAP-Hierarchie, die das Zertifikat mit dem Benutzer und den Benutzern mit den Bankkonten des Benutzers verbindet. Der garantierte eindeutige Teil eines Zertifikats ist Seriennummer + Aussteller-DN. Oft funktioniert Subject DN, aber es ist nicht in allen PKI-Systemen garantiert.

Das ist in der Regel so, wie Entwickler, die PKI für die High-End-Authentifizierung mit Apache verwenden, es tun. Nachdem ich in einer Reihe dieser Systeme gearbeitet habe, muss ich noch auf einen Fall der einfachen Wiederverwendung von Berechtigungen stoßen, daher sehe ich das nie wirklich als ein großes Minus - ich muss mich in beiden Fällen auf etwas spezialisiert haben, wie es Rollen / Berechtigungen sind nie einfach.

Dies klingt nach einer Mischung aus Nr. 1 und Nr. 3 - ich rate Ihnen dringend, die nativen Funktionen der Anwendung / des Webservers zu verwenden, die Sie zum Generieren der SSL-Sitzung verwenden. Dadurch kann der Browser das Server-Setup mit der Zertifikatsabfrage auf die übliche, bewährte Weise durchführen. Von dort aus müssen Sie mit Apache ein eigenes Autorisierungssystem einrichten. IIS bietet Microsoft eine Vorstellung davon, wie dies für Sie funktionieren sollte.

Bekannte Fallstricke

Führen Sie eine Reihe von Browsertests durch. Von Jahr zu Jahr, von Browser zu Browser, finde ich Fallstricke bei der Behandlung von SSL-Sitzungen. Das richtige Verketten der SSL-Sitzung mit der Reihe von Webseitenanforderungen und das Sicherstellen, dass das Abmelden richtig gehandhabt wird, sind die Hauptproblembereiche. Und es hat viel mit dem Server und der Browser-Software zu tun. SSL ist stabil genug, dass es normalerweise funktioniert, wenn es funktioniert, obwohl es IE gegen alle anderen Probleme geben kann.

Insbesondere das letzte Mal, als ich dies tat, war die Frage der Force-Codierung und des Sitzungs-Timeouts eine große Sache.

Smartphones

Gut. Glück. ist ungefähr alles, was ich sagen kann. Ich bin überhaupt kein Entwickler von mobilen Apps, aber bisher habe ich den Eindruck, dass der Umgang mit PKI-Zertifikaten auf einem durchschnittlichen Smartphone unter- oder nicht vorhanden ist.

Ich würde mich so gerne irren.

Persönliche Zertifikate eignen sich gut für die regelmäßige Erneuerung von Zertifikaten (was einen recht robusten Prozess darstellt) und können als "kennwortlose" Authentifizierung implementiert werden, die Kunden mögen

aber wo es scheitert ist

• Die Kosten pro Zertifikat
• Kompatibilität mit modernen Browsern
• Endbenutzer, die Zertifikate extrahieren und private Schlüssel unsicher speichern

Beachten Sie, dass moderne persönliche Zertifikate mit Sha-2-Signatur nicht mit Safari auf dem iPad und vielen modernen Browsern funktionieren. Dies liegt daran, dass persönliche Zertifikate nie wirklich so gestartet wurden, wie es die Organisationen der Zertifizierungsstellen dachten. Das Ausstellen von 30.000 Zertifikaten (was wir tun) kostet ungefähr dasselbe pro Zertifikat wie einige Hardware-Token-Typen.

Ihre Strategie, Kunden zu ermöglichen, ihre eigenen Zertifikate zu finden, ist nicht wirklich gültig. Es ist heutzutage schwierig, Anbieter von persönlichen Zertifikaten zu finden, und sie sind recht teuer. Sie müssen sicherstellen, dass der Geschäftsfall funktioniert, da sich die Kunden sonst einfach nicht darauf einlassen.

Okay, hier ist viel los. Das Wichtigste zuerst: Die Clientzertifizierungsauthentifizierung ist nutzlos, wenn sie auf dem Endpunkt nicht unterstützt wird. Wir haben also einen großartigen Beitrag von Intrepidus, der die Grundlagen der Client-Authentifizierung für Smartphone-Apps behandelt .

Als nächstes möchte ich Ihnen dringend empfehlen, Ihre eigene Authentifizierungsroutine nicht zu codieren. Es gibt viele großartige, geprüfte Bibliotheken, die damit umgehen. Sie sparen sich Funktions- und Sicherheitslücken, indem Sie eine ausgereifte Bibliothek für die Authentifizierung verwenden. Die Verwendung einer geprüften, ausgereiften Bibliothek wäre auf jeden Fall die beste Vorgehensweise.

Als nächstes wird empfohlen, ein Verzeichnis für die Behandlung Ihres Clients zu verwenden: die Zertifikatzuordnung. Sie sehen sich also AD oder LDAP an. Wie Sie bereits erwähnt haben, machen Windows und IIS dies für Sie sehr nahtlos. IIS.net hat einen guten Überblick über die Konfiguration der Zertifikatszuordnung unter IIS .

Wenn Sie mit Apache arbeiten, ist dies nicht so einfach. Es sieht so aus, als würde mod_authz_ldap Client-Zertifikate zuordnen , aber ich habe nicht persönlich damit gearbeitet.

Das bringt uns zu der Logistik, so etwas tatsächlich umzusetzen. Sie signieren die Benutzerzertifikate nicht. Daher benötigen Sie einen ironclad-Prozess, damit ein Benutzer sein Zertifikat einreicht und Ihre App es im Verzeichnis veröffentlicht. Ich würde zwei Faktoren dafür sehen wollen, mit einer Passwortauthentifizierung und einer Textnachricht oder einem Anruf an eine vertrauenswürdige Nummer. Ich würde dem Benutzer eine E-Mail senden, um ihm mitzuteilen, dass seinem Konto ein Zertifikat hinzugefügt wurde. Ich würde einem Benutzer erlauben, die Benutzerzertifizierungszuordnung über seine Kontoverwaltungsseite in der App zu entfernen.

Ich würde mir ansehen, wie Google und Facebook Cookies für vertrauenswürdige Geräte setzen, um Zweifaktoren zu vermeiden. Ich hätte neue Geräte mit Zwei-Faktor-Authentifizierung, bevor ich die Nur-Zertifikat-Authentifizierung zulasse.

Ich würde auch darüber nachdenken, wie man mit widerrufenen Benutzerzertifikaten umgeht. Dies bedeutet, dass eine externe Zertifikatssperrliste (CRL) überprüft wird. Was tun Sie, wenn für ein Client-Zertifikat kein CRL-Verteilungspunkt definiert ist? Überprüfen Sie die CRL, wenn sich der Benutzer anmeldet oder wenn dies als Teil eines Auftrags geplant ist, da wahrscheinlich nur eine Handvoll CRLs verwendet werden?

In Wirklichkeit läuft dies auf Folgendes hinaus: Woher weiß ich, dass die Benutzerzertifikate nicht gefährdet wurden, und wie kann ich darauf vertrauen, dass ich das Zertifikat X dem Benutzer Y zuordnen kann.