Kürzlich hatte ich wieder Zeit, darüber nachzudenken, wie die Funktion für die sichere Passwortzurücksetzung funktionieren sollte, zunächst als ich diese Funktionalität in eingebaut habe und dann, als ich half, etwas Ähnliches für jemand anderen zu machen. Im zweiten Fall wollte ich ihm einen Link zu einer kanonischen Ressource mit allen Einzelheiten zur sicheren Implementierung der Passwortzurücksetzungsfunktion geben. Das Problem ist jedoch, dass es eine solche Ressource nicht gibt, zumindest nicht eine, die alles beschreibt, was ich für wichtig halte. Daher habe ich beschlossen, es selbst zu schreiben.
Sehen Sie, die Welt der vergessenen Passwörter ist tatsächlich ziemlich mysteriös. Es gibt viele verschiedene, vollkommen akzeptable Perspektiven und eine Menge ziemlich gefährlicher. Es besteht die Wahrscheinlichkeit, dass Sie als Endbenutzer ihnen schon oft begegnet sind; deshalb werde ich versuchen, diese Beispiele zu nutzen, um zu zeigen, wer alles richtig macht und wer nicht, und worauf man sich für die richtige Implementierung der Funktion in der eigenen Anwendung konzentrieren sollte.
Passwortspeicherung: Hashing, Verschlüsselung und (oh!) Klartext
Wir können nicht darüber diskutieren, was mit vergessenen Passwörtern zu tun ist, bevor wir nicht besprochen haben, wie sie gespeichert werden. In einer Datenbank werden Passwörter in einer von drei Hauptarten gespeichert:
- Klartext. Es gibt eine Spalte mit dem Passwort, das im normalen Textformat gespeichert wird.
- Verschlüsselt. Üblicherweise durch symmetrische Verschlüsselung (ein Schlüssel wird sowohl für die Verschlüsselung als auch für die Entschlüsselung verwendet), und die verschlüsselten Passwörter werden ebenfalls in einer Spalte gespeichert.
- Gehasht. Ein einseitiger Prozess (das Passwort kann gehasht werden, aber nicht entschlüsselt); das Passwort, hoffentlich, wird von Salt begleitet, und jeder von ihnen befindet sich in seiner eigenen Spalte.
Lassen Sie uns gleich mit der einfachsten Frage anfangen: niemals Passwörter im Klartext speichern! Niemals. Eine einzige Schwachstelle für , ein unbedacht gemachter Backup oder einer von vielen anderen einfachen Fehlern — und das war's, Game Over, alle Ihre Passwörter — das heißt, entschuldigen Sie, die Passwörter aller Ihrer Kunden werden öffentlich zugänglich. Natürlich würde dies eine enorme Wahrscheinlichkeit bedeuten, dass öffentlich zugänglich werden von all ihren Konten in anderen Systemen. Und das wird Ihre Schuld sein.
Verschlüsselung ist besser, hat aber ihre Schwächen. Das Problem der Verschlüsselung liegt in der Dekodierung; man kann diese verrückt aussehenden Codes nehmen und sie zurück in Klartext umwandeln, und wenn das passiert, kehren wir zur Situation mit lesbaren Passwörtern zurück. Wie passiert das? Ein kleiner Fehler schleicht sich in den Code ein, der für die Dekodierung des Passwortes zuständig ist, und macht es öffentlich zugänglich — das ist eine Möglichkeit. Hacker erhalten Zugang zum Rechner, auf dem die verschlüsselten Daten gespeichert sind — das ist die zweite Möglichkeit. Eine weitere Möglichkeit besteht darin, dass ein Backup der Datenbank gestohlen wird und jemand auch den Verschlüsselungsschlüssel erhält, der oft sehr unsicher aufbewahrt wird.
Und das bringt uns zum Thema Hashing. Die Idee des Hashings ist, dass es einseitig funktioniert; der einzige Weg, um das vom Benutzer eingegebene Passwort mit seiner gehashten Version zu vergleichen, besteht darin, das eingegebene Passwort zu hashen und die beiden zu vergleichen. Um Angriffe durch Tools wie "Regenbogen-Tabellen" zu verhindern, fügen wir durch Salzen Zufälligkeit in den Prozess ein (für einen vollständigen Überblick lesen Sie meinen über kryptografische Speicherung). Letztendlich können wir bei richtiger Implementierung mit großer Sicherheit sagen, dass gehashte Passwörter niemals wieder in Klartext umgewandelt werden (ich werde in einem anderen Beitrag über die Vorteile verschiedener Hashing-Algorithmen sprechen).
Ein kurzes Argument über Hashing und Verschlüsselung: Der einzige Grund, warum Sie irgendwann ein Passwort verschlüsseln und nicht hashen sollten, ist, wenn Sie das Passwort im Klartext sehen müssen, und das sollten Sie niemals wollen, zumindest nicht in der Situation einer Standard-Website. Wenn Sie das müssen, machen Sie wahrscheinlich etwas falsch!
Achtung!
Etwas weiter unten im Text befindet sich ein Teil eines Screenshots von der pornografischen Website AlotPorn. Es ist ordentlich zugeschnitten, und es gibt nichts, was man nicht am Strand sehen könnte, aber wenn das trotzdem Probleme verursachen könnte, scrollen Sie bitte nicht nach unten.
Setzen Sie das Passwort immer zurück, nie erinnern Sie es nicht
Wurden Sie jemals gebeten, eine Funktion zu erstellen zur Erinnerung Passwort? Denken Sie einen Schritt zurück und überlegen Sie, was diese Anfrage wirklich bedeutet: Warum brauchen wir diese "Erinnerung"? Weil der Benutzer sein Passwort vergessen hat. Was wollen wir eigentlich erreichen? Ihm zu helfen, sich wieder anzumelden.
Ich verstehe, dass das Wort "Erinnerung" (häufig) im umgangssprachlichen Sinne verwendet wird, aber tatsächlich versuchen wir, dem Benutzer sicher zu helfen, wieder online zu sein.Da Sicherheit wichtig ist, gibt es zwei Gründe, warum eine Erinnerung (d.h. das Versenden des Passworts an den Benutzer) nicht in Ordnung ist:
- E-Mail ist ein unsicherer Kanal. Genau wie wir nichts Vertrauliches über HTTP versenden würden (wir würden HTTPS verwenden), sollten wir nichts über E-Mail versenden, weil die Transportebene unsicher ist. Tatsächlich ist es viel schlimmer, als Informationen über einen ungeschützten Transportprotokoll zu übermitteln, da E-Mails häufig auf Speichermedien gespeichert, Systemadministratoren zugänglich, weitergeleitet und verteilt sowie Malware ausgesetzt sind und so weiter. Unverschlüsselte E-Mails sind ein äußerst unsicherer Kanal.
- Sie sollten auf jeden Fall keinen Zugriff auf das Passwort haben. Lesen Sie den vorherigen Abschnitt über die Speicherung noch einmal durch – Sie sollten einen Passwort-Hash (mit gutem, widerstandsfähigen Salz) haben, das heißt, Sie sollten in keiner Weise in der Lage sein, das Passwort abzurufen und es per E-Mail zu senden.
Lassen Sie mich das Problem anhand von : Hier ist eine typische Anmeldeseite:
Offensichtlich ist das erste Problem, dass die Anmeldeseite nicht über HTTPS geladen wird, aber die Website bietet auch an, das Passwort zu senden ("Send Password"). Möglicherweise ist dies ein Beispiel für die umgangssprachliche Verwendung dieses Begriffs, also lassen Sie uns einen weiteren Schritt machen und sehen, was passiert:
Es sieht leider nicht viel besser aus; und die E-Mail bestätigt das Vorhandensein des Problems:
Das sagt uns zwei wichtige Aspekte von usoutdoor.com:
- Die Website hasht keine Passwörter. Bestenfalls werden sie verschlüsselt, aber es ist sehr wahrscheinlich, dass sie im Klartext gespeichert werden; Beweise dafür sehen wir nicht.
- Die Website sendet ein langfristiges Passwort (wir können es immer wieder verwenden) über einen unsicheren Kanal.
Nachdem wir das geklärt haben, müssen wir überprüfen, ob der Rücksetzprozess sicher durchgeführt wird. Zuerst müssen wir sicherstellen, ob der Anfragende das Recht hat, den Reset durchzuführen. Mit anderen Worten, wir benötigen zunächst eine Identitätsprüfung; schauen wir uns an, was geschieht, wenn die Identität ohne vorherige Überprüfung bestätigt wird, dass der Anfragende tatsächlich der Kontoinhaber ist.
Die Auflistung von Benutzernamen und ihr Einfluss auf die Anonymität
Dieses Problem lässt sich am besten visuell veranschaulichen. Problem:
Sehen Sie? Beachten Sie die Meldung „There is no user registered with this email address“ („Benutzer mit dieser E-Mail-Adresse ist nicht registriert“). Das Problem tritt offensichtlich auf, wenn eine solche Website bestätigt, die Existenz eines Benutzers, der mit dieser E-Mail-Adresse registriert ist. Bingo – Sie haben gerade die Pornofetisch Ihres Mannes/ Chefs/ Nachbarn entdeckt!
Natürlich ist Pornografie ein ziemlich kanonisches Beispiel für die Bedeutung der Privatsphäre, aber die Gefahr, eine Identität mit einer bestimmten Website zu verknüpfen, ist viel umfassender als die oben beschriebene potenziell peinliche Situation. Eine der Gefahren ist Social Engineering; wenn ein Angreifer in der Lage ist, eine Person mit einem Dienst zu verknüpfen, hat er Informationen, die er nutzen kann. Beispielsweise kann er sich an die Person wenden und sich als Vertreter der Website ausgeben und zusätzliche Informationen anfordern, um einen .
Solche Praktiken führen auch zur Gefahr des „Enumerierens von Benutzernamen“, bei dem die Existenz einer ganzen Sammlung von Benutzernamen oder E-Mail-Adressen auf einer Website durch einfache Gruppenanfragen und deren Antworten überprüft werden kann. Haben Sie eine Liste der E-Mail-Adressen aller Mitarbeiter und ein paar Minuten, um ein Skript zu schreiben? Dann sehen Sie das Problem!
Was ist also die Alternative? Tatsächlich ist sie ganz einfach und wunderbar umgesetzt bei :
Hier verrät Entropay absolut nichts über die Existenz einer E-Mail-Adresse in seinem System für jemanden, der nicht im Besitz dieser Adresse ist. Wenn Sie Besitzer sind Diese Adresse existiert nicht im System, und Sie erhalten eine ähnliche E-Mail:
Natürlich gibt es akzeptable Situationen, in denen jemand denkt, dass er sich auf der Website registriert hat. Das ist jedoch nicht der Fall, oder er hat es von einer anderen E-Mail-Adresse gemacht. Das obige Beispiel behandelt beide Situationen erfolgreich. Wenn die Adresse übereinstimmt, erhalten Sie eine E-Mail, die das Zurücksetzen des Passworts vereinfacht.
Die Nuance der gewählten Entropay-Lösung besteht darin, dass die Identitätsprüfung über E-Mail vor jeglicher Online-Überprüfung erfolgt. Einige Websites fordern die Benutzer auf, die Antwort auf eine geheime Frage zu geben (zu diesem Thema weiter unten) bis wie der Reset beginnen kann; das Problem dabei ist jedoch, dass man auf die Frage antworten muss, während man eine Art Identifikation (E-Mail oder Benutzername) bereitstellt, wodurch es fast unmöglich wird, intuitiv zu antworten, ohne die Existenz eines anonymen Benutzerkontos offenzulegen.
Bei diesem Ansatz gibt es eine geringe Verminderung der Benutzerfreundlichkeit, da es bei dem Versuch, ein nicht existierendes Konto zurückzusetzen, kein sofortiges Feedback gibt. Natürlich ist das der ganze Sinn der E-Mail, aber aus der Sicht eines echten Endbenutzers erfährt er beim Eingeben einer falschen Adresse erst beim Erhalt der E-Mail davon. Dies kann zu einem gewissen Stress führen, ist aber ein geringer Preis für einen so seltenen Prozess.
Ein weiterer Hinweis, der etwas vom Thema abweicht: Funktionen zur Unterstützung des Logins, die die Richtigkeit des Benutzernamens oder der E-Mail-Adresse offenbaren, haben dasselbe Problem. Immer antworten Sie dem Benutzer mit der Meldung „Benutzername und Passwortkombination ungültig“ (Your username and password combination is invalid) und bestätigen Sie nicht explizit die Existenz von Identifikationsinformationen (z. B. „Benutzername ist korrekt, aber das Passwort ist falsch“).
Versand eines Rücksetzpassworts im Vergleich zu Versand eines Rücksetz-URLs
Das nächste Konzept, das wir besprechen müssen, betrifft die Art und Weise, wie das Passwort zurückgesetzt wird. Es gibt zwei beliebte Lösungen:
- Generierung eines neuen Passworts auf dem Server und Versand per E-Mail
- Versand einer E-Mail mit einer einzigartigen URL, die den Reset-Prozess vereinfacht
Trotzdem , den ersten Punkt sollte man niemals verwenden. Sein Problem ist, dass dies die Anwesenheit bedeutet des gespeicherten Passworts, auf das man jederzeit zurückgreifen und es wiederverwenden kann; es wurde über einen ungeschützten Kanal übermittelt und bleibt in Ihrem Posteingang. Es besteht die Möglichkeit, dass der Posteingang mit mobilen Geräten und dem E-Mail-Client synchronisiert wird, zudem kann er online für lange Zeit in einem E-Mail-Webdienst gespeichert werden. Der Punkt ist, dass ein Postfach nicht als zuverlässiges Mittel für die langfristige Speicherung angesehen werden kann.
Doch zusätzlich zu diesem Punkt gibt es ein weiteres ernsthaftes Problem — er erleichtert maximal die böswillige Sperrung eines Kontos. Wenn ich die E-Mail-Adresse desjenigen kenne, der das Konto auf der Website besitzt, kann ich es jederzeit sperren, indem ich einfach das Passwort zurücksetze; das ist eine Denial-of-Service-Attacke, die auf einem Silbertablett serviert wird! Deshalb sollte ein Rücksetzen nur nach erfolgreicher Überprüfung des Antragsrechts des Anfragenden durchgeführt werden.
Wenn wir von einem Reset-URL sprechen, meinen wir die Webseite, die einzigartig für diesen speziellen Fall des Rücksetzprozesses ist. Natürlich muss er zufällig sein, er darf nicht leicht entschlüsselbar sein und sollte keine externen Links zu dem Konto enthalten, die das Zurücksetzen erleichtern. Zum Beispiel sollte der Reset-URL nicht einfach wie "Reset/?username=JohnSmith" sein.
Wir möchten ein einzigartiges Token erstellen, das per E-Mail als Reset-URL gesendet werden kann, und es dann mit dem Eintrag auf dem Server abgleichen, um zu bestätigen, dass der Kontoinhaber tatsächlich die Person ist, die versucht, das Passwort zurückzusetzen. Zum Beispiel könnte das Token so aussehen: "3ce7854015cd38c862cb9e14a1ae552b" und zusammen mit der Nutzer-ID, die das Zurücksetzen durchführt, und dem Zeitpunkt der Token-Generierung in einer Tabelle gespeichert werden (mehr dazu weiter unten). Wenn die E-Mail gesendet wird, enthält sie eine URL wie "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", und wenn der Nutzer sie aufruft, überprüft die Seite das Vorhandensein des Tokens, bestätigt die Benutzerdaten und erlaubt es, das Passwort zu ändern.
Natürlich, da der oben beschriebene Prozess (hoffentlich) dem Benutzer erlaubt, ein neues Passwort zu erstellen, muss sichergestellt werden, dass die URL über HTTPS geladen wird. Nein, diese URL mit dem Token muss die Sicherheit der Transportschicht verwenden, damit das Eingabeformular für das neue Passwort nicht attackiert werden kann, und das vom Benutzer erstellte Passwort über eine sichere Verbindung übertragen wird.
Außerdem sollte für die Zurücksetz-URL ein Zeitlimit für das Token hinzugefügt werden, damit der Zurücksetzprozess innerhalb eines bestimmten Zeitrahmens, sagen wir, innerhalb einer Stunde, abgeschlossen werden kann. Dies gewährleistet, dass das Zeitfenster für den Rücksetzvorgang minimal ist, sodass der Empfänger dieser Zurücksetz-URL nur innerhalb dieses sehr kleinen Zeitfensters handeln kann. Natürlich kann ein Angreifer den Zurücksetzprozess erneut starten, aber er wird eine weitere einzigartige Zurücksetz-URL benötigen.
Schließlich müssen wir die Einmaligkeit dieses Prozesses sicherstellen. Nach Abschluss des Zurücksetzprozesses muss das Token gelöscht werden, damit die Zurücksetz-URL nicht mehr aktiv ist. Der vorherige Punkt sorgt dafür, dass der Angreifer ein sehr kurzes Zeitfenster hat, in dem er die Zurücksetz-URL manipulieren kann. Außerdem, natürlich, nach erfolgreichem Abschluss des Zurücksetzens ist das Token nicht mehr notwendig.
Einige dieser Schritte mögen überflüssig erscheinen, aber sie beeinträchtigen die Benutzerfreundlichkeit nicht und wirklich erhöhen die Sicherheit, auch wenn in Situationen, die wir hoffen, selten sein werden. In 99 % der Fälle wird der Benutzer den Rücksetzwitz innerhalb eines sehr kurzen Zeitraums in Anspruch nehmen und das Passwort nicht sofort erneut zurücksetzen.
Die Rolle der CAPTCHA
Oh, CAPTCHA, das Schutzmittel, das wir alle so sehr lieben zu hassen! Tatsächlich dient CAPTCHA weniger dem Schutz als vielmehr der Identifizierung - sind Sie ein Mensch oder ein Roboter (oder ein automatisiertes Skript). Ihr Zweck ist es, das automatische Absenden von Formularen zu verhindern, was, wie Sie sich vorstellen können, plötzliche Fehler verarbeiten und nützliche Details zur Fehlersuche anzeigen, wie z. B. einen Stack-Trace. Die Fehlermeldung wurde vereinfacht – es reicht aus, auf den Link zu klicken. als Versuch dient, Sicherheitsmechanismen zu umgehen. Im Kontext des Zurücksetzens von Passwörtern bedeutet CAPTCHA, dass die Rücksetzerfunktion nicht durch Brute-Force-Angriffe gehackt werden kann, um entweder den Benutzer mit Spam zu bombardieren oder zu versuchen, die Existenz von Konten festzustellen (was natürlich unmöglich ist, wenn Sie die Ratschläge aus dem Abschnitt zur Identitätsprüfung befolgt haben).
Natürlich ist CAPTCHA für sich genommen nicht perfekt; es gibt viele Fälle von programmatischem "Hack" und das Erreichen ausreichender Erfolgsraten (60-70%). Außerdem gibt es eine Lösung, die in meinem Beitrag über , bei der man Menschen Bruchteile eines Cents bezahlen kann, um jede CAPTCHA zu lösen und eine Erfolgsrate von 94% zu erzielen. Das heißt, sie ist anfällig, erhöht jedoch (geringfügig) die Eintrittsbarriere.
Lassen Sie uns ein Beispiel von PayPal betrachten:
In diesem Fall kann der Rücksetzprozess einfach nicht beginnen, ohne dass die CAPTCHA gelöst wird, daher theoretisch ist es unmöglich, den Prozess zu automatisieren. Theoretisch.
Für die meisten Webanwendungen wäre dies jedoch übertrieben und stellt auf jeden Fall eine Minderung der Benutzerfreundlichkeit dar — die Menschen mögen CAPTCHA einfach nicht! Außerdem ist CAPTCHA eine solche Sache, zu der man bei Bedarf leicht zurückkehren kann. Wenn der Dienst unter Angriff gerät (hier ist das Logging nützlich, aber dazu später mehr), kann man CAPTCHA leichter hinzufügen als irgendwo anders.
Geheime Fragen und Antworten
Bei allen von uns betrachteten Methoden hatten wir die Möglichkeit, das Passwort zurückzusetzen, nur indem wir Zugriff auf das E-Mail-Konto hatten. Ich sage "nur", aber natürlich sollte der unrechtmäßige Zugriff auf ein fremdes E-Mail-Konto ein schwieriger Prozess sein. Doch .
Tatsächlich dient der obige Link über den Hack des Kontos von Sarah Palin bei Yahoo! zwei Zwecken; erstens zeigt er, wie einfach es ist, (einige) E-Mail-Konten zu hacken, und zweitens zeigt er, wie böswillig schlecht gewählte geheime Fragen verwendet werden können. Aber dazu später mehr.
Das Problem mit Passwortzurücksetzungen, die vollständig von E-Mail abhängen, besteht darin, dass die Integrität des Kontos auf der Website, dessen Passwort Sie zurücksetzen möchten, vollständig von der Integrität des E-Mail-Kontos abhängt. Jeder, der Zugang zu Ihrer E-Mail hat, hat Zugang zu jedem Konto, das durch einfaches Erhalten einer E-Mail zurückgesetzt werden kann. Für solche Konten ist E-Mail der "Schlüssel zu allen Türen" Ihres Lebens online.
Eine Möglichkeit, dieses Risiko zu verringern, besteht darin, das Muster einer geheimen Frage und Antwort zu implementieren. Zweifellos haben Sie sie bereits gesehen: Sie wählen eine Frage aus, deren Antwort nur Sie wissen müssen, nach der Ihnen beim Zurücksetzen des Passworts diese gestellt wird. Das erhöht das Vertrauen, dass die Person, die versucht, das Passwort zurückzusetzen, tatsächlich der Kontoinhaber ist.
Kehren wir zu Sarah Palin zurück: Der Fehler bestand darin, dass die Antworten auf ihre geheimen Fragen leicht zu finden waren. Insbesondere, wenn man eine so bedeutende öffentliche Person ist, sind Informationen über den Mädchennamen der Mutter, die Ausbildung oder wo jemand in der Vergangenheit gelebt hat, nicht besonders geheim. Tatsächlich kann ein großer Teil von ihnen praktisch von jedem gefunden werden. So geschah es auch bei Sarah:
Der Hacker David Kernell erhielt Zugang zu Palins Konto, indem er Details aus ihrer Biografie fand, wie ihren Hochschulnamen und ihr Geburtsdatum, und dann die Funktion zum Zurücksetzen vergessener Passwörter für Yahoo!-Konten nutzte.
In erster Linie ist es ein Entwurfsfehler seitens Yahoo! — durch das Festlegen so einfacher Fragen hat das Unternehmen im Wesentlichen den Wert der geheimen Frage und damit auch den Schutz seines Systems sabotiert. Natürlich ist das Zurücksetzen von Passwörtern für E-Mail-Konten immer schwieriger, da Sie deren Besitz nicht bestätigen können, indem Sie dem Eigentümer eine E-Mail senden (ohne eine zweite Adresse), aber glücklicherweise gibt es heute nicht so viele Möglichkeiten für ein solches System.
Kehren wir zu den geheimen Fragen zurück — es gibt die Option, dem Benutzer die Erstellung eigener Fragen zu ermöglichen. Das Problem dabei ist, dass am Ende furchtbar offensichtliche Fragen entstehen:
Welche Farbe hat der Himmel?
Fragen, die Menschen in eine unangenehme Lage bringen, wenn zur Identifizierung die geheime Frage verwendet wird von einer Person (zum Beispiel im Callcenter):
Mit wem habe ich an Weihnachten geschlafen?
Oder offen gesagt dumme Fragen:
Wie schreibt man „Passwort“?
Wenn es um geheime Fragen geht, müssen die Benutzer vor sich selbst gerettet werden! Mit anderen Worten, die geheime Frage sollte von der Website selbst festgelegt werden, und noch besser, sie sollte eine Reihe geheimer Fragen stellen, aus denen der Benutzer wählen kann. Und nicht einfach auswählen eine; idealerweise sollte der Benutzer zwei oder mehr geheime Fragen zum Zeitpunkt der Kontoerstellung auswählen., die dann als zweiter Identifikationskanal verwendet werden. Das Vorhandensein mehrerer Fragen erhöht die Vertraulichkeit im Überprüfungsprozess und ermöglicht auch eine zufällige Auswahl (nicht immer dieselbe Frage), zusätzlich bietet es etwas Redundanz für den Fall, dass der tatsächliche Benutzer sein Passwort vergessen hat.
Wie sollte eine gute geheime Frage beschaffen sein? Dies hängt von mehreren Faktoren ab:
- Sie sollte kurz sein – die Frage sollte klar und eindeutig sein.
- Die Antwort sollte konkret sein – wir wollen keine Frage, die von einer Person unterschiedlich beantwortet werden kann.
- Mögliche Antworten sollten vielfältig sein – eine Frage nach der Lieblingsfarbe einer Person gibt nur eine sehr kleine Auswahl möglicher Antworten.
- Die Suche nach der Antwort sollte schwierig sein – wenn die Antwort leicht zu finden ist, kann diese jeder finden (denken wir an hochgestellte Personen), dann ist sie schlecht.
- Die Antwort sollte konstant über die Zeit – wenn man nach dem Lieblingsfilm fragt, könnte die Antwort nach einem Jahr eine andere sein.
Wie es der Zufall will, gibt es eine Website, die sich guten Fragen widmet und die heißt . Ein Teil der Fragen scheint ganz gut zu sein, andere bestehen nicht den oben beschriebenen Test, insbesondere die Überprüfung der "Suchtschwere".
Lassen Sie mich demonstrieren, wie geheime Fragen bei PayPal implementiert sind und insbesondere, welche Maßnahmen die Website ergreift, um die Identifikation zu gewährleisten. Vorher haben wir die Seite zu Beginn des Prozesses gesehen (mit CAPTCHA), und hier zeigen wir, was passiert, nachdem Sie Ihre E-Mail-Adresse eingegeben und das CAPTCHA gelöst haben:
In der Folge erhält der Benutzer eine solche E-Mail:
Bislang ist alles ganz normal, aber was hinter diesem Zurücksetzen-URL steckt:
Also, jetzt kommen die geheimen Fragen ins Spiel. Tatsächlich erlaubt PayPal auch, das Passwort zurückzusetzen, indem man die Kreditkartennummer bestätigt, was einen zusätzlichen Kanal schafft, zu dem viele Websites keinen Zugang haben. Ich kann mein Passwort einfach nicht ändern, ohne die beiden geheimen Fragen zu beantworten (oder ohne die Kartennummer zu kennen). Selbst wenn jemand meine E-Mail erlangt, kann er das Passwort meines PayPal-Kontos nicht zurücksetzen, wenn er nicht etwas mehr persönliche Informationen über mich weiß. Welche Informationen? Hier sind die Optionen für geheime Fragen, die PayPal anbietet:
Die Frage nach Schule und Krankenhaus mag in Bezug auf die einfache Suche etwas zweifelhaft sein, aber die anderen sind nicht so schlecht. Um die Sicherheit zu erhöhen, verlangt PayPal jedoch zusätzliche Identifizierung für Änderungen Antworten auf geheime Fragen:
PayPal ist ein ziemlich utopisches Beispiel für den sicheren Passwortreset: Es implementiert CAPTCHA zur Reduzierung der Gefahr von Brute-Force-Angriffen, verlangt zwei geheime Fragen und dann eine andere Art der Identifizierung, nur um die Antworten zu ändern – und das, nachdem der Benutzer bereits eingeloggt ist. Natürlich haben wir genau das erwartet von PayPal; es handelt sich um eine Finanzorganisation, die mit großen Geldbeträgen arbeitet. Das bedeutet nicht, dass jeder Passwortreset diesen Schritten folgen muss – in den meisten Fällen ist das übertrieben – jedoch ist es ein gutes Beispiel für Situationen, in denen Sicherheit ein ernstes Geschäft ist.
Der Vorteil des Systems geheimer Fragen besteht darin, dass, wenn Sie es nicht sofort implementiert haben, es später hinzugefügt werden kann, wenn der Schutzlevel des Ressourcen dies erfordert. Ein gutes Beispiel dafür ist Apple, das dieses Mechanismus erst kürzlich eingeführt hat [Artikel wurde 2012 verfasst]. Als ich einmal begann, eine Anwendung auf dem iPad zu aktualisieren, sah ich die folgende Anfrage:
Dann sah ich einen Bildschirm, auf dem man mehrere Paare von geheimen Fragen und Antworten sowie eine Rettungs-E-Mail-Adresse auswählen konnte:
Was PayPal betrifft, so sind die Fragen im Voraus ausgewählt und einige davon sind tatsächlich ziemlich gut:
Jedes der drei Paare von Fragen und Antworten stellt eine eigene Menge möglicher Fragen dar, sodass es genügend Möglichkeiten zur Konfiguration des Kontos gibt.
Ein weiterer Aspekt, den man bezüglich der Antwort auf die geheime Frage in Betracht ziehen sollte, ist die Speicherung. Das Speichern in einer DB im Klartext birgt fast die gleichen Risiken wie bei einem Passwort: Ein Datenbankleck offenbart sofort den Wert und gefährdet nicht nur die Anwendung, sondern potenziell auch ganz andere Anwendungen, die dieselben geheimen Fragen verwenden (das ist wieder ). Eine Möglichkeit ist sicheres Hashing (resistenter Algorithmus und kryptografisch zufälliges Salt). Im Gegensatz zu den meisten Fällen der Passwortspeicherung kann hier jedoch ein berechtigter Grund bestehen, die Antwort als einfachen Text sichtbar zu machen. Ein typisches Szenario ist die Identitätsprüfung durch einen Live-Operator am Telefon. Natürlich ist in diesem Fall auch Hashing anwendbar (der Operator kann einfach die vom Kunden genannte Antwort eingeben), aber im schlimmsten Fall sollte die geheime Antwort auf irgendeiner Ebene eines kryptografischen Speichers landen, selbst wenn es sich nur um symmetrische Verschlüsselung handelt. Zusammenfassend: Behandeln Sie Geheimnisse wie Geheimnisse!
Ein letzter Aspekt von geheimen Fragen und Antworten ist, dass sie anfälliger für Social Engineering sind. Es ist eine Sache, direkt nach dem Passwort eines fremden Kontos zu fragen, und eine ganz andere, ein Gespräch über dessen Ausbildung zu beginnen (eine beliebte geheime Frage). In der Tat können Sie leicht mit jemandem über viele Aspekte seines Lebens sprechen, die einen geheimen Frage darstellen können, und dabei keinen Verdacht erregen. Natürlich ist der Kern der geheimen Frage, dass sie mit den Lebenserfahrungen einer Person verbunden ist, weshalb sie einprägsam ist, und genau hier liegt das Problem – Menschen reden gern über ihre Lebenserfahrungen! Darüber lässt sich nicht viel ändern, außer die Optionen für geheime Fragen so zu wählen, dass sie weniger wahrscheinlich durch Social Engineering herausgezogen werden können.
[Fortsetzung folgt.]
Als Werbung
VDSina bietet zuverlässige , jeder Server ist mit einem Internetkanal von 500 Megabit verbunden und kostenlos gegen DDoS-Angriffe geschützt!
Quelle: habr.com
