it-swarm-eu.dev

Zertifikatsbasierte Authentifizierung im Vergleich zur Authentifizierung mit Benutzername und Passwort

Was sind die Vor- und Nachteile der zertifikatbasierten Authentifizierung gegenüber der Authentifizierung mit Benutzername und Kennwort? Ich kenne einige, würde mich aber über eine strukturierte und detaillierte Antwort freuen.

UPDATE

Ich bin auch daran interessiert zu wissen, für welche Angriffe sie anfällig sind, z. wie bisher Brute Force erwähnt, während für Zertifikate nichts erwähnt wird ... was ist mit XSRF? Es wird erwartet, dass ein Zertifikat eine kürzere Lebensdauer hat und widerrufen werden kann, während ein Kennwort länger gültig ist, bevor eine Administratorrichtlinie nach einer Änderung fragt ...

95
Stefany

1. Benutzer sind dumm

Ein Passwort passt in den Speicher eines Benutzers und wird vom Benutzer ausgewählt. Da es bei der Authentifizierung darum geht, die physische Identität des Benutzers zu überprüfen remote (aus Sicht des Verifizierers), ist das Benutzerverhalten notwendigerweise in den Prozess involviert - Kennwörter hängen jedoch vom Teil des Benutzers ab Benutzer, der im Umgang mit Sicherheit am bekanntesten ist, nämlich sein Gehirn. Benutzer verstehen einfach nicht, worum es bei der Passwortentropie geht. Ich bin nicht Schuld ihnen dafür: Dies ist ein technisches Thema, eine Spezialisierung, die nicht so schnell realistisch zum "gesunden Menschenverstand" werden kann. Auf der anderen Seite ist die Sicherheit eines physischen Tokens viel "greifbarer" und durchschnittliche Benutzer können ziemlich gut darin werden. Evolutionisten würden sagen, dass Menschen in den letzten Millionen Jahren positiv dafür ausgewählt wurden, weil diejenigen, die sich nicht an ihren Feuersteinwerkzeugen festhalten konnten, nicht genug überlebten, um Nachkommen zu haben.

Hollywood-Filme können als Modell dafür dienen, wie Benutzer über Passwörter denken - schon allein deshalb, weil diese Benutzer auch ins Kino gehen. Ausnahmslos hat der Erzfeind ein kurzes Passwort und prahlt gerne damit und verteilt Hinweise, wann immer er kann. Und ausnahmslos errät ein britischer Geheimagent das Passwort rechtzeitig, um die Fusionsbombe zu deaktivieren, die unter dem Lieblingsblumenbeet der Königin gepflanzt wurde. Filme projizieren eine verzerrte, übertriebene Realität, stellen jedoch immer noch die mentale Basis dar, auf der durchschnittliche Benutzer arbeiten: Sie stellen sich Passwörter als Sicherheit vor, indem sie "witziger" sind als der Angreifer. Und die meisten scheitern immer daran.

"Passwortstärke" kann durch verbindliche Regeln (mindestens acht Zeichen, mindestens zwei Ziffern, mindestens ein Groß- und ein Kleinbuchstabe ...) etwas verbessert werden, aber diese Regeln werden von den Benutzern als Belastung und manchmal als Belastung angesehen unerträgliche Einschränkung ihrer angeborenen Freiheit - so können die Benutzer die Regeln mit großer Kreativität bekämpfen, beginnend mit dem traditionellen Aufschreiben des Passworts auf eine Haftnotiz. In den meisten Fällen schlagen die Regeln zur Kennwortverstärkung auf diese Weise fehl.

Auf der anderen Seite implizieren Benutzerzertifikate ein Speichersystem, und wenn dieses System ein physisches Gerät ist, das der Benutzer mit seinen Haus- oder Autoschlüsseln herumträgt, hängt die Sicherheit (teilweise) davon ab, wie gut der durchschnittliche Benutzer die Sicherheit von a verwaltet physisches Objekt, und sie machen normalerweise einen guten Job darin. Zumindest besser als bei der Auswahl eines guten Passworts. Das ist also ein großer Vorteil von Zertifikaten.

2. Zertifikate verwenden asymmetrische Kryptographie

Bei der "Asymmetrie" geht es darum, Rollen zu trennen. Mit einem Passwort kennt jeder, der das Passwort überprüft, irgendwann das Passwort oder passwortäquivalente Daten (nun, das ist im Fall von PAKE Protokollen nicht ganz richtig ). Bei Benutzerzertifikaten wird das Zertifikat von einer Zertifizierungsstelle ausgestellt, die die Verbindung zwischen einer physischen Identität und einem kryptografischen öffentlichen Schlüssel garantiert. Der Verifizierer kann eine eindeutige Entität sein und kann einen solchen Link verifizieren und zur Authentifizierung des Benutzers verwenden, ohne die Fähigkeit erhalten, sich als Benutzer auszugeben.

Kurz gesagt, dies ist der Punkt von Zertifikaten: diejenigen zu trennen, die definieren die digitale Identität des Benutzers (dh die Entität, die die Zuordnung von der physischen Identität zur Computerwelt vornimmt) von denen, die = authentifizieren Benutzer.

Dies öffnet den Weg zu digitalen Signaturen, die Nicht-Zurückweisung bringen. Dies betrifft insbesondere Banken, die Finanzaufträge von Online-Kunden entgegennehmen: Sie müssen Kunden authentifizieren (das ist Geld, über das wir sprechen, eine sehr ernste Angelegenheit), aber sie würden gerne eine überzeugende Spur der Aufträge haben - im Sinne von: a Richter wäre überzeugt. Durch die bloße Authentifizierung erhält die Bank die Gewissheit, mit dem richtigen Kunden zu sprechen, kann dies jedoch Dritten nicht beweisen. Die Bank könnte ein gefälschtes Verbindungsprotokoll erstellen, so dass es gegen einen Kunden, der behauptet, von der Bank selbst gerahmt zu werden, waffenlos ist. Digitale Signaturen sind nicht sofort verfügbar, selbst wenn der Benutzer über ein Zertifikat verfügt. Wenn der Benutzer jedoch ein Zertifikat zur Authentifizierung verwenden kann, wurde der größte Teil der harten Arbeit erledigt.

Kennwörter sind von Natur aus anfällig für Phishing-Angriffe, Benutzerzertifikate hingegen nicht. Gerade wegen der Asymmetrie: Bei der Verwendung von Zertifikaten werden dem Peer niemals geheime Daten offengelegt, sodass ein Angreifer, der sich als Server ausgibt, auf diese Weise nichts Wertvolles lernen kann.

3. Zertifikate sind komplex

Die Bereitstellung von Benutzerzertifikaten ist komplex und daher teuer:

  • Das Ausstellen und Verwalten von Zertifikaten ist eine vollständige Dose Wurm, wie jeder PKI-Anbieter Ihnen sagen kann (und ich sage es Ihnen auch). Besonders das Widerrufsmanagement. PKI besteht zu etwa 5% aus Kryptographie und zu 95% aus Verfahren. Es kann gemacht werden, aber nicht billig.

  • Benutzerzertifikate implizieren, dass Benutzer ihren privaten Schlüssel auf irgendeine Weise unter ihrem "exklusiven Zugriff" speichern. Dies erfolgt entweder in Software (vorhandene Betriebssysteme und/oder Webbrowser können dies) oder unter Verwendung dedizierter Hardware, aber beide Lösungen haben ihre eigenen Usability-Probleme. Die beiden Hauptprobleme, die auftreten werden, sind: 1) Der Benutzer verliert seinen Schlüssel und 2) Ein Angreifer erhält eine Kopie des Schlüssels. Durch die Softwarespeicherung wird der Schlüsselverlust zu einem plausiblen Problem (aufgrund einer ausgefallenen Festplatte), und die gemeinsame Nutzung des Schlüssels zwischen mehreren Systemen (z. B. einem Desktop-Computer und einem iPad) impliziert einige manuelle Vorgänge, die wahrscheinlich nicht gut vor Angreifern geschützt sind. Hardware-Token implizieren das ganze chaotische Geschäft der Gerätetreiber, was noch schlimmer sein kann.

  • Ein Benutzerzertifikat impliziert relativ komplexe mathematische Operationen auf der Clientseite. Dies ist selbst für einen anämischen Pentium II kein Problem, aber Sie können keine Zertifikate von Javascript verwenden, die auf einer generischen Website geklatscht sind. Zertifikat erfordert aktive Zusammenarbeit von clientseitiger Software, und diese Software ist in dieser Angelegenheit beispielsweise ergonomisch suboptimal. Durchschnittliche Benutzer können normalerweise lernen, Client-Zertifikate für eine HTTPS-Verbindung zu einer Website zu verwenden, jedoch auf Kosten des Lernens, wie das gelegentliche Warn-Popup ignoriert wird, wodurch sie für einige Angriffe (z. B. aktive Angriffe, bei denen der Angreifer dies versucht) viel anfälliger werden füttere sie mit ihrem eigenen gefälschten Serverzertifikat).

Andererseits ist die passwortbasierte Authentifizierung praktisch überall einfach zu integrieren. Es ist natürlich genauso leicht, Fehler zu machen. aber zumindest ist es nicht unbedingt mit inkompressiblen Zusatzkosten verbunden.

Zusammenfassung

Benutzerzertifikate ermöglichen eine Rollentrennung, die mit Kennwörtern nicht möglich ist. Sie tun dies auf Kosten einer Horde von Implementierungs- und Bereitstellungsproblemen, die sie teuer machen. Passwörter bleiben jedoch billig, da sie in einen menschlichen Verstand passen, was von Natur aus eine geringe Sicherheit impliziert. Sicherheitsprobleme mit Kennwörtern können durch einige Tricks (bis hin zu PAKE-Protokollen) und vor allem durch die Schuldzuweisung des Benutzers im Falle eines Problems (wir wissen, dass der durchschnittliche Benutzer kein sicheres Kennwort auswählen kann, aber jedes Missgeschick wird es etwas mildern) etwas gemildert immer noch seine Schuld sein - so machen es Banken).

94
Thomas Pornin

Benutzername/Passwort

  • Pro: Einfach bereitzustellen - benötigt nur Code und einen sicheren Datenspeicher. Kann abhängig von der Sicherheitsrichtlinie Kennwörter automatisch generieren oder neue Benutzer zum Erstellen zwingen.

  • Pro: Einfach zu verwalten - das Zurücksetzen von Passwörtern kann (für einige Sicherheitsrichtlinien) mit automatisierten Tools durchgeführt werden

  • Con: Aus Sicherheitsgründen sollten Passwörter frühzeitig und häufig zurückgesetzt werden. Das Vergessen oder Nicht-Ändern von Passwörtern durch den Benutzer ist entweder ein Sicherheitsrisiko oder ein Problem mit der Benutzerfreundlichkeit.

  • Con: Gute Passwörter können schwer zu merken sein, was dazu führt, dass Benutzer Passwörter wiederverwenden oder aufschreiben.

  • Con: Passwortdatenspeicher sind eine Schwachstelle - wenn ein Eindringling den Passwortspeicher erhält, erhält er die Mutterlast.

  • Con: Alle Teile der Passwortübertragung können zu einer Gefährdung führen - Websites, auf denen Passwörter zur Vereinfachung lokal gespeichert werden, interne Serverkomponenten, die im Klartext übertragen werden, Protokolldateien in COTS-Produkten, in denen Passwörter im Klartext gespeichert werden. Da das Geheimnis Teil der Übertragung ist, sind Sie nur so stark wie Ihr schwächstes Glied - es sind ernsthafte Anstrengungen erforderlich, um eine Gefährdung zu verhindern, und die Anforderungen gelten sowohl für den Benutzer als auch für den Systementwickler.

Zertifikate :

  • Pro: Erfordert keine Übermittlung des Geheimnisses. Der Nachweis eines privaten Schlüssels enthält keine geheimen Informationen - verringert alle Arten von Speicher-/Übertragungsschwächen.

  • Pro: Wird von einer vertrauenswürdigen Partei (der Zertifizierungsstelle) ausgestellt, die ein zentrales Verwaltungssystem für den Status über mehrere Anwendungen hinweg ermöglicht. Wenn ein Zertifikat schlecht wird, kann es widerrufen werden. Das Festlegen einer Kennwortunterbrechung muss für jedes System separat erfolgen, sofern keine gemeinsame ID verwendet wird.

  • Pro: Der Fall der Nicht-Zurückweisung ist stärker - in den meisten Kennwortsystemen ist die Art und Weise, wie der Benutzer vor der Kontoerstellung zunächst authentifiziert wird, ziemlich schwach, und die Mechanismen zum Zurücksetzen des Kennworts können einen weiteren Faktor plausibler Verleugnung bieten. Bei vielen Formen der Zertifikatsausstellung ist es für einen Benutzer weitaus schwieriger zu sagen, dass dies nicht der Fall war. Vorsichtsmaßnahme - Sie sind immer noch nur so gut wie die Ausstellungsrichtlinien Ihrer Zertifizierungsstelle.

  • Pro: Dient mehr als nur der Authentifizierung - kann auch Integrität und Vertraulichkeit gewährleisten.

  • Con: Benötigt immer noch ein Passwort/eine PIN - fast jeder Speichermechanismus für private Schlüsselpaare wird dann mit einer PIN entsperrt. SmartCards können über Manipulationsschutz- und Sperrfunktionen verfügen, um Brute Force zu verhindern. Dies behebt jedoch nicht die Tatsache, dass der Benutzer seine PIN] auf eine Notiz neben dem Computer geschrieben hat, auf dem die Karte angedockt ist. Manchmal Kennwortprobleme treten bei PKI in kleinerem Maßstab wieder auf.

  • Con: Komplexität der Infrastruktur - Das Einrichten einer PKI ist keine leichte Aufgabe und im Allgemeinen sowohl bei der Bereitstellung als auch bei der Wartung so teuer, dass sie nur für große/teure Systeme verwendet werden kann.

  • Con: Berichte und Aktualisierungen zum Zertifikatstatus sind nicht einfach. Das Widerrufen eines beschädigten Benutzeranmeldeinformats ist aufgrund der Größe und Komplexität der Infrastruktur problematisch. Normalerweise generiert eine Zertifizierungsstelle eine CRL, die möglicherweise auf einem OCSP-Server bereitgestellt wird oder nicht. Dann sollte jede Anwendung bei jeder Anmeldung den CRL- oder OCSP-Status überprüfen. Dies führt zu einer Reihe von Zeitverzögerungen im System zwischen dem Zeitpunkt, zu dem ein PKI-Berechtigungsnachweis als gefährdet gemeldet wird, und dem Zeitpunkt, zu dem die Systeme, die auf diesen Berechtigungsnachweis angewiesen sind, tatsächlich den Zugriff verweigern. Die Geschwindigkeit der Statusaktualisierung kann beschleunigt werden - jedoch zu höheren Kosten für die Systemkomplexität.

Ein paar andere Anmerkungen:

Es wird erwartet, dass ein Zertifikat eine kürzere Lebensdauer hat und widerrufen werden kann, solange ein Kennwort länger gültig ist, bevor eine Administratorrichtlinie nach einer Änderung fragt ...

Ich bin mit der Prämisse nicht einverstanden. Auf den Systemen, an denen ich gearbeitet habe und die sowohl Kennwort als auch PKI unterstützen, ist die Richtlinie für die Anforderungen der Kennwortaktualisierung VIEL kürzer als die Richtlinie für die Ausstellung von Zertifikaten. Der Widerruf ist eine andere Dose Würmer - für das weniger wahrscheinliche Ereignis eines Kompromisses mit privaten Schlüsseln. Da die privaten Schlüsseldaten nicht über das System übertragen werden, wird allgemein angenommen, dass das Risiko einer Exposition gegenüber diesen Daten viel geringer ist als das Risiko einer Exposition gegenüber Passwörtern. Aus praktischen Gründen wird angenommen, dass Passwörter eine kürzere Lebensdauer haben.

Ich bin auch daran interessiert zu wissen, für welche Angriffe sie anfällig sind, z. wie bisher Brute Force erwähnt, während für Zertifikate nichts erwähnt wird ... was ist mit XSRF?

Sie mischen hier Äpfel und Orangen. Brute Force kann ein praktikabler Angriff auf beide Arten von Authentifizierungsdaten sein. XSRF ist jedoch ein Angriff auf einen zugrunde liegenden Anwendungstyp, der unabhängig vom Authentifizierungsmechanismus möglich wäre. Sofern Sie nicht meinen, dass Benutzername/Passwort mit einer Art Textschnittstelle eingegeben werden, können sie für Cross-Site-Scripting auf dieser Schnittstelle anfällig sein.

Im Allgemeinen (Entschuldigung für das Fehlen einer offiziellen Terminologie - ich schaue normalerweise nach den typischen Angriffsbedingungen, habe aber wenig Zeit):

  • Brute Force - Da der Schlüsselbereich eines durchschnittlichen Kennworts kleiner als der Schlüsselbereich eines asymmetrischen Schlüssels ist, lässt sich ein Kennwort leichter brutal erzwingen. Eine ausreichend kleine Schlüsselgröße auf einem Zertifikat ist jedoch auch Brute-Force-fähig, und die Fähigkeit, Brute-Force-Angriffsschlüssel zu verwenden, wächst mit den CPU-Fähigkeiten, die ein Rattenrennen mit zunehmender Schlüsselgröße erzwingen.

  • Gebildetes Erraten - Das Eingrenzen des Schlüsselraums auf einen vernünftigen Satz von Vermutungen ist mit Kennwörtern einfacher und für die meisten asymmetrischen Schlüsselalgorithmen nicht so offensichtlich, obwohl der RSA-Algorithmus schwache Schlüssel enthält, sodass eine gewisse Abhängigkeit davon besteht, wie groß ein Krypto-Nerd ist Angreifer ist.

  • Social Engineering - in beiden Fällen möglich, obwohl Sie mit einem in Hardware gespeicherten Zertifikat nicht nur die Kontrolle über die PIN] des Benutzers haben müssen, sondern auch über die Hardware, auf der der Schlüssel gespeichert ist.

  • Inside Attack - das Abrufen der Anmeldeinformationen aus dem System und das anschließende Emulieren eines legitimen Benutzers - hängt davon ab. Wenn Passwörter unsicher gespeichert werden, ist dies für ein passwortbasiertes System praktikabler. Wenn Sie jedoch die Kontrolle über die Zertifizierungsstelle erlangen können, können Sie sich ein legitimes Zertifikat ausstellen. Dies hängt dann davon ab, wie der Zugriff kontrolliert wird.

  • Mann in der Mitte - hängt davon ab - ein Mann in der Mitte kann ein Passwort abfangen, wenn das Passwort während der Übertragung nicht durch einen Verschlüsselungsmechanismus verschlüsselt wird, der ihn umgeht. Das ist mit SSL/TLS machbar. Ein Mann in der Mitte kann jedoch auch Teile einer PKI-Übertragung abfangen, je nachdem, wie die PKI verwendet wird. PKI-Signaturen ohne Nonce oder Zeitstempel können von einem Mann in der Mitte repliziert werden. Er kann eine abgefangene Nachricht erneut senden, solange nicht festgestellt werden kann, ob die Nachricht aktuell oder eindeutig ist.

32
bethlakshmi
  1. Benutzernamen und Passwörter
    • Es geht nur darum, was Sie wissen. Sie geben einen Geheimcode Word zur Authentifizierung beim Dienst an.
    • Dies bedeutet, dass es verwendet werden kann, wenn es im Stream abgefangen wird. Die Verwendung von Verschlüsselung macht dies unwahrscheinlich, aber dennoch möglich. Jemand kann einen Mann in der Mitte dazu bringen, Ihr Passwort zu erhalten oder den Computer zu übernehmen, der die Authentifizierung erhält.
    • Ein Benutzername und ein Passwort können jederzeit auf jedem Computer verwendet werden. Dies ist eine schlechte Sache, wenn Sicherheit wichtig ist, und eine gute Sache, wenn Zugänglichkeit wichtig ist. Für eine Bank ... ist das schlecht. Für Facebook sollte es wirklich keine Rolle spielen.
  2. Zertifikate
    • Zertifikate sind etwas anspruchsvoller. Der Server sendet Daten an den Client und der Client signiert die Daten und sendet sie zurück. Dies bedeutet, dass der Server den privaten Schlüssel zu keinem Zeitpunkt kennt. Während ein Mann in der Mitte oder bei der Übernahme des Servers dazu führt, dass er Zugriff erhält, verfügt er nicht über Ihren Schlüssel.
    • Zertifikate sind ein Schmerz zu benutzen. Sie können sich nicht an sie erinnern und sie können gestohlen werden.

Das beste System ist eine Kombination. Sie geben dem Schlüssel ein Passwort, damit Sie über eine Zwei-Faktor-Authentifizierung verfügen. Etwas, das Sie kennen (Passwort) und etwas, das Sie haben (Schlüssel). Je mehr Sicherheitsebenen vorhanden sind, desto schmerzhafter ist es jedoch. Das ist der große Kompromiss bei der gesamten Sicherheit.

8
Stephen

Ich stimme Stephens Punkten zu. Sie stellen die Forschung vor eine schwierige Frage, da das Problem in der Regel kein Vergleich zwischen den beiden ist. Ein guter Weg, um zu verstehen, warum beide existieren und normalerweise nicht gegeneinander bewertet werden, besteht darin, sich auf die Verwendung zu konzentrieren. Zertifikate sind an Keystores auf Maschinenebene gebunden und eignen sich daher hervorragend für die Authentifizierung von Maschine zu Maschine zwischen bestimmten Maschinen, die im Voraus geplant wurden. Passwörter sind sehr gut für Menschen geeignet, da wir mobil sind und dazu neigen, sich von zahlreichen Systemen auf eine Weise zu authentifizieren, die im Voraus schwer vorherzusagen ist. Daher sind Zertifikate typisch für die im Voraus entwickelte hardwarebasierte Authentifizierung, und Kennwörter eignen sich für die mobile Wetware-basierte Authentifizierung. Eine Smartcard ist eine großartige Möglichkeit, dem mobilen Menschen eine zertifikatbasierte Authentifizierung hinzuzufügen, und ein weiterer Faktor für den Prozess.

8
zedman9991

Ein Passwort kann oft brutal erzwungen und sozial entwickelt werden, da es, da sein Besitzer es sich merken muss, oft viel einfacher ist als ein geheimer Schlüssel.

Ein privater Schlüssel (von ausreichender Stärke - für RSA, 2048 oder 4096 Bit) kann nicht brutal erzwungen werden. Die einzige Möglichkeit, sich bei einem System zu authentifizieren, für das eine Authentifizierung auf Basis eines öffentlichen Schlüssels erforderlich ist, besteht darin, zuerst auf einen anderen Computer zuzugreifen, um den privaten Schlüssel zu erhalten. Dies führt zu einer zusätzlichen Komplexität jedes Angriffs. Social Engineering hilft nicht, eine Person dazu zu bringen, ihr Passwort preiszugeben, da das Passwort nur seinen privaten Schlüssel entschlüsselt, anstatt ihm direkten Zugriff auf das Zielsystem zu gewähren. Social Engineering, um eine Person dazu zu bringen, ihren privaten Schlüssel zusammen mit ihrem Passwort preiszugeben, ist wahrscheinlich viel schwieriger.

Zusätzlich werden Passwörter über das Netzwerk vom Computer des Benutzers an das System übertragen, das der Benutzer verwenden möchte. Private Schlüssel werden weder im klaren noch im verschlüsselten Format über das Netzwerk übertragen. Vielmehr wird nur der öffentliche Schlüssel übertragen.

3
yfeldblum

Sie scheinen zu vergessen, dass eine Webseite sowohl Zertifikate als auch Passwörter verwenden kann. Wenn ein Benutzer mit einem Zertifikat kommt, öffnet sich die Tür. Und wenn er kein Zertifikat hat, muss er sich wie immer mit Name und Passwort anmelden.

Auf diese Weise erhalten die interessierten Benutzer ihr Zertifikat, alle anderen tun es auf die alte Weise.

1
Martin

Ich möchte eine Option hinzufügen - Geräte mit Einmalkennwort. Ich stimme dem zu, was andere über die Vor- und Nachteile von Zertifikaten und Kennwörtern gesagt haben - OTP-Geräte erfordern einige Back-End-Komponenten für den Betrieb, können aber meiner Meinung nach ohne großen Aufwand integriert werden (Active Directory ist etwas anders, aber andere Systeme sind nicht zu schwer).

Eine Kombination aus einem Passwort und einem Einmalpasswort funktioniert sehr gut. Sie können eine einfachere Lösung wie einen Yubikey mit einem Kennwort (USB oder NFC Verbindung erforderlich)) oder einen angezeigten Code-Anhänger verwenden.

Beide Optionen lassen sich leicht zu Linux-basierten Vorgängen hinzufügen. Wenn Sie dies in Active Directory tun möchten, müssen Sie Software kaufen, um den Code zu verarbeiten und auf jedem AD-Server zu installieren. Der Benutzer gibt dann das OTP am Anfang des Kennwortfelds und dann sein übliches Kennwort ein. Es ist möglich, ein eigenes Modul dafür zu entwickeln, aber nach dem, was ich gesehen habe, unerschwinglich.

1
Mat Carlson