Fragen

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.

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.

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.

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

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

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.

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)
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>}

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

Signieren Sie den öffentlichen Schlüssel

PKI

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

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.