Frage:
Zertifikatsbasierte Authentifizierung im Vergleich zur Authentifizierung mit Benutzername und Kennwort
Stefany
2011-05-06 18:35:04 UTC
view on stackexchange narkive permalink

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 ...

Sieben antworten:
#1
+96
Thomas Pornin
2011-05-06 20:05:59 UTC
view on stackexchange narkive permalink

1. Benutzer sind dumm

Ein Kennwort 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 aus der Ferne (aus Sicht des Verifizierers) zu überprüfen, ist das Benutzerverhalten notwendigerweise in den Prozess involviert. Kennwörter hängen jedoch von dem Teil des Benutzers ab, der ist notorisch mittelmäßig im Umgang mit Sicherheit, nämlich seinem Gehirn. Benutzer verstehen einfach nicht, worum es bei der Passwortentropie geht. Ich beschuldige sie nicht dafür: Dies ist ein technisches Thema, eine Spezialisierung, die in naher Zukunft nicht 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 verwendet werden 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 einfach 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 angesehen, und manchmal als 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.

Andererseits implizieren Benutzerzertifikate ein Speichersystem, und wenn dieses System ein physisches Gerät ist, das der Benutzer mit seinen Haus- oder Autoschlüsseln mit sich herumträgt Dann hängt die Sicherheit (teilweise) davon ab, wie gut der durchschnittliche Benutzer die Sicherheit eines physischen Objekts verwaltet, und er leistet normalerweise gute Arbeit. 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 um die Trennung von Rollen. Mit einem Passwort kennt jeder, der das Passwort überprüft, irgendwann das Passwort oder passwortäquivalente Daten (nun, das ist bei 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 unterschiedliche Entität sein und einen solchen Link überprüfen und zur Authentifizierung des Benutzers verwenden, ohne dass die Möglichkeit erhält, sich als Benutzer auszugeben.

definieren (dh die Entität, die die Zuordnung von der physischen Identität zur Computerwelt vornimmt), von denen, die authentifiziere Benutzer.

Dies eröffnet den Weg zu digitalen Signaturen , die keine Ablehnung 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 geleistet.

Außerdem sind Kennwörter von Natur aus anfällig für Phishing-Angriffe, Benutzerzertifikate dagegen 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

Das Bereitstellen von Benutzerzertifikaten ist komplex und daher teuer:

  • Das Ausstellen und Verwalten von Zertifikaten ist wie jede PKI eine vollständige Dose Wurm Der Verkäufer kann es Ihnen sagen (und ich sage es Ihnen auch). Besonders das Widerrufsmanagement. PKI besteht zu etwa 5% aus Kryptographie und zu 95% aus Verfahren. Es kann durchgeführt 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 tun) 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 gesamte 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. Das Zertifikat erfordert eine 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 Geben Sie ihnen ein eigenes gefälschtes Serverzertifikat.

Andererseits ist die passwortbasierte Authentifizierung praktisch überall einfach zu integrieren. Es ist natürlich genauso leicht, Fehler zu machen. Zumindest ist dies jedoch 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 Passwörtern können durch einige Tricks (bis hin zu einschließlich PAKE-Protokollen) und vor allem durch die Schuldzuweisung des Benutzers im Falle eines Problems (wir wissen, dass der durchschnittliche Benutzer kein sicheres Passwort auswählen kann, aber jedes Missgeschick wird es etwas mildern) etwas gemildert immer noch seine Schuld sein - so machen es Banken).

"Benutzer sind dumm" - nein, sind sie nicht. Benutzer sind nicht dumm. Sie sind rational unwissend: Sie haben bessere Dinge mit ihrer Zeit zu tun, als die Mathematik der Passwortentropie zu lernen. Es gibt einen wichtigen Unterschied (und einen sehr wichtigen Unterschied in der Denkweise für Sicherheitsleute). Benutzer sind auch rational nicht konform: Wie Cormac Herley argumentiert hat, überwiegt angesichts der Tatsache, dass die Sicherheit eines Benutzers relativ selten verletzt wird, der Vorteil für Benutzer, Zeit für lästige Sicherheitsmaßnahmen zu verwenden, tendenziell den Zeitaufwand damit.
@D.W. Ich liebe diesen Begriff "rational unwissend"! Ich sehe viel Gebrauch davon ...
Benutzer sind Benutzer. Benutzer interessieren sich hauptsächlich für ihre Aufgaben, von denen einige im Sicherheitsbereich ausgeführt werden. Sicherheit beeinträchtigt häufig die Benutzerfreundlichkeit, und Benutzer sind absichtlich nicht konform, wenn es darum geht, ihre eigene Benutzerfreundlichkeit zu verbessern. Um ein System sicher zu machen, müssen die Benutzer zusammenarbeiten. Um eine Zusammenarbeit zu erreichen, müssen sie verstehen, warum spezifische Maßnahmen getroffen werden. Nicht nur "Passwörter sind sicherer, wenn sie länger sind", sondern typische Angreifer verfügen über Tools, die Passwörter mit maximal acht Zeichen annehmen. Daher haben wir die Mindestlänge neun festgelegt. (Ich habe die Länge von acht Zeichen erfunden).
Und Sie stellen das PKI-Zertifikat aus, um ... oh yeh, einem "dummen Benutzer", und verlassen sich darauf, dass sie sich darum kümmern und es nicht irgendwo wie die Dateifreigabe des Unternehmens ablegen.
Das Argument "Passwortstärke" ist falsch.Regeln wie die Mindestanzahl von Zeichen, Großbuchstaben und Zahlen tragen nicht viel zur Entropie bei, sondern erleichtern das Knacken der Passwörter, da der Angreifer genau wissen kann, wie die Passwörter aussehen, und das Speichern des Passworts erschwertfür die Benutzer. Ein auf einen Notizzettel geschriebenes Kennwort ist so sicher wie ein Zertifikat gleicher Länge, wenn alle Angreifer keinen physischen Zugriff auf den Computer haben.
Ich habe mich für stackexchange angemeldet, um den Kommentar von D.W. zu verbessern."Rational ignorant"!- Sehr schön.
* "Passwörter sind von Natur aus anfällig für Phishing-Angriffe, Benutzerzertifikate dagegen nicht." * Entschuldigung, warum kann mich nicht jemand nach einer Kopie meines Zertifikats anstatt nach einer Kopie meines Passworts durchsuchen?
#2
+34
bethlakshmi
2011-05-07 00:50:06 UTC
view on stackexchange narkive permalink

Benutzername / Passwort

  • Pro : Einfache Bereitstellung - erfordert nur Code und einen sicheren Datenspeicher. Abhängig von der Sicherheitsrichtlinie können Kennwörter automatisch generiert oder neue Benutzer zum Erstellen gezwungen werden.

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

  • Con : Für eine gute Sicherheit sollten Kennwö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 zu den Problemen von Benutzern, die Passwörter wiederverwenden oder aufschreiben.

  • Con : Passwortdatenspeicher sind eine Schwachstelle - wenn ein Eindringling den Passwortspeicher erhält

  • Con : Alle Teile der Passwortübertragung können zu einer Gefährdung führen - Websites, auf denen Passwörter lokal gespeichert werden, um die Verwendung zu vereinfachen, intern Serverkomponenten, die im Clear übertragen, protokollieren Dateien in COTS-Produkten, in denen Kennwörter im Clear gespeichert sind. 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 Übertragung 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 ), das ein zentrales Managementsystem 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 bieten von plausibler Leugnung. 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 Zwecken als nur der Authentifizierung - kann Integrität und Vertraulichkeit gewährleisten auch.

  • Con : Erfordert 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 rohe Gewalt 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 treten bei PKI Kennwortprobleme in kleinerem Maßstab erneut auf.

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

  • Con : Berichte und Aktualisierungen zum Zertifikatstatus sind nicht einfach zu widerrufen Ein beschädigter Benutzerausweis ist aufgrund der Größe und Komplexität der Infrastruktur lästig. 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.

Einige andere Hinweise:

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 ...

I. stimme der Prämisse nicht zu. 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. Widerruf ist eine andere Dose Würmer - es ist 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. Es sei denn, Sie meinen, dass Benutzername / Passwort, die mit einer Textschnittstelle eingegeben würden, für Cross-Site-Scripting auf dieser Schnittstelle anfällig sein könnten.

Im Allgemeinen (Entschuldigung für meinen Mangel an offizieller Terminologie - I. Normalerweise werden die typischen Angriffsbedingungen nachgeschlagen, aber ich habe wenig Zeit.)

  • Brute Force - weil der Schlüsselbereich Ihres durchschnittlichen Kennworts kleiner ist als der Schlüsselbereich eines asymmetrischen Schlüssels, a Passwort ist leichter zu 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üsselbereichs 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 Der Angreifer ist ein großer Krypto-Nerd.

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

  • Inside Attack - Abrufen der Anmeldeinformationen aus dem System und anschließende Verwendung zur Emulation 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 davon ab, wie der Zugriff kontrolliert wird.

  • Mann in der Mitte - hängt von einem Mann ab 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.

Ich denke, es hat jedoch Auswirkungen auf CSRF. Es scheint CSRF-Anmeldeangriffe zu vereiteln, da der Angreifer seine eigenen Anmeldeinformationen nicht in die Anmeldeanforderung einfügen kann.
#3
+8
Stephen
2011-05-06 19:15:04 UTC
view on stackexchange narkive permalink
  1. Benutzernamen und Passwörter
    • Es geht nur darum, was Sie wissen. Sie geben ein geheimes Codewort 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 ausgefeilter. 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 a Schmerzen zu benutzen. Sie können sich nicht an sie erinnern und sie können gestohlen werden.
  3. ol>

    Das beste System ist eine Kombination. Sie geben dem Schlüssel ein Passwort ein, 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.

#4
+8
zedman9991
2011-05-06 19:27:59 UTC
view on stackexchange narkive permalink

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.

"Zertifikate sind an Keystores auf Maschinenebene gebunden und eignen sich daher hervorragend für die Authentifizierung von Maschine zu Maschine zwischen" Dies ist eine Information, die ich zum Beispiel vergessen habe, als ich nachdachte, also +1 Danke!
#5
+3
yfeldblum
2011-05-06 19:46:18 UTC
view on stackexchange narkive permalink

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 ausreichende 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.

Außerdem 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.

Ich warne davor, den Ausdruck "kann nicht brutal gezwungen werden" zu verwenden.
Ich verstehe vielleicht falsch, was Sie meinen, aber ist Social Engineering zum Abrufen des Kennworts zum Schutz eines privaten Schlüssels nicht genauso gut, wenn nicht sogar besser, als ein Kennwort für einen bestimmten Dienst zu erhalten?
Der Versuch, sowohl einen kennwortgeschützten privaten Schlüssel als auch das Kennwort für diesen Schlüssel abzurufen, ist normalerweise schwieriger als das einfache Abrufen eines Kennworts. Ja, Social Engineering ist in beiden Fällen ein guter Angriff. Nur bei der Authentifizierung mit öffentlichen Schlüsseln ist es eine größere Herausforderung, dies zu erreichen. Ein privater Schlüssel kann beispielsweise nicht einfach gespeichert werden (und wird meistens nicht gespeichert), geschweige denn über das Telefon gelesen, was einen längeren Social-Engineering-Aufwand erfordert, um ihn zu erhalten.
Ich verstehe was du meinst. Ich habe den Satz "... zuerst den privaten Schlüssel erhalten" komplett verpasst.
#6
+1
Martin
2013-11-20 20:13:08 UTC
view on stackexchange narkive permalink

Sie scheinen zu vergessen, dass eine Webseite sowohl Zertifikate als auch Kennwö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 Kennwort anmelden.

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

#7
+1
Mat Carlson
2013-11-20 23:07:07 UTC
view on stackexchange narkive permalink

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, können jedoch meiner Meinung nach problemlos integriert werden (Active Directory ist etwas anders, aber anders 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 Passwort (USB- oder NFC-Verbindung erforderlich) oder einen angezeigten Code-Anhänger wählen.

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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...