Frage:
Warum authentifizieren wir uns, indem wir einen Benutzer auffordern, sowohl den Benutzernamen als auch das Passwort einzugeben? Reicht es nur aus, das Passwort einzugeben?
LaTeX
2011-03-04 20:33:20 UTC
view on stackexchange narkive permalink

Ich weiß nicht, warum wir uns authentifizieren, indem wir den Benutzer auffordern, sowohl den Benutzernamen als auch das Passwort einzugeben. In meinem mentalen Modell reicht die Aufforderung zum Passwort nur aus.

Der Grund ist folgender:

Angenommen, es sind x gültige Zeichen zu verwenden.

Fall 1 (Eingabe von Benutzername und Passwort)

Die Länge von Benutzername und Passwort sei n / 2 Zeichen jeweils. Da der Benutzername der Öffentlichkeit zugänglich ist, beträgt die Erfolgswahrscheinlichkeit, das Kennwort zu brechen, eins über x ^ (n / 2).

Der Benutzername ist eindeutig.

Fall 2 ( Nur Passwort eingeben)

Die Länge des Passworts darf n Zeichen betragen. Die Wahrscheinlichkeit, dass das Passwort erfolgreich gebrochen wird, liegt bei über x ^ n.

Warum authentifizieren wir uns durch Aufforderung a Benutzer, um sowohl Benutzernamen als auch Passwort einzugeben? Reicht es nur aus, das Passwort einzugeben?

Das Passwort ist eindeutig.

Können Sie mir sagen, wie Sie Zugriffsversuche protokollieren möchten? auf welcher Basis? Es tut mir leid, aber dieser Ansatz kann einfach nicht reguliert werden ...
Ich sehe oft, dass Angreifer zufällige Benutzernamen mit (ich denke) einem gemeinsamen festen Passwort versuchen. So umgehen sie ein vorübergehendes Verbot von Kontonamen für zu viele fehlgeschlagene Anmeldeversuche.
@LaTeX: Wenn ich keinen Benutzernamen und nur "passw0rd1" eingegeben habe, auf welches der Dutzenden von Konten, die dieses Passwort verwenden, werde ich Zugriff erhalten? ;)
Acht antworten:
#1
+40
Justin C
2011-03-04 21:02:02 UTC
view on stackexchange narkive permalink

Ich denke, das Problem besteht darin, dass Kennwörter eindeutig sein müssen. Wenn ich mein gewünschtes Passwort eingegeben habe und Sie mir gesagt haben, dass ich es nicht verwenden kann, wird es bereits verwendet. Dann weiß ich, dass ich mich mit dem gewünschten Passwort bei einem zufälligen Personenkonto anmelden kann.

Sie benötigen also einen Benutzernamen, der eindeutig ist und jedem bekannt sein kann. Dann haben Sie ein persönliches Passwort, das nicht unbedingt eindeutig ist, was das Erraten noch schwieriger macht.

Wenn Sie gerade dabei sind, hacken und salzen Sie dieses Passwort.

> Wenn Sie schon dabei sind, hacken und salzen Sie dieses Passwort.
#2
+21
AviD
2011-03-06 01:14:17 UTC
view on stackexchange narkive permalink

Hier gibt es bereits gute Antworten, aber das einfache Grundkonzept fehlt noch:

Identifizierung und Authentifizierung sind nicht dasselbe.

Einfach ausgedrückt, dies sind zwei separate Anforderungen, die nicht verwechselt werden sollten.
Ein Benutzername dient zur Identifizierung, und mit einem Kennwort können Sie die beanspruchte Identität überprüfen (dh Authentifizierung). .

Siehe auch Unterschied zwischen Authentifizierung und Identifizierung [Krypto- und Sicherheitsperspektive]

Guter Punkt. Ich werde auch bemerken, dass es auch möglich ist, eine Autorisierung ohne Identifizierung oder Authentifizierung durchzuführen. Vielleicht nicht so häufig wie es sein mag, aber genau das können Sie mit Bargeld tun, z. in der echten Welt. Daher kann auch eine Art bloßes Kennwort oder Token für den Zugriff auf ein System verwendet werden, obwohl die meisten Systeme nicht so strukturiert sind.
@nealmcb, Dem stimme ich zu. Die Autorisierung ohne Identifizierung wird jedoch tatsächlich häufiger durchgeführt, als Sie vielleicht denken - z. Auf allen Pr0n-Sites "Ich bin über 18" würde ich das nicht als Identifikation betrachten ... Auch das ist * irgendwie *, worum es bei der anspruchsbasierten Autorisierung (siehe MS Genf) geht ...
Gutes Beispiel. Hmmm - wie ist die Beziehung zwischen Genf und U-Prove, auf die sich der Name derzeit zu konzentrieren scheint?
#3
+11
nealmcb
2011-03-04 23:13:42 UTC
view on stackexchange narkive permalink

Sowohl der Benutzer als auch der Administrator profitieren von einem Benutzernamen, der normalerweise eindeutig ist und kein Geheimnis darstellt. Sie können ihn frei verwenden, um auf das Konto zu verweisen. Wenn der Benutzername nicht eindeutig ist, kann er einer E-Mail-Adresse oder einer anderen eindeutigen Kontakt-ID zugeordnet werden. Auf diese Weise kann ein Benutzer sein Passwort zurücksetzen und ein neues erhalten oder sein Passwort ändern, ohne sein Konto zu ändern.

Außerdem ist es, wie von anderen angemerkt, problematisch, nur ein eindeutiges Passwort zu benötigen, wenn es das ist nur Kennung und es gibt eine Kollision.

Die Möglichkeit, ein vergessenes Passwort zurückzusetzen, ist ein hervorragender Punkt, den ich verpasst habe.
#4
+5
Andreas Arnold
2011-03-04 20:42:42 UTC
view on stackexchange narkive permalink

Der Benutzername dient dazu, den Benutzer zu identifizieren. Wenn Sie nur nach einem Passwort fragen, haben (leider) mehrere Personen das Passwort 123456 oder das Passwort. Wie können Sie jetzt feststellen, welcher Benutzer mit diesem Kennwort versucht, sich anzumelden? Deshalb gibt es auch einen Benutzernamen.

Und da das Passwort nicht im Klartext gespeichert werden sollte, sollten Sie nicht überprüfen, ob das Passwort eindeutig ist.

Der andere Punkt Sie vermissen in Fall 2: Ich muss nur ein Passwort finden, das jemand verwendet hat und nicht wer es tatsächlich verwendet hat. Wenn also eine Person das Passwort 123456 verwendet, muss ich das nur wissen und kann mich anmelden. Wenn es auch einen Benutzernamen gibt, meldet sich das Passwort allein nicht erfolgreich an.

Hervorragende Summe. Ich wollte hinzufügen, dass Passwörter auch nicht verschlüsselt, sondern mit einem Salz gehasht werden sollten, damit Sie Passwörter auf keinen Fall vergleichen können.
#5
+5
Sigtran
2011-03-04 21:11:40 UTC
view on stackexchange narkive permalink

Ihre Wahrscheinlichkeiten, ein Passwort zu finden, sind definitiv falsch.

Beispiel:

Sie haben 8 Benutzer &, jedes Passwort ist 64 Bit lang (Standard 8 Zeichen, in keiner Weise gesalzen).

Für Fall zwei:

Ein Angreifer muss den Algorithmus zum Brechen des Kennworts nur einmal ausführen, um alle 8 Benutzer zu erhalten (Gesamtarbeit im schlimmsten Fall = 64 Bit, durchschnittlich 32 Bit)

Für den ersten Fall:

Um alle Passwörter zu knacken, muss ein Angreifer seinen Algorithmus achtmal ausführen (einmal für jeden Benutzer), was offensichtlich mehr Arbeit bedeutet (z. B. insgesamt) Arbeit im schlimmsten Fall = 67 Bit, durchschnittlich 33-34 Bit)

Die Wahrscheinlichkeit, dass das Passwort gebrochen wird, sollte sein:

Für den ersten Fall:

  1 / (2 ^ bitsUsedForPassword)  

Für Fall zwei:

  numberOfUsers / (2 ^ bitsUsedForPassword)  

Daher hat der zweite Fall eher die Chance, das Kennwort zu erhalten, wenn mehr als ein Benutzer anwesend ist.

#6
+4
D.W.
2011-03-06 06:47:38 UTC
view on stackexchange narkive permalink

Einen Benutzernamen und ein Passwort zu haben ist definitiv sicherer. Angenommen, Ihre Site hat eine Million Benutzer:

  • Wenn Sie nur ein Kennwort verwenden, muss ein Angreifer nur eines der Millionen gültigen Kennwörter erraten, um in die Site einzudringen.

  • Wenn Sie einen Benutzernamen und ein Kennwort verwenden, muss der Angreifer einen gültigen Benutzernamen und das richtige Kennwort für diesen Benutzernamen (nicht irgendeinen) eingeben Passwort auf der Website). Für den Angreifer ist das viel schwieriger.

Das Erfordernis eines Benutzernamens und eines Kennworts bietet eine viel bessere Sicherheit.

Beispiel: Nehmen wir an, dass jedes Passwort aus einer Reihe von einer Milliarde Möglichkeiten einheitlich zufällig ausgewählt wird, z. B. eine zufällige 9-stellige Zahl. (Ja, ich weiß, dass dies eine unrealistische Annahme ist, daher wird dieses Beispiel eine Vereinfachung darstellen, aber die ähnlichen Ergebnisse gelten für realistischere Annahmen.)

  • Wenn für die Site nur ein gültiges Kennwort erforderlich ist Um sich anzumelden, gelangt ein Angreifer, der zufällige 9-stellige Zahlen eingibt, durchschnittlich nach etwa 1000 Versuchen auf die Site.

  • Wenn für die Site ein gültiger Benutzername erforderlich ist und das entsprechende Kennwort zum Anmelden. Selbst wenn der Angreifer den Benutzernamen aller kennt, muss der Angreifer im Durchschnitt etwa 1.000.000.000 (eine Milliarde) Mal versuchen, bevor er auf die Website gelangt. (Eigentlich die Hälfte davon, aber was auch immer.)

Sie können sehen, dass der Unterschied in der Sicherheit dramatisch ist.

Außerdem @Justin C. Die Kommentare von @ nealmcb bieten zusätzliche orthogonale Gründe, um sowohl einen Benutzernamen als auch ein Passwort zu benötigen. Jeder dieser Gründe würde ausreichen; Zusammengenommen ist der Fall, dass sowohl ein Benutzername als auch ein Passwort erforderlich sind, umso stärker.

#7
+1
mrnap
2011-03-05 02:27:53 UTC
view on stackexchange narkive permalink

Theoretisch ist @Sigtran richtig, dass es immer besser ist, einen Benutzernamen zu haben. Nach einer allgemeinen Regel gilt: Je mehr Verschleierung desto mehr Sicherheit :) In der Implementierung in Situationen, in denen Sie keine UUID oder bestimmte Benutzerrechte benötigen, tun Sie dies wirklich nicht. Sie benötigen keinen Benutzernamen (so etwas wie ein allgemeines Repository, auf das mehrere Personen zugreifen). In diesen Szenarien ist es der richtige Weg, ein langwieriges und komplexes Passwort (alphanumerisch + Sonderzeichen) zu benötigen und es dann zu salzen.

#8
  0
JMB
2013-08-14 22:48:45 UTC
view on stackexchange narkive permalink

Der Grund, warum Sie sowohl einen Benutzernamen als auch ein Kennwort benötigen, besteht darin, dass Sie das eindeutige Salt des Benutzers nachschlagen können, bevor Sie das Kennwort hashen und überprüfen.

Ein typisches, sicheres Schema verfügt über eine Benutzertabelle mit mindestens 3 Spalten : Benutzername, Salt, Passworthash. Der PasswordHash ist das Passwort des Benutzers, dem das eindeutige Salt (eine zufällige, eindeutige Kombination von Zeichen) hinzugefügt und anschließend Ihren Hashing-Algorithmus durchlaufen wird. Bei der Authentifizierung wird der Benutzer anhand seines Benutzernamens gesucht, sein eindeutiges Salt zu seinem Kennwort hinzugefügt, das Ergebnis gehasht und überprüft, ob es mit dem Kennwort-Hash in der Datenbank übereinstimmt.

Wenn Sie nur das Kennwort hashen und in der Datenbank speichern Dann kann ein Angreifer, der Zugriff auf Ihre Benutzertabelle erhält, einige der gängigen Kennwörter mithilfe einer Regenbogentabelle (Liste der häufig verwendeten Kennwörter) ermitteln. Das heißt, sie nehmen die Liste der gängigen Passwörter, hashen sie alle und prüfen, ob eines von ihnen mit dem in Ihrer Datenbank gespeicherten Passwort übereinstimmt. Wenn jeder Benutzer ein eindeutiges Salt hat, dann müsste er dieses Salt zu jedem Passwort in der Regenbogentabelle hinzufügen und dann alle hashen, um zu sehen, ob er eine Übereinstimmung für diesen einen Benutzer findet. Dann müssen sie dies für jeden Benutzer in Ihrer Tabelle wiederholen. Dies erhöht die Berechnung, die erforderlich ist, um ein passendes Kennwort aus einer gestohlenen Benutzertabelle zu finden, massiv.



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 2.0-Lizenz, unter der er vertrieben wird.
Loading...