Frage:
Warum verwenden wir keine Einzeleingabeauthentifizierung?
Wissen Macht Frei
2016-11-02 13:03:23 UTC
view on stackexchange narkive permalink

Bei der Authentifizierung mit zwei Eingaben werden sowohl der Benutzername (möglicherweise öffentlich verfügbar) als auch das Kennwort (geheim gehalten) verwendet.

Zum Vergleich wird angenommen, dass die Länge des Benutzernamens der Länge des Kennworts entspricht, d. h , n Zeichen. Nehmen wir auch an, wir können nur Groß- und Kleinschreibung von a bis z verwenden. Wenn sowohl Benutzername als auch Passwort geheim gehalten werden, benötigen wir höchstens 26 ^ (2n) Versuche, um die Authentifizierung zu bestehen.

Betrachten Sie nun ein neues Authentifizierungssystem mit nur einer einzigen Eingabe. dh Passwort, das geheim gehalten wird von Länge 2n . Die zulässigen Zeichen unterscheiden nicht zwischen Groß- und Kleinschreibung und erstrecken sich von a bis z. Für dieses System müssen auch 26 ^ (2n) -Versuche bestanden werden.

Fragen

Warum verwenden wir keine Einzeleingabeauthentifizierung?

Wir verwenden die Authentifizierung mit nur einer Eingabe.Der Benutzername ist für die Identifizierung, nicht für die Authentifizierung.Anderes Problem.Betrachten Sie es so;Warum haben Sie als Person einen Namen * und * einen Schlüssel für Ihr Haus?Warum nicht nur der Schlüssel?
Es ist bereits mit Fingerabdruck und Augenscan gemacht.Das Problem ist, dass es für alle Benutzer eindeutig sein muss.Wenn Sie einen Benutzer auffordern, seine eigene Einzelauthentifizierung einzugeben, werden Fehler wie "bereits vorhanden" angezeigt.
@marcelm diese Logik ist fehlerhaft;Ihr Name wird beim Zugriff auf Ihr Haus nicht verwendet, es sei denn, Sie haben ein verrücktes High-Tech-Schloss, das Sie beim Einstecken des Schlüssels mündlich ansprechen müssen, um erfolgreich darauf zugreifen zu können.Wenn überhaupt, ist es ein Beispiel für eine Authentifizierung mit einer Eingabe (dem Haus ist es egal, WER den Schlüssel hat, nur dass der Schlüssel zum Schloss passt).
@DoktorJ In Ihrem Beispiel ist die Adresse der Benutzername.Wenn Sie nur den Schlüssel (das Passwort) haben, aber nicht die Adresse (den Benutzernamen), können Sie durch die Stadt laufen und den Schlüssel in verschiedenen Türen probieren, aber nur, weil Sie hineinkommen (der Schlüssel funktioniert in einem Schloss; das gleiche Passwort "hunter2"wird von mehreren Konten verwendet) bedeutet nicht, dass Sie in das * richtige * Haus gekommen sind.
@drewbenn Aber es ist egal, in wessen Haus du kommst.Sie nehmen nur das Wertvolle und gehen.Wenn Sie ein Passwort eingeben und das System Ihnen mitteilt, dass das Passwort vergeben ist, können Sie sich sofort bei diesem Konto anmelden und schlechte Dinge tun, ohne daran interessiert zu sein, um welches Konto es sich handelt.
@DoktorJ Als ich das letzte Mal meinen Hausschlüssel verlor und eine Vermietungsagentur kontaktierte, musste ich mich (auf überzeugende Weise) ausweisen, bevor sie einen neuen ausstellen konnten.
@the_lotus Sie sollten Ihren Kommentar eine Antwort machen
Das von OPs vorgeschlagene Schema funktioniert gut, ich habe es in Tahoe LAFS gesehen.
"Dang,` abc123` ist schon vergeben. Fudge, `abc1234` auch?! Diese Leute haben sicher Glück, dass sie die einfachen vor dem Rest von uns ausgewählt haben ..."
Sie können den Benutzernamen als eine Form von Salz betrachten.Es muss nicht geheim sein, aber Sie möchten, dass sie einzigartig sind.In der Tat ist es ziemlich sinnlos (nur unter Berücksichtigung der Sicherheit), eindeutige Benutzernamen und Salze für ihre Passwörter zu haben, wenn es eine 1-zu-1-Zuordnung gibt.In der Praxis kann es nützlich sein, wenn Sie das Ändern von Benutzernamen zulassen möchten, ohne das Salt zu ändern.(und einen neuen Hash speichern müssen)
Siehe auch diese frühere Frage (zusätzlich zu den Duplikaten): http://security.stackexchange.com/questions/2384/why-do-we-authenticate-by-prompting-a-user-to-enter-both-username-und Passwort
@drewbenn Ich würde sagen, die Adresse ähnelt der URL, hat aber immer noch eine Authentifizierung mit nur einer Eingabe.Ich brauche die Adresse nicht, um meinen Schlüssel in einer bestimmten Tür zu probieren.In ähnlicher Weise verwenden Sie bei einer Authentifizierung mit nur einer Eingabe immer noch nur ein einzelnes Token. Es kommt nur darauf an, ob Sie dieses Token auf der richtigen Site verwenden oder nicht.
Zehn antworten:
#1
+71
S.L. Barth - Reinstate Monica
2016-11-02 13:08:16 UTC
view on stackexchange narkive permalink

Wenn Sie sich für einen Dienst anmelden, haben Sie gute Chancen, dass "Dieser Name wird bereits verwendet, wählen Sie einen anderen" - oder etwas in diesem Sinne.

In dem von Ihnen vorgeschlagenen System würde dies der Fall sein Sagen Sie, dass der Zugangscode verwendet wird - großartig, öffnen Sie einen neuen Browser und melden Sie sich mit diesem Zugangscode an! Sie haben gerade das Konto eines anderen entführt.

Sie können eine beliebige Anzahl vorhandener Zugangscodes finden, indem Sie einfach versuchen, Ihren eigenen zu ändern.

Und was ist, wenn Sie Ihren Zugangscode vergessen haben? ? Dies kann gemindert werden, wenn das System Ihre E-Mail-Adresse kennt und Ihnen einen neuen Zugangscode senden kann. Dann stehen Sie jedoch einer Authentifizierung mit zwei Eingaben nahe. Sie können sich auch mit Ihrer E-Mail-Adresse anmelden.

Der Zweck von "Benutzername" besteht also nicht darin, die Anzahl der Versuche zu erhöhen, die erforderlich sind, um die Authentifizierung zu unterbrechen, oder?
@SingleFighter In der Tat ist es nicht.Beachten Sie, dass dies von der Annahme abhängt, dass die Länge des Benutzernamens / Passworts / Zugangscodes fest ist.In der Praxis erlaubt ein gutes System Passwörter beliebiger Länge.
"Sie können sich genauso gut mit Ihrer E-Mail-Adresse anmelden." - Nun, es gibt eine nette Sache namens [passwordless auth] (https://www.sitepoint.com/passwordless-authentication-works/)..Für die nicht wirklich häufig verwendeten Dienste kann dies emuliert werden, auch wenn Sie das Kennwort benötigen, aber das Kennwort per E-Mail wiederherstellen / zurücksetzen können. Sie können einfach ein langes zufälliges Kennwort einrichten, das Sie einmal verwenden und vergessen können.Wenn Sie sich das nächste Mal anmelden müssen, bitten Sie das System, das Kennwort zurückzusetzen und ein neues, einmalig langes, zufälliges Kennwort einzugeben.:) :)
@IvanKolmychek Interessant!Ich habe lange gedacht, dass so etwas möglich sein sollte.Ich würde etwas Zeit brauchen, um zu überprüfen, ob diese Methode so sicher ist, wie ich hoffe.In der Zwischenzeit sollten Sie diese Methode als Antwort veröffentlichen.
Würden zugewiesene Zufallscodes leicht Kollisionen erzeugen, wenn viele Codes verfügbar wären?Wenn Sie eine kleine Benutzerbasis und einen großen Codebereich haben, könnten Sie Versuche, das Problem zu mindern, drosseln, und die regelmäßige Neuausgabe neuer Zufallscodes an alle könnte die Wahrscheinlichkeit verringern, dass ein Problem behoben werden kann.Ich stelle mir vor (Zulässige Gesamtversuche pro Sekunde * Sekunde zwischen Neuausgabe) / (Code Space / Anzahl der Benutzer) ist so etwas wie eine Chance, kaputt zu gehen
@notstoreboughtdirt Wenn diese Codes immer nur kopiert und eingefügt oder auf andere Weise nicht gespeichert würden, könnten Sie eine sehr geringe Bruchwahrscheinlichkeit erzielen.Beispielsweise können Sie base64 (a-z, A-Z, 1-9, -, /) an den meisten Stellen verwenden, an denen Sie einen solchen Code benötigen, und ein 20-stelliger base64-Code bietet 1,33 x 10 ^ 36 Möglichkeiten.Wenn jedes Sandkorn auf der Erde eine neue Erde wäre und Sie alle Sandkörner auf allen neuen Erden hochzählen würden, würde es nicht 10 ^ 36 erreichen, also sehr sicher.Angenommen, Sie begrenzen es auf 10 Versuche / Sek. Für eine Milliarde Benutzer, die 10 bis 18 Jahre bis zur ersten Kollision sind.Ich würde sagen, ziemlich sicher.
@notstoreboughtdirt: zufällig generierte Codes ähneln letztendlich der SSH-Schlüsselpaarauthentifizierung: Niemand kann sich an sein "echtes Passwort" erinnern, es ist einfach nicht menschlich machbar, also tragen sie es in einer verschlüsselten Datei herum und merken sich nur die Passphrase für die Verschlüsselung.Dies hat einen großen Vorteil gegenüber der normalen Passwortanmeldung, aber auch einige Usability-Probleme.
Ich habe mich nicht wirklich mit Mathe beschäftigt, aber ich dachte in kleinerem Maßstab.Was wäre, wenn das System nur wenige tausend Benutzer hätte und die Gesamtverbindungen auf nur 10 pro Sekunde beschränkt wären?Die Rückseite eines Umschlags weist darauf hin, dass ich möglicherweise nur 10 Ziffern benötige, wenn ich jedes Jahr neu ausstelle.10 Ziffern sind möglicherweise nicht zu unangenehm, um sie sich für etwas zu merken, das es wert ist, geschützt zu werden.
"Sie haben eine gute Chance zu bekommen" Dieser Name wird bereits verwendet, wählen Sie einen anderen "" - das hängt wirklich von der minimal erforderlichen Begeisterung für den Token ab, er könnte willkürlich hoch genug eingestellt werden, dass Sie mit größerer Wahrscheinlichkeit im Lotto gewinnen würdenJackpot jeden Tag für den Rest Ihres Lebens,
Ich denke nicht, dass es das Problem des "vergessenen Zugangscodes" lösen kann, aber wie wäre es mit einem System, das einige Eingaben von Ihnen entgegennimmt und es als Startwert für einen Zufallszahlengenerator verwendet und Duplikate im Back-End & stillschweigend neu generiert?Ihnen ein Zugriffstoken (Benutzername + Passwort) zurückgeben?Dies hat den Vorteil, dass nur ein einziges Feld für die Anmeldung für Benutzer benötigt wird, aber den Nachteil, dass sie nicht ihre eigenen Anmeldeinformationen auswählen können.
@Bruno warum überhaupt einen Samen sammeln?Besonders wenn man bedenkt, dass dies die Sicherheit des Systems mehr beeinträchtigt als es hinzufügt, da es nur wenige Dinge gibt, die * weniger * zufällig sind als Eingaben von Personen, die aufgefordert werden, eine Nummer anzugeben, und die sich in keiner Weise wirklich darum kümmern.Verwenden Sie einen kryptografisch sicheren Zufallszahlengenerator und Sie sind viel sicherer mit viel weniger "Wofür veranlassen sie mich, eine Zufallszahl zu wählen?"von Ihren Benutzern.
@TheEnvironmentalist Sie haben Recht, ich habe mich zu sehr darauf konzentriert, das ursprüngliche Anmeldeszenario der Antwort für die Bereitstellung von Eingaben beizubehalten.In diesem Modell müssen Sie überhaupt keinen Samen sammeln.Ich habe zu viel Minecraft gespielt ...
#2
+15
Toby Speight
2016-11-02 19:52:48 UTC
view on stackexchange narkive permalink

Benutzername ist eine Kennung , eine Bezeichnung, die angibt, welcher Benutzer Sie sind, und angibt, welche Ressourcen Ihnen gehören (oder auf Sie verweisen).

Das Kennwort ist ein Authentifikator , ein Beweis dafür, dass Sie diese Benutzeridentität annehmen dürfen.

Benutzernamen können nicht geheim sein, da ein Informationssystem dieses Wissen im Klartext benötigt, um sie zu kennzeichnen Ressourcen und um Ihre Verwendung von Ressourcen zu autorisieren. Passwörter sollten geheim sein, sogar für den Dienst und seine Betreiber - aus diesem Grund werden gespeicherte Passwörter mit einer Einwegfunktion gehasht.

Mit "Ressourcen" oben bin ich bewusst inklusiv sein. Bei einer Benutzeranmeldung können es sich um Dateien und Prozesse handeln. Als Datenbankbenutzer verfügen Sie über Tabellen und andere Datenbankobjekte. Bei einer Website können dies Ihre Beiträge und Reputationspunkte sein.

Genau richtig.Identität und Authentifizierung sind * verschiedene Informationen *.
@jpmc26, aber sie müssen nicht unbedingt sein, daher die ziemlich interessante Frage
@TheEnvironmentalist: Sie können so gut wie zwei beliebige Informationen zu einer langen Zeichenfolge zusammenführen und dann die Logik an anderer Stelle verwenden, um den Unterschied auszugleichen.In diesem Fall erhalten Sie wahrscheinlich eine nicht gemeinsam genutzte Datensatz-ID, um den Benutzer zu identifizieren und eine Verknüpfung herzustellen, sobald das lange Authentifizierungstoken eingegeben wurde.Der Benutzer hätte also immer noch eine Identität, nur haben Sie ihn nicht explizit danach gefragt und gehofft, dass sein Authentifizierungstoken eindeutig ist, damit Sie ihn finden können.Es ist üblicher (und ich würde eine bessere Praxis argumentieren), die Probleme der Identität und der Authentifizierung getrennt und explizit zu halten.
#3
+8
Gremlin
2016-11-02 19:50:19 UTC
view on stackexchange narkive permalink

In einigen Fällen verwenden wir es.

Ein Beispiel ist die Funktion Freigabe über einen Link von Google-Dokumenten. Der Link enthält einen Zugriffsschlüssel oder eine Dokument-ID mit 45 alphanumerischen Zeichen. Dies ist lang genug, um sowohl die Einzigartigkeit sicherzustellen als auch das Brute-Forcing zu erschweren.

Dies ist keine Authentifizierung, sondern eine Autorisierung.Google muss nicht wissen, wen Sie per URL-Token autorisieren sollen.
@bunyaCloven Es ist beides.Bei einem Link zum Zurücksetzen des Kennworts verweist der Link sowohl auf das Konto als auch auf die Berechtigung zum Ausführen einer bestimmten Aktion (Ändern des Kennworts) für dieses Konto.Eoins Vorschlag für linkbasierte Schlüssel ist ein gutes Beispiel, das die Probleme der Eindeutigkeit und Anfälligkeit für Wörterbuchangriffe löst, indem es das "Passwort" für Sie auswählt und es viel zu lang für Brute-Force und zu zufällig macht, ein Wörterbuch anzuwendenAttacke.
@TheEnvironmentalist bunyaCloven ist korrekt.Dies ist keine Bestätigung Ihrer Identität hier.Es wird davon ausgegangen, dass jeder mit dem Link autorisiert ist.Ihre Identität wird niemals in Frage gestellt.
@TheEnvironmentalist ist es nicht.Ein Link zum Zurücksetzen des Kennworts ist ein Autorisierungstoken, das an ein authentifiziertes Postfach gesendet wird.
@bunyaCloven Philosophische Unterschiede, nehme ich an.Wenn Sie davon ausgehen, dass das Erfordernis der Kenntnis (wenn Sie so wollen) des Besitzes dieses Links ausreichend für die Authentifizierung ausreichen, nicht direkt über die Kenntnis des Passworts, sondern per Proxy, dann ist es Authentifizierung.Wenn Sie die Authentifizierung etwas traditioneller definieren als eine Herausforderung, die nur vom Verstand allein beantwortet werden kann und die dadurch geschützt ist, dass sie niemals geteilt worden ist, im Gegensatz zu seiner nie gestolperten wie im zweiten Fall, dann ist es nicht.Es hängt alles davon ab, wo Sie Ihre Linie in den Sand ziehen.
-1
Für die Authentifizierung sind zwar Kenntnisse erforderlich.Die Absicht der Daten definiert jedoch, ob der Besitz zu Authentifizierungs- oder Autorisierungszwecken dient.Die Verwendung eines öffentlichen Schlüssels zum Senden verschlüsselter Daten impliziert beispielsweise eine Autorisierung: Jeder kann solche Daten senden.Die Verschlüsselung mit einem öffentlichen Schlüssel impliziert jedoch eine Authentifizierung: Niemand außer Ihnen kann solche Daten senden, die mit Ihrem verifizierten öffentlichen Schlüssel verschlüsselt werden können.
API-Schlüssel sind ein weiteres Beispiel für die Authentifizierung mit einer Eingabe.Es gibt eine Vielzahl verschiedener Tools, mit denen Sie einen API-Schlüssel für einen Benutzer generieren, der dann selbst zur Identifizierung und Authentifizierung verwendet wird, um auf dieses Tool zuzugreifen.Der Nachteil ist natürlich, dass der Endbenutzer nicht angeben kann, um welchen Schlüssel es sich handelt. Er muss vom Server ausgewählt werden, damit er eindeutig und sicher ist.
#4
+6
TheEnvironmentalist
2016-11-02 19:55:47 UTC
view on stackexchange narkive permalink

Dieses Authentifizierungssystem mit nur einer Eingabe wäre interessant, es gibt jedoch einige Sicherheitsprobleme:

Das Haupthindernis ist das Erfordernis der Eindeutigkeit. Damit sich verschiedene Benutzer bei ihren jeweiligen Konten anmelden können, müssen die Anmeldeinformationen (normalerweise Benutzername + Passwort) eindeutig sein. Theoretisch bedeutet dies, dass in einem typischen System mit zwei Eingaben Benutzernamen nicht unbedingt eindeutig sein müssen, solange nicht zwei Benutzer denselben Benutzernamen und verwenden. Das Problem ist, dass in einem System mit nur einer Eingabe nur ein einzelnes Kennwort verfügbar ist. Dies bedeutet, dass jeder Benutzer ein anderes Kennwort als der andere haben muss. Dies führt zu einer Reihe von Sicherheitslücken:

  1. Sie können davon ausgehen, dass in jedem ausreichend beliebten Dienst eine Reihe offensichtlicher Kennwörter von jemandem verwendet werden. Wenn Sie nur versuchen, sich mit Passwörtern wie "Passwort", "12345" und "Beatles" anzumelden, könnten Sie wahrscheinlich auf mindestens einige Konten zugreifen.
  2. Wie von S.L. Barth, jeder kann vorhandene Passwörter finden, indem er versucht, sein Passwort zu ändern, bis er auf die Meldung "Passwort bereits verwendet" stößt. Da Kennwörter eindeutig sein müssen, müssen Sie einen Benutzer daran hindern, ein vorhandenes Kennwort auszuwählen, um festzustellen, dass das Kennwort bereits verwendet wird.
  3. Wörterbuchangriffe: Dies ist im Grunde nur die logische Summe der Punkte 1 und 2. Wenn Sie ein Konto erstellen und dann ein Skript versuchen lassen, das Kennwort mithilfe eines Kennwortwörterbuchs zu ändern, indem Sie jedes "bereits verwendete" Kennwort aufzeichnen, auf das es unterwegs stößt, können Sie schnell und einfach eine Liste erstellen Tausende oder sogar Millionen vorhandener Passwörter. Dies ist alles, was Sie benötigen, um in all diese Konten einzubrechen.
  4. ol>

    Beachten Sie, dass eine interessante Sicherheit, die Sie daraus ziehen, darin besteht, dass es zwar sehr einfach wäre, in eine beliebige Anzahl von zufälligen Konten einzubrechen (wie oben beschrieben), es jedoch weitaus schwieriger wäre Brechen Sie bei einem gezielten Angriff in ein Konto ein. Da Kennwörter eindeutig sein müssen, erhalten Sie in einem System mit nur einer Eingabe komplexere Kennwörter als in den heutigen Systemen mit zwei Eingaben, und es gibt keinen Benutzernamen, mit dem Sie einen bestimmten Benutzer ansprechen können. Dies ist also die einzige Möglichkeit Wenn Sie in ein Zielkonto einbrechen, müssen Sie sich brutal in alle Konten hineinzwingen, bis Sie das gewünschte Konto erhalten. Außerdem ist es schwieriger zu bestätigen, dass das Konto, bei dem Sie angemeldet sind, das gesuchte Konto ist, da Sie den Benutzernamen nicht als Identitätsnachweis verwenden können. Das ist ein wirklich interessanter Sicherheitseffekt, also Bravo.

Ich habe eine "Authentifizierung mit nur einer Eingabe" gesehen, die sich mit Problem Nr. 2 befasst, indem der Computer und nicht der Benutzer die letzten Buchstaben des Kennworts generieren.
Was passiert, wenn ich dann den Computer wechsle?Verliere ich mein Konto?
#5
+5
Serge Ballesta
2016-11-02 17:18:27 UTC
view on stackexchange narkive permalink

Der Benutzername ist eine ID und sollte sich niemals ändern (*). Es wird empfohlen, das Kennwort regelmäßig zu ändern und jedes Mal, wenn es kompromittiert werden könnte.

Da diese beiden Teile eine unterschiedliche Lebensdauer haben, ist es besser, sie getrennt zu halten.

(*) Tatsächlich gibt es Anwendungsfälle, bei denen ein Benutzername geändert werden muss, z. B. wenn zwei Entitäten und zwei verschiedene Benutzer, die denselben Benutzernamen verwenden, zusammengeführt werden. Die Lebensdauer eines Benutzernamens sollte jedoch viel länger sein als die eines Passworts

Ich glaube, die Frage, die gestellt wurde, warum dies der Fall sein muss.Warum sollte sich der Benutzername niemals ändern?Warum ist das System mit einem Eingang nicht funktionsfähig?
@TheEnvironmentalist Nun, die Frage implizierte auch, dass der Benutzername explizit Teil der Sicherheit ist, indem seine Verwendung mit der eines Passworts gleichgesetzt wird.Die Antwort besagt, dass dies nicht wahr ist und die beiden Dinge getrennt gehalten werden sollten.Es ist eine gültige Antwort.
Leider müssen sich Benutzernamen oft * ändern *.Daher wird häufig eine eindeutige ID verwendet, um den Benutzernamen Eigenschaften zuzuordnen.
@BrianKnoblauch: Ich weiß, dass sich Benutzernamen ändern können, aber ihre Lebensdauer sollte viel länger sein als die eines Passworts.Wie auch immer, ich habe meine Antwort bearbeitet.
Diese beiden Teile haben unterschiedliche Lebensdauern, da sie getrennt sind und unterschiedliche Rollen erhalten, nicht umgekehrt.
Best Practices für die Sicherheit empfehlen, das Kennwort nur zu ändern, wenn die Möglichkeit besteht, dass es kompromittiert wird.Änderungen zum Zwecke der Änderung verringern nur die Sicherheit, da der Aufwand beim Ändern normalerweise neue Leckvektoren einführt.
#6
+2
John McNamara
2016-11-02 23:56:44 UTC
view on stackexchange narkive permalink

Passwortmode meistens

und in der Vergangenheit wären zusätzliche Speicher- / Verarbeitungsanforderungen erforderlich gewesen, die jetzt viel billiger sind.

Es gibt keinen wesentlichen technischen Grund dafür

Ein Benutzer könnte sich nur mit einem sicheren Passwort wie "9so48dsf67 $ h9e6ghfoubyf2gfuDywbnefo8g2H3fg2fkngsd6_g3ty7g63gs74g" anmelden und der Server könnte es automatisch mit der relevanten Identität abgleichen und sicher annehmen, dass es korrekt ist.

Dies ist effektiv das, was Google korrekt ist.

Dokumente usw. werden beim Generieren einer freigegebenen Dokument-URL verwendet.

Sie verwenden sie nur für den Zugriff auf dieses eine Dokument, nicht zur Identifizierung.

dh

Sie tun dies nicht Kennen Sie Ihre Identität (kein Anmeldename)

Aber die URL authentifiziert sich (ist in ihrer Datenbank gültig)

und auch Erteilt Ihnen automatisch die Berechtigung (zum Anzeigen oder Bearbeiten dieses Dokuments)

Das System kann problemlos mit sich ändernden / verlorenen Kennwörtern, "Spitznamen", E-Mail-Adressen usw. umgehen.

Die Leute sind es SEHR gewohnt, ihre eigenen viel kürzer zu wählen und viel weniger sichere Passwörter, die diesen Ansatz zu unsicher machen würden, um praktisch zu sein.

Menschen sind auch sehr an die Methode "Login" + "Passwort" gewöhnt und würden umfangreiche Schulungen benötigen, um eine Alternative zu verstehen und ihr zu vertrauen.

Ich denke, das liegt daran, dass die Leute erwarten, dass sie das Passwort ändern können, während sie immer noch als derselbe Benutzer erkannt werden.
@Agent_L, können sie das Passwort ändern.Entweder während sie bereits in ihrem Konto angemeldet sind oder über das übliche Formular "Ich habe mein Passwort vergessen", in dem sie einfach ihre E-Mail-Adresse eingeben und sonst nichts.Die einzige Einschränkung besteht darin, dass das Passwort / Token / wie auch immer Sie es aufrufen möchten, eine ausreichend hohe Entropie aufweisen muss.Die meisten Leute sind einfach nicht dazu bereit.
Ich war schlecht, weil ich unklar war. Ich bezog mich nur auf Ihren letzten Satz.Ich habe die Google-Dokumente nicht gemeint, da Sie sich zuerst mit Login und Passwort anmelden, um den Authentifizierungslink zu generieren.Ich meinte eine allgemeine Situation, in der Login und Pass zu einer Zeichenfolge zusammengeführt werden. Dadurch haben Sie das Gefühl, dass Sie das Passwort nicht ändern können, sondern die Identität behalten.
#7
+2
João Angelo
2016-11-03 18:55:55 UTC
view on stackexchange narkive permalink

Wikipedia hat Folgendes zur Authentifizierung zu sagen:

Im Gegensatz zur Identifizierung, die sich auf die Angabe oder anderweitige Angabe eines Anspruchs bezieht, der angeblich eine Person bestätigt Authentifizierung ist der Prozess der tatsächlichen Bestätigung dieser Identität .

(Hervorhebung liegt bei mir) sub>

Stellen Sie sich in der realen Welt vor, Sie gehen zur Bank:

  1. Sie: Hallo, mein Name ist John Doe und ich möchte ein Konto eröffnen.
  2. Sachbearbeiter: Können Sie Geben Sie mir einen Identitätsnachweis für Ihre Identität?
  3. Sie: (Bietet einen Personalausweis oder einen Führerschein)
  4. ol>

    Auf Punkt eins Sie Sie haben sich als John Doe identifiziert und in Punkt drei diese Identität auf eine Weise bewiesen, der die Bank vertraut. In der realen Welt wurde Ihre Identität normalerweise vor langer Zeit von Ihren Eltern entschieden, als sie Ihren Namen wählten.

    In der Online-Welt können Sie auf Websites, die das traditionelle Registrierungsverfahren mit zwei Eingaben verwenden, dies tun Wählen Sie Ihre Identität und auch die Art und Weise, wie Sie diese Identität beweisen. .

    Es ist richtig, dass Sie versuchen könnten, sowohl die Identität als auch den Beweis in denselben tatsächlichen Daten zusammenzuführen, aber es gibt sie wirklich irgendein Vorteil ? Der Benutzername sowie weitere Daten, die als Beweis verwendet werden sollen, werden bereits von allen verstanden, da sie in gewisser Weise mit dem tatsächlichen Leben übereinstimmen. Darüber hinaus wird die zugrunde liegende Implementierung viel einfacher, wie in anderen Antworten und Kommentaren angegeben.

    Es ist auch richtig, dass Sie gezwungen sind, auf jeder Online-Site, die Sie besuchen, immer eine Identität und einen Beweis zu erstellen ist irgendwie langweilig . Insbesondere wenn man bedenkt, dass der Identitätsteil innerhalb dieser Site eindeutig sein muss und Sie ein später Anwender sind, was bedeutet, dass alle coolen Identitäten bereits ausgewählt wurden.

    Zunächst wurde dies gelöst, indem Ihre E-Mail-Adresse als Identität akzeptiert wurde Auf diese Weise muss der Benutzer nicht darüber nachdenken, und die Eindeutigkeit ist weiterhin gewährleistet.

    Einige gehen jedoch noch einen Schritt weiter und versuchen, den Prozess noch weiter zu vereinfachen, indem sie die sogenannte kennwortlose Authentifizierung zulassen. Das Coole dabei ist, dass Sie weder eine neue Identität noch ein neues Kennwort erstellen müssen, um die Identität zu prüfen.

    Ein Beispiel hierfür ist die Auth0-Implementierung der kennwortlosen Authentifizierung, mit dem sich ein Benutzer bei einer Site entweder über einen Link authentifizieren kann, der über seine E-Mail-Adresse bereitgestellt wird oder über einen einmaligen Code, der über eine SMS bereitgestellt wird.

    Mit kennwortlosen Verbindungen in Auth0 können sich Benutzer anmelden, ohne sich ein Kennwort merken zu müssen. Dies verbessert die Benutzererfahrung , insbesondere bei mobilen Anwendungen, da Benutzer nur eine E-Mail-Adresse oder Telefonnummer benötigen, um sich für Ihre Anwendung zu registrieren.

    Ohne Kennwörter benötigt Ihre Anwendung keine Um ein Verfahren zum Zurücksetzen des Kennworts zu implementieren, vermeiden Benutzer die unsichere Praxis, dasselbe Kennwort für viele Zwecke zu verwenden.

    (Schwerpunkt liegt bei mir) sub>

    Aus Sicht des Benutzers ist dies sehr einfach durchzuführen und aus Sicht der Site, die diese Art der Authentifizierung verwendet, ist es immer noch möglich, wiederkehrende Benutzer zu identifizieren, indem sie entweder ihre E-Mail-Adresse oder ihre Telefonnummer abgleichen.

    Wenn Sie darüber nachdenken, vereinfacht dies nur das, was viele Benutzer früher getan haben. Ich gebe zum Beispiel zu, dass ich oft, wenn ich mich bei einer neuen Site authentifizieren wollte, nur meine E-Mail-Adresse und ein zufälliges Passwort verwendet habe, an das ich mich nie erinnern würde, und für den Fall, dass mein Browser die Sitzung oder das gespeicherte Passwort verloren hätte Setzen Sie einfach das Passwort zurück.

    Offenlegung : Ich arbeite bei Auth0. sub>

"Es ist wahr, dass Sie versuchen könnten, sowohl die Identität als auch den Beweis in denselben tatsächlichen Daten zusammenzuführen, aber gibt es wirklich einen Vorteil?"Das ist die interessante Frage.Es ist trivial zu tun, wir haben viele Gründe, warum Benutzer es nicht mögen würden, aber gibt es irgendwelche wirklich einzigartigen praktischen Vorteile?
Meiner Meinung nach sind alle Nachteile und keine Vorteile, wenn wir den Benutzer dazu zwingen, dieses einzelne Datenelement für immer zu kennen und geheim zu halten.Dies gilt umso mehr, als dieses einzelne Datenelement von der Anwendung zufällig generiert werden müsste, da es einfach nicht funktionieren würde, wenn der Benutzer es auswählen könnte.
Nichts im Schema impliziert "für immer".Das Token kann vom Benutzer leicht per E-Mail / SMS geändert werden, genau wie die aktuellen Verfahren zum "Passwort verloren".
Wenn Sie E-Mail und SMS in den Mix einbringen, haben Sie bereits ein anderes Stück als Benutzeridentität, auch wenn der Benutzer es nicht eingeben muss.Es ist die passwortlose Sache, die ich erwähnt habe.Wenn Sie wirklich ein einziges Stück für die Identität und Authentifizierung verwenden, trägt der Benutzer die gesamte Verantwortung auf seinen Schultern.Sie können es drehen lassen, aber der Benutzer muss immer die aktuelle kennen ... für immer oder bis er die Site satt hat.
#8
+1
paparazzo
2016-11-02 23:27:36 UTC
view on stackexchange narkive permalink
Die

PKI-Zertifikat-basierte Authentifizierung ähnelt einer Benutzer-ID und einem Kennwort in einem.

Signieren Sie den öffentlichen Schlüssel

PKI

#9
+1
kubanczyk
2016-11-03 19:54:35 UTC
view on stackexchange narkive permalink

Dies ist mit Passwörtern nicht wirklich möglich. Dies ist mit jedem Schema möglich, bei dem der Schlüssel / das Geheimnis / der Berechtigungsnachweis / das Token / was auch immer auf dem Computer eines Kunden gespeichert ist und nicht im Gehirn des Menschen.

Gewunden? Drehen Sie genau das Gleiche um: Wenn Sie einen ausreichend zufälligen und ausreichend komplizierten Schlüssel / Geheimnis / Berechtigungsnachweis / Token / was auch immer haben, ist es nicht einmal sinnvoll, einen Menschen nach einem Benutzernamen zu fragen , ein Spitzname, eine GUID, jede andere Identifikation für eine alltägliche Authentifizierung. Die Software teilt ihnen dies alles mit.

Wenn Ihre Software Suckpuppet -Konten nicht begrüßt. (Einige sind willkommen. Zum Beispiel ist ssh mit "sockpuppets" zufrieden, verschiedenen Konten, die von einem Menschen verwendet werden. Es fragt nach dem Kontonamen, selbst wenn Sie einen RSA-Schlüssel angeben. Sockpuppet RSA-Privatschlüssel, die nebeneinander auf demselben Gerät sitzen, wären unnötige Komplikationen, nicht mehr Sicherheit.) Die Frage nach einem Spitznamen ist der einfachste Weg, um Sockenpuppen zu unterstützen.

Der Schlüssel "Ausreichend kompliziert" impliziert, dass wir niemals eine Kollision erwarten. Dies bedeutet, dass wir niemals erwarten müssen, dass es gesalzen wird. Dies impliziert, dass sich ein durchschnittlicher Mensch nicht daran erinnern kann . Und es bedeutet, dass wir nicht die zusätzliche Komplexität benötigen, die der Mensch benötigt, um sich an den Benutzernamen zu erinnern.

Zurücksetzen des Kontos

Das einzige Problem wird zurückgesetzt, nachdem der Schlüssel verloren gegangen ist oder nachdem er kompromittiert wurde. Dies bedeutet ein verlorenes oder kompromittiertes Gerät. Hier müssen wir eine sicherere Authentifizierung verwenden (möglicherweise auch eine problematischere). Benötigen Sie einen Benutzer, der sich hier an seinen Spitznamen erinnert? Wenn Sie den Benutzer nur nach dem Mädchennamen einer Mutter fragen, ist die Kollision nahezu sicher. Das bedeutet nicht, dass Sie einen Spitznamen benötigen, sondern dass die Nachnamenauthentifizierung zu schwach ist! Bei allen Angriffen ging es um die Mädchennamen der armen Mütter. Sie müssen jedoch wahrscheinlich nach einer globalen Kennung außerhalb der App fragen, höchstwahrscheinlich nach einer Mobiltelefonnummer für die SMS-Überprüfung (dies schließt die Gefahr aus, dass Angreifer Ihr Mobiltelefon kontrollieren).

Alternatives Schema ist e -mail-Überprüfung, für die auch eine globale Kennung außerhalb der App erforderlich ist (dies schließt die Gefahr aus, dass Angreifer Ihr Gerät kontrollieren, daher ist es in dieser Einstellung sehr schwach).

Beachten Sie dies in den meisten Fällen Menschen müssen sich ihre globale Kennung nicht merken, aber manchmal müssen sie sie überprüfen und manuell eingeben.

Alternatives Schema ist die Überprüfung des vorab freigegebenen Papiers: Bitten Sie den Benutzer um ein Einmalkennwort Nummer 04 von der Papierkarte, die ihnen bei der Kontoeröffnung zugesandt wurde. Es ist ein Fall, in dem ich es praktisch finde, eine "triviale geheime" Authentifizierung hinzuzufügen, damit fast jede Person, die einen Brief erhält, den Zugriff nicht nur zum Spaß oder aus purer Neugier zurücksetzt. Es könnte "Welche Postleitzahl haben wir verwendet, um dieses Papier zu verschicken?" Sein, es könnte der gefürchtete Mädchenname sein, aber es könnte auch einen Spitznamen verwenden.

Passwörter, an die sich Menschen erinnern

Das Passwort oder ein kurzer geheimer Text, an den sich ein Mensch erinnern könnte, ist ein minderwertiges Schema, das längst überfällig ist. Die damit verbundenen unnötigen Kosten umfassen:

  • Seite "Bitte anmelden"
  • "Dieser Spitzname ist belegt" Problem
  • "Dieses Passwort ist zu schwach" Problem
  • Notwendigkeit eines serverseitigen Salzes (Upgrade des schwachen Geheimnisses auf ein wirklich zufälliges, um Regenbogentabellen entgegenzuwirken)
  • KeePass und ähnliche Datenbanken - überkomplizierte Lösung für ein einfaches Problem, bei dem ein ordnungsgemäßes Schema für alte Anmeldeaufforderungen verwendet werden muss

Diese verschwinden alle mit einem maschinell gespeicherten Schlüsselschema (symmetrisch oder asymmetrisch, Letzteres schlug vor).

#10
  0
Mirinth
2016-11-03 02:54:00 UTC
view on stackexchange narkive permalink

Wir verwenden es nicht, weil es unpraktisch ist.

Stellen Sie sich vor, Sie haben eine riesige Datenbank mit Benutzern, beispielsweise 8 Milliarden, weil jeder auf der Erde Ihre Website nutzt. Jemand hat Ihnen nur die einzige Eingabetaste gegeben. Woher wissen Sie, ob sie in der Datenbank enthalten sind?

Sie können Schlüssel nicht einfach speichern und nachschlagen, da es sich im Grunde genommen um Klartextkennwörter handelt und das Speichern von Kennwörtern im Klartext schlecht ist. Sie können es mit md5 auch nicht ein paar hundert Mal hashen, da Sie für Regenbogentabellen anfällig wären. Sie müssen einen geeigneten Passwort-Hashing-Algorithmus wie bcrypt mit einem großen, zufälligen Salz verwenden.

Jetzt haben Sie einen Schlüssel und eine große Salztabelle, und Sie müssen es herausfinden welches geht mit diesem Schlüssel. Aber wenn Sie das Salz nachschlagen könnten, hätten Sie auch nur den Hash-Schlüssel nachschlagen können! Sie stecken fest.

Sie können den Schlüssel nur mit allen 8 Milliarden Salzen hashen und dann 8 Milliarden Mal in der Datenbank suchen (einmal nach jedem Schlüssel). Viele Leute schlagen vor, dass Sie das Hashing auf ungefähr 1/10 Sekunde einstellen. Stellen Sie sich Folgendes vor: 8 Milliarden Hashes mit jeweils 1/10 Sekunde würden 25 Jahre benötigen, um sich anzumelden.

Wenn Ihre Benutzer nicht besonders geduldig sind, benötigen Sie eine große Anzahl von Computern Alle diese Hashes parallel zu berechnen, was viel Geld kostet, das Ihre Kunden bezahlen müssen, wodurch die Konkurrenz attraktiver aussieht. Andernfalls müssen Sie den Arbeitsfaktor verringern, damit Hashes für Sie (und damit auch für Angreifer) leicht zu berechnen sind. Oder entwickeln Sie spezielle Hardware, die den gleichen Effekt hat wie die Senkung des Arbeitsfaktors, da Sie darauf wetten können, dass Angreifer sie auch kaufen.

All dies wird bequem umgangen, indem der Benutzer stattdessen einen Namen angibt. Der Name ist nicht geheim, daher kann er als einfacher Text in der Datenbank gespeichert werden. Anschließend kann die Datenbank ihre Tabellen nach Namen sortieren, damit der Server das mit dem Kennwort des Benutzers verbundene Salt effizient nachschlagen kann.

Deshalb werden wir wahrscheinlich immer Benutzernamen in der einen oder anderen Form haben: Wir benötigen einen Suchschlüssel, um den Anmeldevorgang effizient zu gestalten, und die Anforderungen an Salt- und Hash-Passwörter machen alles, was wie ein Passwort aussieht, zu einem schlechten Kandidaten für die Aufgabe.

Dies ist sicherlich die praktischste Antwort?Ein vernünftiges System speichert Passwörter nicht im Klartext oder nur im Hash.Es würde sie als Haschisch ** mit einem Salz ** speichern.Der Benutzername teilt dem System mit, welches Salt zur Überprüfung des Kennworts verwendet werden soll.Ohne das müssten Sie alle möglichen Salze gegen das eingegebene Passwort verwenden.
@Nick, ist nicht die einzige Möglichkeit, wie Passwörter gesalzen werden, und IIRC ist nicht der übliche Unix-Ansatz mit herkömmlichen passwd-Dateien (oder gleichwertig mit Shadow-passwd-Dateien).Dort ist das Salz zufällig und wird als erste Zeichen des verschlüsselten Passworts gespeichert.Es ist also nicht erforderlich, dass das Salz von der Benutzeridentität abgeleitet wird.
@Mirinth, Ich denke, es gibt einen Fehler in Ihrer Argumentation.Wenn die Benutzer-ID Teil des Passworts ist, wird sie * de facto * zu einem Salz für das Passwort.Anstelle von Regenbogentabellen für Salt + Passwort-Kombinationen würde ein Angreifer Regenbogen-Tabellen für Benutzername + Passwort-Kombinationen benötigen.
Adressierung * "Wir benötigen einen Suchschlüssel, um den Anmeldevorgang effizient zu gestalten" *, das ist der Vorgang, der immer noch effizient sein könnte.Die Dinge, die besonders problematisch sein könnten, sind eher Administrator- oder Bedieneraktionen. Wie würden Sie ein Zurücksetzen des Passworts anfordern, ohne eine Kennung, die Sie preisgeben könnten?(Beachten Sie, dass * "hier ist eine Liste der E-Mail-Adressen, die ich möglicherweise bei der Anmeldung verwendet habe" * keine wirkliche Antwort darauf ist, da Sie dann einen Benutzernamen in die Datenbank zurückgeführt haben).
** Salt ** ist ein zufälliger Text, der mit dem vom Menschen bereitgestellten Passwort verknüpft ist (lesen Sie: Das schwache Passwort wird zu einem zufälligen Passwort verbessert).Wenn das Passwort computergeneriert und völlig zufällig ist, enthält es bereits das gesamte benötigte Salz.
8 Milliarden Zeilen sind keine große Datenbank mehr: -]
@Toby: Nur wenn die Benutzer-ID zufällig ist.Benutzer erinnern sich jedoch nicht gerne an zufällige Dinge, sodass Sie erwarten können, dass sie sie irgendwo aufschreiben (und an einem Ort lassen, an dem sie leicht zu stehlen sind) oder einen Passwort-Manager verwenden, dem es egal ist, wie viele Felder ausgefüllt werden müssen.
@TobySpeight `Es ist also nicht erforderlich, dass das Salz von der Benutzeridentität abgeleitet wird` - Das Salz wird jedoch an das ** gehash ** -Kennwort angehängt, das in der Aufzeichnung für diesen Benutzer enthalten ist, sobald wir wissen, wer der Benutzer ist.Das Salz wird vom Benutzer nicht geliefert.Wenn ich "Schwertfisch" als Passwort eingebe, weißt du nicht, was das Salz ist.Um das * mit einem Salz * zu hacken, muss ich wissen, welches Salz.Ihr Argument ist rückwärts - ohne zu wissen, welcher Benutzer ich nicht weiß, welches Salz - und daher ist es wichtig, den Benutzer * zu kennen *.
@Toby: Können Sie erklären, wie Lookups immer noch effizient sein können?Wenn es eine Möglichkeit gibt, das Salz nachzuschlagen, ohne das nicht verwaschene Passwort zu speichern, würde mich das interessieren.
"Es ist also nicht erforderlich, dass das Salz von der Benutzeridentität abgeleitet wird" - Sie leiten es nicht ab, das wäre zu einfach.Das Salz wird zufällig generiert und als Teil der Benutzeridentität gespeichert.Wir müssen wissen, welcher Benutzer weiß, welches zufällige Salz verwendet werden soll, damit wir das angegebene Passwort authentifizieren können.
@Minrith - Wenn Sie "mkpasswd" installiert haben, können Sie dies selbst ausprobieren: "mkpasswd -s <<< password" verwendet jedes Mal ein zufälliges Salz, und Sie erhalten einen anderen Hash.Geben Sie jedoch den Hash an, z.`mkpasswd -s -S 00 <<< password` und Sie erhalten immer` 00xQPHYlVDIw6` (beachten Sie die `00` am Anfang).Das ist es, was in der Benutzerdatenbank gespeichert ist.Wenn Sie sich anmelden, wird Ihr Hash-Passwort nachgeschlagen (unter Verwendung Ihres Benutzernamens oder Ihrer ID), und die ersten beiden Zeichen des Hash-Passworts aus der Datenbank werden als Salt verwendet, wenn Sie das Passwort hashen, mit dem Sie sich anmelden.
Wenn das für einen Kommentar zu eng ist, stellen Sie ihn bitte als Frage (oder zeigen Sie mir auf eine vorhandene Frage), und ich schreibe ihn als Antwort.


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