{"id":97639,"date":"2020-10-20T02:42:56","date_gmt":"2020-10-20T00:42:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2"},"modified":"2020-10-20T02:42:56","modified_gmt":"2020-10-20T00:42:56","slug":"vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Alles, was Sie \u00fcber sicheres Zur\u00fccksetzen von Passw\u00f6rtern wissen wollten. Teil 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zwei-Faktor-Authentifizierung<\/h2>\n

\nAlles, was Sie gelesen haben, bezieht sich auf ersten Teils<\/a><\/noindex> die Identifikation basierend auf dem, was der anfragende Benutzer wei\u00df.<\/em><\/strong>Er kennt seine E-Mail-Adresse, wei\u00df, wie er darauf zugreifen kann (d.h. er kennt sein E-Mail-Passwort) und kennt die Antworten auf geheime Fragen. <\/p>\n

\u201eWissen\u201c gilt als ein Authentifizierungsfaktor; zwei weitere g\u00e4ngige Faktoren sind das, was Sie haben<\/em><\/strong>, wie ein physisches Ger\u00e4t, und das, wer Sie sind<\/em><\/strong>, wie Fingerabdr\u00fccke oder die Netzhaut des Auges.<\/p>\n

\"Alles,
\n<\/a><\/noindex>
\nIn den meisten F\u00e4llen ist die biometische Identifizierung schwer umsetzbar, insbesondere wenn wir \u00fcber die Sicherheit von Webanwendungen sprechen, weshalb bei der Zwei-Faktor-Authentifizierung (Two Factor Authentication, 2FA) in der Regel das zweite Attribut \u2013 \u201edas, was Sie haben\u201c \u2013 verwendet wird. Eine beliebte Variante dieses zweiten Faktors ist ein physisches Token, wie RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Alles,
\nPhysische Tokens werden h\u00e4ufig zur Authentifizierung in Unternehmens-VPNs und Finanzdienstleistungen eingesetzt. Zur Authentifizierung in einem Dienst m\u00fcssen sowohl das Passwort als auch der Code auf dem Token (der oft ge\u00e4ndert wird) in Kombination mit einer PIN verwendet werden. Theoretisch muss ein Angreifer sowohl das Passwort kennen als auch ein Token besitzen sowie die PIN des Tokens wissen. Im Szenario des Zur\u00fccksetzens des Passworts ist das Passwort offensichtlich unbekannt, aber der Besitz des Tokens kann verwendet werden, um den Besitz des Kontos zu best\u00e4tigen. Nat\u00fcrlich, wie bei jeder Schutzma\u00dfnahme, bietet dies keinen \"Schutz vor Dummheit\"<\/a><\/noindex>, erh\u00f6ht aber definitiv die Eintrittsbarriere.<\/p>\n

Eine der Hauptprobleme dieses Ansatzes ist die Kosten und Logistik der Umsetzung; wir sprechen von der Bereitstellung physischer Ger\u00e4te f\u00fcr jeden Kunden und deren Schulung in den neuen Prozess. Au\u00dferdem m\u00fcssen die Benutzer das Ger\u00e4t bei sich haben, was bei physischen Tokens nicht immer der Fall ist. Eine weitere M\u00f6glichkeit besteht darin, den zweiten Authentifizierungsfaktor \u00fcber SMS zu realisieren, der im Falle von 2FA als Best\u00e4tigung dienen kann, dass die Person, die den Zur\u00fccksetzungsprozess durchf\u00fchrt, das Mobiltelefon des Kontoinhabers hat. So macht es Google:<\/p>\n

\"Alles,
\nEs ist auch notwendig, die Zwei-Schritt-Verifizierung zu aktivieren.<\/a><\/noindex>, aber das bedeutet, dass Ihr Mobiltelefon beim n\u00e4chsten Zur\u00fccksetzen des Passworts m\u00f6glicherweise ein zweiter Authentifizierungsfaktor werden kann. Lassen Sie mich dies anhand meines iPhones demonstrieren, aus Gr\u00fcnden, die bald klar werden werden:<\/p>\n

\"Alles,
\nNachdem die E-Mail-Adresse des Google-Kontos identifiziert wurde, stellt es fest, dass 2FA aktiviert ist, und wir k\u00f6nnen das Konto mithilfe einer \u00dcberpr\u00fcfung zur\u00fccksetzen, die per SMS an das Mobiltelefon des Kontoinhabers gesendet wird:<\/p>\n

\"Alles,
\nJetzt m\u00fcssen wir den Beginn des Zur\u00fccksetzvorgangs ausw\u00e4hlen:<\/p>\n

\"Alles,
\nDiese Aktion f\u00fchrt zur Versendung einer E-Mail an die registrierte Adresse:<\/p>\n

\"Alles,
\nDiese E-Mail enth\u00e4lt die Zur\u00fccksetz-URL:<\/p>\n

\"Alles,
\nBei Zugriff auf die Zur\u00fccksetz-URL wird eine SMS gesendet, und die Website fordert zur Eingabe auf:<\/p>\n

\"Alles,
\nHier ist die SMS:<\/p>\n

\"Alles,
\nNach der Eingabe im Browser kehren wir zum klassischen Passwort-Zur\u00fccksetzen zur\u00fcck:<\/p>\n

\"Alles,
\nDas mag etwas wortreich erscheinen, und das ist es auch, aber das Formular best\u00e4tigt, dass die Person, die das Zur\u00fccksetzen vornimmt, Zugang zur E-Mail-Adresse und zum Mobiltelefon des Kontoinhabers hat. Aber es kann neunmal sicherer sein als das Zur\u00fccksetzen des Passworts nur per E-Mail. Allerdings gibt es Probleme\u2026<\/p>\n

Das Problem liegt bei Smartphones. Das unten gezeigte Ger\u00e4t kann nur einen Authentifizierungsfaktor best\u00e4tigen \u2014 es ist in der Lage, SMS zu empfangen, aber keine E-Mails:<\/p>\n

\"Alles,
\nDieses Ger\u00e4t kann jedoch SMS empfangen und<\/em> Erh\u00e4lt E-Mails zum Zur\u00fccksetzen des Passworts:<\/p>\n

\"Alles,
\nDas Problem ist, dass wir die E-Mail als ersten Authentifizierungsfaktor und die SMS (oder eine App, die Tokens generiert) als zweiten betrachten, aber heute sind sie in einem Ger\u00e4t kombiniert. Das bedeutet selbstverst\u00e4ndlich, dass, wenn jemand Zugang zu Ihrem Smartphone erh\u00e4lt, all dieser Komfort darauf hinausl\u00e4uft, dass wir wieder bei einem Kanal sind; dieser zweite Faktor \u201edas, was Sie haben\u201c bedeutet, dass Sie auch den ersten Faktor haben. Und all dies ist durch eine PIN aus vier Ziffern gesch\u00fctzt\u2026 wenn das Telefon \u00fcberhaupt eine PIN hat und<\/em> es war gesperrt.<\/p>\n

Ja, die von Google implementierte 2FA-Funktion bietet eindeutig zus\u00e4tzlichen Schutz, aber sie ist nicht \u201edummensicher\u201c und h\u00e4ngt definitiv nicht von zwei vollkommen separaten Kan\u00e4len ab.<\/p>\n

Zur\u00fccksetzen per Benutzername gegen Zur\u00fccksetzen per E-Mail<\/h2>\n

\nSollte der Password-Reset nur per E-Mail erlaubt sein? Oder sollte der Benutzer auch die M\u00f6glichkeit haben, den Reset \u00fcber den Benutzernamen durchzuf\u00fchren? Das Problem beim Reset \u00fcber den Benutzernamen besteht darin, dass es keine M\u00f6glichkeit gibt, den Benutzer \u00fcber einen falschen Benutzernamen zu informieren, ohne<\/em> offenzulegen, dass jemand anderes ein Konto mit diesem Namen haben k\u00f6nnte. Im vorherigen Abschnitt stellte der R\u00fccksetzprozess per E-Mail sicher, dass der rechtm\u00e4\u00dfige Eigent\u00fcmer dieser E-Mail stets R\u00fcckmeldung erh\u00e4lt, ohne dass sein Bestehen im System \u00f6ffentlich gemacht wird. Nur mit dem Benutzernamen ist dies nicht m\u00f6glich.<\/p>\n

Daher lautet die Antwort kurz: nur E-Mail. Wenn Sie versuchen, nur mit dem Benutzernamen zur\u00fcckzusetzen, wird es F\u00e4lle geben, in denen der Benutzer ratlos ist, was passiert ist, oder<\/em> Sie w\u00fcrden die Existenz von Konten offenbaren. Ja, es handelt sich nur um einen Benutzernamen und nicht um eine E-Mail-Adresse, und ja, jeder kann sich jeden (verf\u00fcgbaren) Benutzernamen ausw\u00e4hlen, aber es besteht trotzdem eine hohe Wahrscheinlichkeit, dass Sie indirekt die Kontoinhaber aufgrund der Neigung der Benutzer zur Wiederverwendung von Namen offenbaren.<\/p>\n

Was geschieht also, wenn jemand seinen Benutzernamen vergisst? Setzt man voraus, dass der Benutzername nicht gleichzeitig eine E-Mail-Adresse ist (was h\u00e4ufig der Fall ist), \u00e4hnelt der Prozess dem, wie ein Passwort-Reset beginnt \u2014 wir geben die E-Mail-Adresse ein und senden dann eine Nachricht an diese Adresse, ohne deren Existenz offenzulegen. Der einzige Unterschied besteht darin, dass die Nachricht diesmal nur den Benutzernamen enth\u00e4lt und nicht die URL f\u00fcr den Passwort-Reset. Oder die E-Mail k\u00f6nnte auch einfach sagen, dass es kein Konto f\u00fcr diese Adresse gibt.<\/p>\n

Identit\u00e4tspr\u00fcfung und Genauigkeit von E-Mail-Adressen<\/h2>\n

\nEin Schl\u00fcsselbereich beim Zur\u00fccksetzen von Passw\u00f6rtern und wahrscheinlich auch der wichtigste<\/em> Aspekt ist die Identit\u00e4tspr\u00fcfung der Person, die versucht, den Reset durchzuf\u00fchren. Ist es wirklich der rechtm\u00e4\u00dfige Eigent\u00fcmer des Kontos, oder versucht jemand, es zu hacken oder dem Eigent\u00fcmer Unannehmlichkeiten zu bereiten?<\/p>\n

Es ist offensichtlich, dass E-Mail der bequemste und am weitesten verbreitete Kanal zur Identit\u00e4tspr\u00fcfung ist. Sie ist nicht vor unsachgem\u00e4\u00dfer Handhabung (\u201evon Dummk\u00f6pfen\u201c) gesch\u00fctzt, und es gibt zahlreiche F\u00e4lle, in denen die einfache M\u00f6glichkeit, E-Mails an die Adresse des Kontoinhabers zu empfangen, nicht ausreicht, wenn eine hohe Vertrauensw\u00fcrdigkeit bei der Identifizierung erforderlich ist (deshalb wird 2FA verwendet). Dennoch ist sie fast immer der Ausgangspunkt des Zur\u00fccksetzprozesses.<\/p>\n

Wenn E-Mail eine Rolle bei der Sicherstellung von Vertrauen spielt, muss zun\u00e4chst sichergestellt werden, dass die E-Mail-Adresse tats\u00e4chlich korrekt ist. Wenn jemand ein Zeichen falsch eingegeben hat, wird der Reset offensichtlich nicht beginnen. Der Verifizierungsprozess der E-Mail-Adresse w\u00e4hrend der Registrierung ist ein zuverl\u00e4ssiger Weg, um die Richtigkeit der Adresse zu \u00fcberpr\u00fcfen. Wir haben das alle schon erlebt: Sie registrieren sich, erhalten eine E-Mail mit einem einzigartigen URL, auf den Sie klicken m\u00fcssen, was best\u00e4tigt, dass Sie in der Tat der Besitzer dieser E-Mail-Adresse sind. Die Unf\u00e4higkeit, sich anzumelden, bis dieser Prozess abgeschlossen ist, garantiert, dass es einen Anreiz gibt, die Adresse zu best\u00e4tigen.<\/p>\n

Wie bei vielen anderen Sicherheitsaspekten verringert dieses Modell die Benutzerfreundlichkeit zugunsten einer erh\u00f6hten Sicherheit hinsichtlich des Vertrauens in die Identit\u00e4t des Benutzers. Das kann f\u00fcr eine Webseite akzeptabel sein, deren Registrierung der Benutzer hoch sch\u00e4tzt und gerne eine weitere Stufe im Prozess hinzuf\u00fcgen m\u00f6chte (bezahlte Dienste, Banking usw.), aber solche Dinge k\u00f6nnen den Benutzer abschrecken, wenn er das Konto als \u201eeinmalig\u201c ansieht und es beispielsweise einfach als Mittel verwendet, um einen Beitrag zu kommentieren.<\/p>\n

Identifizierung dessen, der den R\u00fccksetzprozess initiiert hat<\/h2>\n

\nEs ist offensichtlich, dass es Gr\u00fcnde f\u00fcr den missbr\u00e4uchlichen Gebrauch der R\u00fccksetzfunktion gibt, und Angreifer k\u00f6nnen sie auf viele verschiedene Arten nutzen. Ein einfacher Trick, den wir zur Best\u00e4tigung der Quelle der Anfrage verwenden k\u00f6nnen (dieser Trick funktioniert normalerweise<\/em> und wird) \u2014 besteht darin, die IP-Adresse des Anfragenden in die E-Mail, in der ein R\u00fccksetzen vorgeschlagen wird, einzuf\u00fcgen. Dies versorgt den Empf\u00e4nger mit einigen<\/em> Informationen zur Identifizierung der Anfragequelle.<\/p>\n

Hier ist ein Beispiel aus der R\u00fccksetzfunktion, die ich derzeit in ASafaWeb integriere:<\/p>\n

\"Alles,
\nDer Link \"find out more\" (\"Mehr erfahren\") leitet den Benutzer zur Website ip-adress.com<\/a><\/noindex>, die Informationen wie den Standort und die Organisation des anfragenden Benutzers bereitstellt:<\/p>\n

\"Alles,
\nNat\u00fcrlich haben alle, die ihre Identit\u00e4t verbergen m\u00f6chten, zahlreiche M\u00f6glichkeiten, ihre echte IP-Adresse zu verschleiern, doch dies ist eine bequeme Methode, um eine teilweise Identifizierung des Anfragenden hinzuzuf\u00fcgen, und in den meisten<\/em> vielen F\u00e4llen gibt Ihnen dies ausreichend Einblick, wer die Anfrage zum Zur\u00fccksetzen des Passworts stellt.<\/p>\n

Benachrichtigung \u00fcber \u00c4nderungen per E-Mail<\/h2>\n

\nDieser Beitrag ist von einem Thema durchdrungen \u2013 Kommunikation; informieren Sie den Kontoinhaber so gut wie m\u00f6glich \u00fcber das, was in jedem Schritt des Prozesses geschieht, ohne etwas zu enth\u00fcllen, das b\u00f6swillig verwendet werden k\u00f6nnte. Das Gleiche gilt f\u00fcr die Situation, in der das Passwort tats\u00e4chlich ge\u00e4ndert wurde \u2013 informieren Sie den Inhaber dar\u00fcber!<\/em><\/strong><\/p>\n

Die Gr\u00fcnde f\u00fcr eine Passwort\u00e4nderung k\u00f6nnen aus zwei Quellen stammen:<\/p>\n

    \n
  1. \u00c4nderung des Passworts nach dem Einloggen, weil der Benutzer ein neues Passwort m\u00f6chte<\/li>\n
  2. Zur\u00fccksetzen des Passworts ohne Einloggen, weil der Benutzer es vergessen hat<\/li>\n<\/ol>\n

    \nObwohl dieser Beitrag haupts\u00e4chlich dem Zur\u00fccksetzen gewidmet ist, verringert die Benachrichtigung im ersten Fall das Risiko, dass jemand das Passwort ohne Wissen des rechtm\u00e4\u00dfigen Besitzers \u00e4ndert. Wie kann das passieren? Ein verbreitetes Szenario ist, dass das Passwort des rechtm\u00e4\u00dfigen Besitzers (ein wiederverwendetes Passwort, das aus einer anderen Quelle geleakt wurde; ein Passwort, das durch Keylogging erhalten wurde; ein leicht zu erratendes Passwort usw.) erlangt wird, wonach der Angreifer beschlie\u00dft, es zu \u00e4ndern, wodurch er den Besitzer blockiert. Ohne eine Benachrichtigung per E-Mail w\u00fcrde der echte Besitzer nichts von der Passwort\u00e4nderung erfahren.<\/p>\n

    Nat\u00fcrlich sollte der Besitzer im Falle eines Passwort-Resets den Prozess bereits selbst eingeleitet haben (oder die oben beschriebenen Identit\u00e4ts\u00fcberpr\u00fcfungsmechanismen umgangen haben), daher sollte die \u00c4nderung keine<\/em> \u00dcberraschung f\u00fcr ihn sein, doch eine Best\u00e4tigung per E-Mail w\u00e4re ein positives Feedback und eine zus\u00e4tzliche \u00dcberpr\u00fcfung. Au\u00dferdem sorgt es f\u00fcr Konsistenz mit dem oben beschriebenen Szenario.<\/p>\n

    Oh, und f\u00fcr den Fall, dass das noch nicht offensichtlich ist \u2013 versenden Sie das neue Passwort nicht per E-Mail!<\/em><\/strong> Das mag manche zum Lachen bringen, aber so etwas passiert<\/a><\/noindex>:<\/p>\n

    \"Alles,<\/p>\n

    Protokolle, Protokolle, Protokolle und noch ein bisschen Protokolle<\/h2>\n

    \nDie Passwortzur\u00fccksetzfunktion ist f\u00fcr Angreifer attraktiv: Entweder m\u00f6chte der Angreifer auf das Konto einer anderen Person zugreifen oder einfach dem Kontoinhaber\/System Unannehmlichkeiten bereiten. Viele der oben beschriebenen Praktiken verringern die Wahrscheinlichkeit von Missbrauch, verhindern ihn jedoch nicht, und sie werden auf jeden Fall nicht verhindern, dass Menschen versuchen, die Funktion auf unerwartete Weise zu verwenden.<\/p>\n

    Eine absolut wertvolle Praxis zur Erkennung sch\u00e4dlichen Verhaltens ist das Logging, und ich meine sehr detailliertes Logging<\/em><\/strong>. Protokollieren Sie gescheiterte Anmeldeversuche, Passwortzur\u00fccksetzungen, Passwort\u00e4nderungen (d.h. wenn der Benutzer bereits angemeldet ist) und praktisch alles, was Ihnen helfen kann, das Geschehen zu verstehen; dies wird in der Zukunft sehr hilfreich sein. Protokollieren Sie sogar einzelne Teile<\/em> des Prozesses, zum Beispiel sollte eine gute R\u00fccksetzfunktion die Initiierung des Zur\u00fccksetzens \u00fcber die Website umfassen (protokollieren Sie Anfragen und Anmeldeversuche zum Zur\u00fccksetzen mit falschem Benutzernamen oder E-Mail), protokollieren Sie den Zugriff auf die Website \u00fcber die Zur\u00fccksetz-URL (einschlie\u00dflich der Versuche, ein falsches Token zu verwenden), und halten Sie schlie\u00dflich den Erfolg oder Misserfolg der Antwort auf die geheime Frage fest.<\/p>\n

    Wenn ich von Logging spreche, meine ich nicht nur die Aufzeichnung des Seitenaufrufs, sondern das Sammeln so vieler Informationen wie m\u00f6glich, sofern sie nicht vertraulich sind<\/em><\/strong>. Leute, bitte protokollieren Sie keine Passw\u00f6rter!<\/em><\/strong> In den Protokollen sollte die Identit\u00e4t des autorisierten Benutzers erfasst werden (er wird autorisiert sein, wenn er sein<\/em> vorhandenes Passwort \u00e4ndert oder versucht, das Passwort eines anderen zur\u00fcckzusetzen<\/em> nachdem er sich angemeldet hat), alle ausprobierten Benutzernamen oder E-Mail-Adressen sowie alle R\u00fccksetz-Token, die er zu verwenden versucht. Es ist auch sinnvoll, in den Protokollen solche Aspekte wie IP-Adressen und, wenn m\u00f6glich, sogar die Header der Anfragen aufzuzeichnen. Das erm\u00f6glicht es Ihnen, nicht nur zu rekonstruieren, was<\/em> was der Benutzer (oder Angreifer) versuchen will, sondern auch wer<\/em> wer er ist.<\/p>\n

    Die Verantwortung an andere Dienstleister delegieren<\/h2>\n

    \nWenn Sie denken, dass das alles einen riesigen Arbeitsaufwand darstellt, dann sind Sie nicht allein. Tats\u00e4chlich ist der Aufbau eines zuverl\u00e4ssigen Systems zur Verwaltung von Konten keine einfache Aufgabe. Es liegt nicht daran, dass es technisch schwierig ist, es gibt einfach viele Besonderheiten. Es geht nicht nur um das Zur\u00fccksetzen, es gibt einen ganzen Registrierungsprozess, sichere Speicherung von Passw\u00f6rtern, die Verarbeitung mehrerer falscher Anmeldeversuche usw. usw. Obwohl ich die Idee der Nutzung vorhandener Funktionalit\u00e4t wie des ASP.NET Membership Providers vorantreibe<\/a><\/noindex>, muss dennoch viel mehr getan werden.<\/p>\n

    Heute gibt es zahlreiche Drittanbieter, die bereitwillig alle M\u00fchen \u00fcbernehmen und alles in einen verwalteten Dienst abstrahieren. Zu solchen Diensten geh\u00f6ren OpenID, OAuth und sogar Facebook. Einige Leute glauben bedingungslos an dieses Modell<\/a><\/noindex> (OpenID war tats\u00e4chlich sehr erfolgreich bei Stack Overflow), w\u00e4hrend andere es buchst\u00e4blich als Albtraum empfinden<\/a><\/noindex>.<\/p>\n

    Zweifellos l\u00f6st ein Dienst wie OpenID viele Probleme f\u00fcr Entwickler, doch es ist ebenso unbestreitbar, dass er neue hinzuf\u00fcgt. Haben sie eine Rolle? Ja, aber es ist offensichtlich, dass wir keine massenhafte Nutzung von Authentifizierungsdienstanbietern beobachten. Banken, Fluggesellschaften und sogar Gesch\u00e4fte \u2014 alle implementieren ihre eigenen Authentifizierungsmechanismen, und es ist offensichtlich, dass es daf\u00fcr triftige Gr\u00fcnde gibt.<\/p>\n

    B\u00f6swilliges Zur\u00fccksetzen<\/h2>\n

    \nEin wichtiger Aspekt jedes der oben genannten Beispiele ist, dass das alte Passwort nur dann als nutzlos angesehen wird nach der Best\u00e4tigung der Identit\u00e4t des Kontoinhabers<\/em><\/strong>. Das ist wichtig, denn wenn ein Konto ohne Identit\u00e4tspr\u00fcfung zur\u00fcckgesetzt werden k\u00f6nnte, w\u00fcrde das die M\u00f6glichkeit f\u00fcr allerlei b\u00f6swillige Handlungen bieten. bis<\/em> Hier ist ein Beispiel: Jemand nimmt an einer Auktion teil, und kurz vor Ende des Bietprozesses blockiert er die Wettbewerber, indem er den Zur\u00fccksetzungsprozess initiiert, und eliminiert sie so aus den Geboten. Offensichtlich kann eine schlecht gestaltete Zur\u00fccksetzungsfunktion, die missbraucht werden kann, zu ernsthaften negativen Ergebnissen f\u00fchren. Es ist erw\u00e4hnenswert, dass das Sperren von Konten durch falsche Anmeldeversuche eine \u00e4hnliche Situation darstellt, aber das ist bereits ein Thema f\u00fcr einen anderen Beitrag.<\/p>\n

    Hier ist ein Beispiel: Jemand nimmt an einer Auktion auf der Auktionswebsite teil und blockiert gegen Ende des Bietprozesses seine Konkurrenten, indem er den R\u00fccksetzprozess initiiert und sie so aus den Geboten entfernt. Es ist offensichtlich, dass eine schlecht gestaltete R\u00fccksetzfunktion missbraucht werden kann, was zu ernsthaften negativen Folgen f\u00fchren kann. Es ist zu beachten, dass Kontoaus \u0431\u043b\u043e\u043aierungen durch falsche Anmeldeversuche eine \u00e4hnliche Situation darstellen, aber das ist bereits ein Thema f\u00fcr einen anderen Beitrag.<\/p>\n

    Wie ich oben erw\u00e4hnt habe, wenn man anonymen Nutzern die M\u00f6glichkeit gibt, das Passwort eines beliebigen Kontos zur\u00fcckzusetzen, nur indem sie die E-Mail-Adresse kennen, ist das eine ideale Situation f\u00fcr einen \"Denial of Service\"-Angriff. Das mag nicht das sein, DoS<\/a><\/noindex>, wor\u00fcber wir normalerweise sprechen, aber es gibt keinen schnelleren Weg, den Zugang zu einem Konto zu blockieren, als mit einer schlecht durchdachten Passwortzur\u00fccksetzungsfunktion.<\/p>\n

    Das schw\u00e4chste Glied<\/h2>\n

    \nIn Bezug auf den Schutz eines einzelnen Kontos ist alles, was oben geschrieben wurde, gro\u00dfartig, jedoch muss man immer das \u00d6kosystem im Auge behalten, das das gesch\u00fctzte Konto umgibt. Lassen Sie mich ein Beispiel geben:<\/p>\n

    ASafaWeb wird von einem gro\u00dfartigen Dienst gehostet, der von AppHarbor bereitgestellt wird. Der Prozess des Passwortzur\u00fccksetzens f\u00fcr das Hosting-Konto verl\u00e4uft so:<\/p>\n

    Schritt 1:<\/strong><\/p>\n

    \"Alles,
    \nSchritt 2:<\/strong><\/p>\n

    \"Alles,
    \nSchritt 3:<\/strong><\/p>\n

    \"Alles,
    \nSchritt 4:<\/strong><\/p>\n

    \"Alles,
    \nNachdem ich alle vorhergehenden Informationen gelesen habe, wird schnell klar, welche Aspekte wir in einer idealen Welt etwas anders umsetzen w\u00fcrden. Dennoch m\u00f6chte ich sagen, dass selbst wenn ich eine Website wie ASafaWeb im AppHarbor-Dienst ver\u00f6ffentliche, danach gro\u00dfartige geheime Fragen und Antworten erfinde, eine zweite Authentifizierung hinzuf\u00fcge und alles andere nach den Regeln mache, das nicht die Tatsache au\u00dfer Kraft setzt, dass das schw\u00e4chste Glied des gesamten Prozesses in der Lage sein wird, alles zu brechen. Wenn jemand erfolgreich die Authentifizierung bei AppHarbor durchf\u00fchrt, indem er meine Informationen nutzt, kann er das Passwort jedes ASafaWeb-Kontos auf das von ihm gew\u00fcnschte \u00e4ndern!<\/p>\n

    Der Punkt ist, dass die Robustheit der Implementierung des Schutzes ganzheitlich betrachtet werden muss: Man muss die Bedrohungen an jedem Zugangspunkt des Systems modellieren, selbst wenn dies ein oberfl\u00e4chlicher Prozess ist, wie z. B. der Login in AppHarbor. Dies sollte mir ein gutes Gef\u00fchl daf\u00fcr geben, wie viel Aufwand ich in den Passwortzur\u00fccksetzungsprozess von ASafaWeb investieren muss.<\/p>\n

    Alles zusammenf\u00fcgen<\/h2>\n

    \nDieser Beitrag enth\u00e4lt eine gro\u00dfe Menge an Informationen, deshalb m\u00f6chte ich diese in einem einfachen visuellen Schema b\u00fcndeln:<\/p>\n

    \"Alles,
    \nDenken Sie daran, dass Sie die gr\u00f6\u00dftm\u00f6gliche Protokollierung jedes dieser Punkte durchf\u00fchren sollten. Das ist alles, es ist ganz einfach!<\/p>\n

    Ergebnisse<\/h2>\n

    \nMein Beitrag scheint umfassend zu sein, dennoch gibt es viele weitere Materialien, die ich k\u00f6nnte<\/em> Integrieren Sie es, aber ich beschloss, mich der K\u00fcrze halber davon zu distanzieren: die Rolle der Adresse f\u00fcr die Rettungs-E-Mail, die Situation, in der Sie den Zugriff auf die mit Ihrem Konto verbundene E-Mail verlieren (zum Beispiel, wenn Sie Ihren Job gek\u00fcndigt haben) und so weiter. Wie ich bereits sagte, ist die Funktion zum Zur\u00fccksetzen nicht so kompliziert, es gibt jedoch viele Sichtweisen darauf.<\/p>\n

    Obwohl das Zur\u00fccksetzen nicht so kompliziert ist, wird es oft falsch implementiert. Oben haben wir ein paar Beispiele gesehen, bei denen die Implementierung pl\u00f6tzliche Fehler verarbeiten und n\u00fctzliche Details zur Fehlersuche anzeigen, wie z. B. einen Stack-Trace. Die Fehlermeldung wurde vereinfacht \u2013 es reicht aus, auf den Link zu klicken.<\/em> zu Problemen f\u00fchren kann, und es gibt viele weitere Pr\u00e4zedenzf\u00e4lle, bei denen ein falsches Zur\u00fccksetzen tats\u00e4chlich<\/em> Probleme verursacht hat. K\u00fcrzlich stellte sich heraus, dass ein Passwort-Reset verwendet wurde, um Bitcoin im Wert von 87.000 Dollar zu stehlen.<\/a><\/noindex>Das ist ein ernsthaft negatives Ergebnis!<\/p>\n

    Seien Sie also vorsichtig mit Ihren R\u00fccksetzfunktionen, modellieren Sie Bedrohungen<\/a><\/noindex> an verschiedenen Punkten, und ziehen Sie beim Entwerfen der Funktion nicht Ihre schwarze M\u00fctze ab, denn die Wahrscheinlichkeit ist hoch, dass sie jemand anderes aufsetzt!<\/p>\n

    <\/p>\n

    Als Werbung<\/h4>\n

    \nVDSina<\/b> bietet kosteng\u00fcnstige Server zur Miete<\/a><\/noindex> t\u00e4gliche Zahlungen, jeder Server ist mit einem Internetanschluss von 500 Megabit verbunden und kostenlos gegen DDoS-Angriffe gesch\u00fctzt!<\/p>\n

    \"Alles,<\/a><\/noindex>
    \n
    Quelle:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u0437\u043d\u0430\u0435\u0442 \u0437\u0430\u043f\u0440\u0430\u0448\u0438\u0432\u0430\u044e\u0449\u0438\u0439. \u041e\u043d \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b, \u0437\u043d\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a \u043d\u0435\u0439 \u0434\u043e\u0441\u0442\u0443\u043f (\u0442.\u0435. \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u043f\u0430\u0440\u043e\u043b\u044c \u043e\u0442 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b) \u0438 \u0437\u043d\u0430\u0435\u0442 \u043e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u0441\u0435\u043a\u0440\u0435\u0442\u043d\u044b\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b. \u00ab\u0417\u043d\u0430\u043d\u0438\u0435\u00bb \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0438\u043c \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u043c \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438; \u0434\u0432\u0443\u043c\u044f \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0451\u043d\u043d\u044b\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u044f\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u0442\u043e, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97639","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Alles, was Sie \u00fcber sicheres Zur\u00fccksetzen von Passw\u00f6rtern wissen wollten. Teil 2 | ProHoster","description":"Zwei-Faktor-Authentifizierung Alles, was Sie im ersten Teil gelesen haben, bezog sich auf die Identifizierung basierend auf dem, was.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0441\u0451, \u0447\u0442\u043e \u0432\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u0437\u043d\u0430\u0442\u044c \u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u043c \u0441\u0431\u0440\u043e\u0441\u0435 \u043f\u0430\u0440\u043e\u043b\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-20T00:42:56+00:00","article:modified_time":"2020-10-20T00:42:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97639","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:16:25","updated":"2022-10-03 07:14:42","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}