Der endgültige Leitfaden zur formularbasierten Website-Authentifizierung

Question

Anmerkung des Moderators:

Diese Frage eignet sich nicht für unser Frage- und Antwortformat mit dem Aktualitätsregeln die derzeit für Stack Overflow gelten. Normalerweise verwenden wir eine "historische Sperre" für solche Fragen, bei denen der Inhalt immer noch einen Wert hat. Die Antworten auf diese Frage werden jedoch aktiv gepflegt und eine historische Sperre erlaubt keine Bearbeitung der Antworten. Daher wurde eine "Wiki-Antwort"-Sperre eingerichtet, damit die Antworten bearbeitet werden können. Sie sollten davon ausgehen, dass die Aktualitätsprobleme, die normalerweise durch eine historische Sperre behandelt werden, vorhanden sind (d.h. diese Frage ist kein gutes Beispiel für eine themenbezogene Frage für Stack Overflow).

Formularbasierte Authentifizierung für Websites

Wir sind der Meinung, dass Stack Overflow nicht nur eine Ressource für sehr spezifische technische Fragen sein sollte, sondern auch für allgemeine Anleitungen, wie man Variationen von häufigen Problemen lösen kann. "Formularbasierte Authentifizierung für Websites" sollte ein gutes Thema für ein solches Experiment sein.

Sie sollte Themen wie z. B.:

• Wie man sich anmeldet
• Wie man sich abmeldet
• So bleiben Sie eingeloggt
• Verwaltung von Cookies (einschließlich empfohlener Einstellungen)
• SSL/HTTPS-Verschlüsselung
• Passwörter speichern
• Geheime Fragen verwenden
• Funktion für vergessenen Benutzernamen/Passwort
• Verwendung von nonces zu verhindern Cross-Site-Request-Forgeries (CSRF)
• OpenID
• Kontrollkästchen "Mich erinnern"
• Automatische Vervollständigung von Benutzernamen und Kennwörtern im Browser
• Geheime URLs (öffentlich URL geschützt durch digest)
• Überprüfung der Passwortstärke
• E-Mail-Validierung
• und vieles mehr über formularbasierte Authentifizierung ...

Sie sollte keine Dinge wie:

• Rollen und Befugnisse
• HTTP-Basisauthentifizierung

Bitte helfen Sie uns:

1. Vorschlagen von Unterthemen
2. Einreichung guter Artikel zu diesem Thema
3. Bearbeitung der offiziellen Antwort

Answer 1

TEIL I: Wie man sich anmeldet

Wir gehen davon aus, dass Sie bereits wissen, wie man ein Login+Passwort-HTML-Formular erstellt, das die Werte zur Authentifizierung an ein Skript auf der Serverseite sendet. Die folgenden Abschnitte befassen sich mit Mustern für eine solide, praktische Authentifizierung und wie man die häufigsten Sicherheitsfallen vermeidet.

Zu HTTPS oder nicht zu HTTPS?

Wenn die Verbindung nicht bereits sicher ist (d. h. über HTTPS mit SSL/TLS getunnelt), werden die Werte Ihres Anmeldeformulars im Klartext gesendet, so dass jeder, der die Verbindung zwischen Browser und Webserver abhört, die Anmeldedaten lesen kann, während sie übertragen werden. Diese Art des Abhörens wird routinemäßig von Regierungen durchgeführt, aber im Allgemeinen werden wir uns nicht mit "eigenen" Leitungen befassen, außer um dies zu sagen: Verwenden Sie einfach HTTPS.

Im Grunde genommen ist die einzige praktisch Eine Möglichkeit, sich gegen Abhören/Paketschnüffeln während der Anmeldung zu schützen, ist die Verwendung von HTTPS oder eines anderen zertifikatsbasierten Verschlüsselungsverfahrens (z. B., TLS ) oder ein bewährtes und getestetes Challenge-Response-Schema (zum Beispiel das Diffie-Hellman -basierten SRP). Jede andere Methode kann leicht umgangen werden durch einen abhörenden Angreifer.

Wenn Sie bereit sind, ein wenig unpraktisch zu werden, können Sie natürlich auch eine Form der Zwei-Faktor-Authentifizierung verwenden (z. B. die Google Authenticator-App, ein physisches Codebuch im Stil des Kalten Krieges oder einen RSA-Schlüsselgenerator-Dongle). Bei richtiger Anwendung könnte dies sogar mit einer ungesicherten Verbindung funktionieren, aber es ist schwer vorstellbar, dass ein Entwickler bereit wäre, eine Zwei-Faktor-Authentifizierung zu implementieren, aber nicht SSL.

(Nicht) Roll-your-own JavaScript-Verschlüsselung/Hashing

Angesichts der wahrgenommenen (aber inzwischen vermeidbar ) Kosten und technische Schwierigkeiten bei der Einrichtung eines SSL-Zertifikats auf Ihrer Website, sind einige Entwickler versucht, ihre eigenen browserinternen Hashing- oder Verschlüsselungsschemata zu entwickeln, um zu vermeiden, dass Anmeldungen im Klartext über eine ungesicherte Leitung übertragen werden.

Dies ist zwar ein edler Gedanke, aber im Grunde genommen nutzlos (und kann ein Sicherheitslücke ), es sei denn, sie wird mit einem der oben genannten Verfahren kombiniert, d. h. entweder mit einer starken Verschlüsselung oder mit einem bewährten Challenge-Response-Mechanismus (wenn Sie nicht wissen, was das ist, sollten Sie wissen, dass es sich um eines der am schwierigsten zu beweisenden, am schwierigsten zu entwickelnden und am schwierigsten zu implementierenden Konzepte der digitalen Sicherheit handelt).

Es stimmt zwar, dass das Hashing des Passworts kann sein wirksam gegen Offenlegung des Passworts Wenn ein Angreifer ein paar Bytes in Ihre ungesicherte HTML-Seite einschleusen kann, bevor sie Ihren Browser erreicht, kann er das Hashing im JavaScript einfach auskommentieren. Außerdem ist es anfällig für Brute-Force-Angriffe (da Sie dem Angreifer sowohl den Benutzernamen, das Salt als auch das gehashte Passwort übergeben).

CAPTCHAS gegen die Menschheit

CAPTCHA soll eine bestimmte Kategorie von Angriffen vereiteln: automatisierte Wörterbuch-/Brute-Force-Versuche ohne menschlichen Bediener. Es besteht kein Zweifel, dass dies eine reale Bedrohung ist, aber es gibt Möglichkeiten, nahtlos damit umzugehen, die kein CAPTCHA erfordern, insbesondere richtig konzipierte serverseitige Anmeldedrosselungssysteme - wir werden diese später besprechen.

Wisse, dass CAPTCHA-Implementierungen nicht gleich sind; sie sind oft nicht von Menschen lösbar, die meisten von ihnen sind tatsächlich unwirksam gegen Bots, alle von ihnen sind unwirksam gegen billige Arbeit aus der Dritten Welt (laut OWASP (der derzeitige Ausbeutungspreis beträgt 12 $ pro 500 Tests), und einige Implementierungen können in einigen Ländern technisch illegal sein (siehe OWASP-Authentifizierungs-Spickzettel ). Wenn Sie ein CAPTCHA verwenden müssen, verwenden Sie das von Google reCAPTCHA da es per Definition OCR-schwer ist (da es bereits OCR-missklassifizierte Buchscans verwendet) und sich sehr bemüht, benutzerfreundlich zu sein.

Ich persönlich empfinde CAPTCHAS eher als lästig und verwende sie nur als letztes Mittel, wenn ein Benutzer sich mehrmals nicht anmelden konnte und die Drosselungszeiten ausgeschöpft sind. Das kommt so selten vor, dass es akzeptabel ist, und es stärkt das System insgesamt.

Speichern von Passwörtern / Überprüfen von Anmeldungen

Nach all den öffentlichkeitswirksamen Hacks und Datenlecks, die in den letzten Jahren aufgetreten sind, ist dies vielleicht schon allgemein bekannt, aber es muss einfach gesagt werden: Speichern Sie keine Passwörter im Klartext in Ihrer Datenbank. Benutzerdatenbanken werden routinemäßig gehackt, geleakt oder durch SQL-Injektion ausgelesen, und wenn Sie Passwörter im Klartext speichern, ist es mit der Anmeldesicherheit sofort vorbei.

Wenn Sie also das Kennwort nicht speichern können, wie überprüfen Sie dann, ob die Kombination aus Login und Kennwort, die vom Anmeldeformular gepostet wird, korrekt ist? Die Antwort ist Hashing mit einer Schlüsselableitungsfunktion . Jedes Mal, wenn ein neuer Benutzer angelegt oder ein Passwort geändert wird, lassen Sie das Passwort durch ein KDF wie Argon2, bcrypt, scrypt oder PBKDF2 laufen und verwandeln das Klartext-Passwort ("correcthorsebatterystaple") in eine lange, zufällig aussehende Zeichenkette, die in Ihrer Datenbank viel sicherer zu speichern ist. Um eine Anmeldung zu verifizieren, führen Sie dieselbe Hash-Funktion für das eingegebene Kennwort aus, wobei Sie diesmal das Salt hinzufügen und die resultierende Hash-Zeichenkette mit dem in Ihrer Datenbank gespeicherten Wert vergleichen. Argon2, bcrypt und scrypt speichern das Salz bereits mit dem Hashwert. Schauen Sie sich dies an Artikel auf sec.stackexchange für ausführlichere Informationen.

Der Grund, warum ein Salt verwendet wird, ist, dass Hashing an sich nicht ausreicht - man muss ein sogenanntes "Salt" hinzufügen, um den Hash gegen Regenbogentische . Ein Salt verhindert, dass zwei Passwörter, die genau übereinstimmen, als derselbe Hash-Wert gespeichert werden, so dass nicht die gesamte Datenbank in einem Durchgang gescannt werden kann, wenn ein Angreifer einen Passwort-Rate-Angriff durchführt.

Ein kryptografischer Hash sollte nicht für die Speicherung von Passwörtern verwendet werden, da vom Benutzer gewählte Passwörter nicht stark genug sind (d. h. in der Regel nicht genug Entropie enthalten) und ein Angreifer mit Zugang zu den Hashes in relativ kurzer Zeit ein Passwort erraten könnte. Aus diesem Grund werden KDFs verwendet, die effektiv "Den Schlüssel strecken" Das bedeutet, dass der Hash-Algorithmus bei jedem Erraten des Kennworts durch einen Angreifer mehrfach wiederholt wird, z. B. 10.000 Mal, wodurch der Angreifer das Kennwort 10.000 Mal langsamer erraten kann.

Sitzungsdaten - "Sie sind eingeloggt als Spiderman69"

Sobald der Server die Anmeldung und das Kennwort mit Ihrer Benutzerdatenbank abgeglichen und eine Übereinstimmung gefunden hat, muss das System eine Möglichkeit haben, sich zu merken, dass der Browser authentifiziert worden ist. Diese Tatsache sollte immer nur serverseitig in den Sitzungsdaten gespeichert werden.

Wenn Sie mit Sitzungsdaten nicht vertraut sind, erfahren Sie hier, wie sie funktionieren: Eine einzelne, zufällig erzeugte Zeichenfolge wird in einem ablaufenden Cookie gespeichert und verwendet, um auf eine Sammlung von Daten - die Sitzungsdaten - zu verweisen, die auf dem Server gespeichert sind. Wenn Sie ein MVC-Framework verwenden, wird dies zweifelsohne bereits gehandhabt.

Vergewissern Sie sich nach Möglichkeit, dass das Sitzungscookie beim Senden an den Browser die Flags "Sicher" und "Nur HTTP" gesetzt hat. Das HttpOnly-Flag bietet einen gewissen Schutz gegen das Auslesen des Cookies durch XSS-Angriffe. Das Secure-Flag sorgt dafür, dass das Cookie nur über HTTPS zurückgesendet wird, und schützt somit vor Netzwerk-Sniffing-Angriffen. Der Wert des Cookies sollte nicht vorhersehbar sein. Wenn ein Cookie, das auf eine nicht existierende Sitzung verweist, vorgelegt wird, sollte sein Wert sofort ersetzt werden, um zu verhindern, dass Sitzungsfixierung .

Der Sitzungsstatus kann auch auf der Client-Seite beibehalten werden. Dies wird durch die Verwendung von Techniken wie JWT (JSON Web Token) erreicht.

TEIL II: Wie man eingeloggt bleibt - Die berüchtigte "Remember Me"-Checkbox

Persistente Anmelde-Cookies ("remember me"-Funktionalität) sind eine Gefahrenzone; einerseits sind sie genauso sicher wie herkömmliche Anmeldungen, wenn die Benutzer wissen, wie sie damit umgehen müssen, andererseits stellen sie ein enormes Sicherheitsrisiko in den Händen unvorsichtiger Benutzer dar, die sie möglicherweise auf öffentlichen Computern verwenden und vergessen, sich abzumelden, und die möglicherweise nicht wissen, was Browser-Cookies sind oder wie man sie löscht.

Ich persönlich mag dauerhafte Logins für die Websites, die ich regelmäßig besuche, aber ich weiß, wie ich sie sicher handhaben kann. Wenn Sie sicher sind, dass Ihre Benutzer dasselbe wissen, können Sie mit gutem Gewissen dauerhafte Anmeldungen verwenden. Wenn nicht - nun, dann können Sie sich der Philosophie anschließen, dass Benutzer, die unvorsichtig mit ihren Anmeldedaten umgehen, es selbst verschuldet haben, wenn sie gehackt werden. Es ist ja nicht so, dass wir zu unseren Benutzern nach Hause gehen und all die Post-It-Zettel mit Passwörtern abreißen, die sie am Rande ihrer Monitore aufgereiht haben, um sich den Mund fusselig zu reden.

Natürlich können es sich manche Systeme nicht leisten, eine cualquier Konten gehackt werden; für solche Systeme gibt es keine Möglichkeit, dauerhafte Logins zu rechtfertigen.

Wenn Sie sich dafür entscheiden, dauerhafte Anmelde-Cookies zu verwenden, gehen Sie folgendermaßen vor:

1. Nehmen Sie sich zunächst etwas Zeit zum Lesen Der Artikel der Paragon Initiative zu diesem Thema. Sie müssen eine Reihe von Elementen richtig, und der Artikel macht eine gute Arbeit der Erklärung jedes.

2. Und um noch einmal auf einen der häufigsten Fallstricke hinzuweisen, SPEICHERN SIE DEN DAUERHAFTEN LOGIN-COOKIE (TOKEN) NICHT IN IHRER DATENBANK, SONDERN NUR EINEN HASH DAVON! Das Login-Token ist passwortgleich, d. h., wenn ein Angreifer Ihre Datenbank in die Hände bekäme, könnte er die Token verwenden, um sich bei jedem Konto anzumelden, als ob es sich um eine Klartext-Kombination aus Login und Passwort handeln würde. Verwenden Sie daher Hashing (gemäß https://security.stackexchange.com/a/63438/5002 ein schwacher Hash reicht für diesen Zweck völlig aus), wenn dauerhafte Anmeldetoken gespeichert werden.

TEIL III: Geheime Fragen verwenden

Keine "Geheimfragen" einführen . Die Funktion "geheime Fragen" ist ein Sicherheitsmusterstück. Lesen Sie das Papier unter Link Nummer 4 auf der MUST-READ-Liste. Sie können Sarah Palin danach fragen, nachdem ihr Yahoo!-E-Mail-Konto während einer früheren Präsidentschaftskampagne gehackt wurde, weil die Antwort auf ihre Sicherheitsfrage lautete... "Wasilla High School"!

Selbst bei benutzerspezifischen Fragen ist es sehr wahrscheinlich, dass die meisten Nutzer eine der beiden Möglichkeiten wählen:

• Eine "Standard"-Geheimfrage wie der Mädchenname der Mutter oder das Lieblingstier

• Eine einfache Kleinigkeit, die jeder aus seinem Blog, LinkedIn-Profil oder ähnlichem übernehmen könnte

• Jede Frage, die leichter zu beantworten ist als das Erraten des Passworts. Für ein anständiges Passwort sind das alle Fragen, die Sie sich vorstellen können

Zusammenfassend lässt sich sagen, dass Sicherheitsfragen in praktisch all ihren Formen und Variationen von Natur aus unsicher sind und aus keinem Grund in einem Authentifizierungsschema verwendet werden sollten.

Der wahre Grund, warum es Sicherheitsfragen überhaupt gibt, ist, dass sie die Kosten für ein paar Support-Anrufe von Nutzern sparen, die keinen Zugriff auf ihre E-Mail haben, um an einen Reaktivierungscode zu gelangen. Dies geschieht auf Kosten der Sicherheit und des Rufs von Sarah Palin. Ist es das wert? Wahrscheinlich nicht.

TEIL IV: Funktionalität für vergessene Passwörter

Ich habe bereits erwähnt, warum Sie niemals Sicherheitsfragen verwenden für den Umgang mit vergessenen/verlorenen Benutzerkennwörtern; es versteht sich auch von selbst, dass Sie den Benutzern niemals ihre aktuellen Kennwörter per E-Mail zusenden sollten. In diesem Bereich gibt es mindestens zwei weitere, allzu häufige Fallstricke, die es zu vermeiden gilt:

1. Nicht zurücksetzen ein vergessenes Passwort zu einem automatisch generierten starken Passwort - solche Passwörter sind notorisch schwer zu merken, was bedeutet, dass der Benutzer es entweder ändern oder aufschreiben muss - z. B. auf einem leuchtend gelben Post-It am Rande seines Monitors. Anstatt ein neues Kennwort festzulegen, lassen Sie die Benutzer einfach gleich ein neues wählen - was sie ja ohnehin tun wollen. (Eine Ausnahme könnte sein, wenn die Benutzer generell einen Passwort-Manager verwenden, um Passwörter zu speichern/verwalten, die man sich ohne Aufschreiben nicht merken kann).

2. Der Code/Token des verlorenen Kennworts wird immer in der Datenbank gehasht. AGAIN Dieser Code ist ein weiteres Beispiel für ein Passwort-Äquivalent und MUSS daher gehasht werden, falls ein Angreifer Ihre Datenbank in die Hände bekommt. Wenn ein verlorener Kennwortcode angefordert wird, senden Sie den Klartextcode an die E-Mail-Adresse des Benutzers, hacken ihn, speichern den Hash in Ihrer Datenbank und das Original wegwerfen . Genau wie ein Passwort oder ein dauerhaftes Login-Token.

Ein letzter Hinweis: Stellen Sie immer sicher, dass Ihre Schnittstelle für die Eingabe des Codes für das verlorene Kennwort mindestens so sicher ist wie Ihr Anmeldeformular selbst, da ein Angreifer stattdessen einfach diese Schnittstelle benutzen wird, um Zugang zu erhalten. Sie sollten sicherstellen, dass Sie sehr lange Codes für verlorene Passwörter generieren (z. B. 16 alphanumerische Zeichen unter Berücksichtigung der Groß- und Kleinschreibung), aber Sie sollten das gleiche Drosselungsschema wie für das Anmeldeformular selbst anwenden.

TEIL V: Überprüfen der Passwortstärke

Zunächst sollten Sie diesen kleinen Artikel lesen, um sich über die Realität zu informieren: Die 500 häufigsten Passwörter

Okay, vielleicht ist die Liste nicht die kanonisch Liste der häufigsten Passwörter auf cualquier System überall aber es ist ein guter Hinweis darauf, wie schlecht die Leute ihre Passwörter wählen, wenn es keine durchgesetzte Richtlinie gibt. Außerdem sieht die Liste erschreckend ähnlich aus, wenn man sie mit öffentlich zugänglichen Analysen von kürzlich gestohlenen Passwörtern vergleicht.

Also: Da es keine Mindestanforderungen an die Passwortstärke gibt, verwenden 2 % der Nutzer eines der 20 häufigsten Passwörter. Das bedeutet: Wenn ein Angreifer nur 20 Versuche hat, ist 1 von 50 Konten auf Ihrer Website knackbar.

Um dies zu vereiteln, muss die Entropie eines Kennworts berechnet und dann ein Schwellenwert angewendet werden. Das National Institute of Standards and Technology (NIST) Sonderveröffentlichung 800-63 hat eine Reihe von sehr guten Vorschlägen. In Kombination mit einer Wörterbuch- und Tastaturlayout-Analyse (z. B. ist "qwertyuiop" ein schlechtes Passwort) können diese Vorschläge 99% aller schlecht gewählten Passwörter zurückweisen auf einem Niveau von 18 Bits Entropie. Einfaches Berechnen der Passwortstärke und Anzeige einer visuellen Stärkeanzeige für einen Nutzer ist gut, aber nicht ausreichend. Solange sie nicht durchgesetzt wird, werden viele Nutzer sie höchstwahrscheinlich ignorieren.

Einen erfrischenden Blick auf die Benutzerfreundlichkeit von Passwörtern mit hoher Entropie bietet Randall Munroes Passwortstärke xkcd wird dringend empfohlen.

Nutzen Sie Troy Hunts Wurde ich von API reingelegt? um die Passwörter der Benutzer mit den Passwörtern zu vergleichen, die bei öffentlichen Datenschutzverletzungen kompromittiert wurden.

TEIL VI: Viel mehr - oder: Verhinderung von Schnellfeuer-Anmeldeversuchen

Werfen wir zunächst einen Blick auf die Zahlen: Geschwindigkeit der Passwortwiederherstellung - Wie lange hält Ihr Passwort stand?

Wenn Sie nicht die Zeit haben, die Tabellen in diesem Link durchzusehen, finden Sie hier eine Liste der Tabellen:

1. Es braucht praktisch keine Zeit ein schwaches Passwort zu knacken, selbst wenn man es mit einem Abakus knackt

2. Es braucht praktisch keine Zeit ein alphanumerisches 9-Zeichen-Passwort zu knacken, wenn es Groß- und Kleinschreibung wird nicht berücksichtigt

3. Es braucht praktisch keine Zeit ein kompliziertes Passwort mit Symbolen, Buchstaben und Zahlen, Groß- und Kleinschreibung zu knacken, wenn es weniger als 8 Zeichen lang (ein Desktop-PC kann den gesamten Schlüsselraum bis zu 7 Zeichen in wenigen Tagen oder sogar Stunden durchsuchen)

4. Es würde jedoch unverhältnismäßig viel Zeit in Anspruch nehmen, selbst ein 6-Zeichen-Passwort zu knacken, wenn man auf einen Versuch pro Sekunde beschränkt wäre!

Was können wir also aus diesen Zahlen lernen? Nun, eine ganze Menge, aber wir können uns auf den wichtigsten Teil konzentrieren: die Tatsache, dass die Verhinderung einer großen Anzahl von schnell aufeinanderfolgenden Anmeldeversuchen (d. h. die brachiale Gewalt Angriff) ist wirklich nicht so schwierig. Aber es zu verhindern rechts ist nicht so einfach, wie es scheint.

Im Allgemeinen haben Sie drei Möglichkeiten, die alle gegen Brute-Force-Angriffe wirksam sind (und Wörterbuchangriffe, aber da Sie bereits eine Richtlinie für sichere Kennwörter anwenden, sollten diese kein Problem darstellen) :

• Präsentieren Sie eine CAPTCHA nach N fehlgeschlagenen Versuchen (verdammt ärgerlich und oft unwirksam - aber ich wiederhole mich hier)

• Konten sperren und eine E-Mail-Verifizierung nach N fehlgeschlagenen Versuchen (dies ist eine DoS Angriff zu erwarten)

• Und schließlich, Drosselung der Anmeldung (ja, DoS-Angriffe sind immer noch möglich, aber zumindest sind sie viel unwahrscheinlicher und viel komplizierter zu bewerkstelligen).

Bewährte Praxis Nr. 1: Eine kurze Zeitverzögerung, die mit der Anzahl der Fehlversuche zunimmt, wie:

• 1 Fehlversuch = keine Verzögerung
• 2 Fehlversuche = 2 Sekunden Verzögerung
• 3 Fehlversuche = 4 Sekunden Verzögerung
• 4 Fehlversuche = 8 Sekunden Verzögerung
• 5 Fehlversuche = 16 Sekunden Verzögerung
• usw.

Ein DoS-Angriff auf dieses System wäre sehr unpraktisch, da die resultierende Sperrzeit etwas größer ist als die Summe der vorherigen Sperrzeiten.

Zur Klarstellung: Die Verzögerung ist no eine Verzögerung, bevor die Antwort an den Browser zurückgegeben wird. Es handelt sich eher um eine Zeitüberschreitung oder eine Refraktärzeit, in der Anmeldeversuche für ein bestimmtes Konto oder von einer bestimmten IP-Adresse aus nicht akzeptiert oder ausgewertet werden. Das heißt, korrekte Anmeldedaten führen nicht zu einer erfolgreichen Anmeldung, und falsche Anmeldedaten führen nicht zu einer Erhöhung der Verzögerung.

Bewährte Praxis Nr. 2: Eine mittlere Zeitverzögerung, die nach N Fehlversuchen in Kraft tritt, wie:

• 1-4 Fehlversuche = keine Verzögerung
• 5 Fehlversuche = 15-30 Minuten Verzögerung

Ein DoS-Angriff auf dieses System wäre ziemlich unpraktisch, aber durchaus machbar. Außerdem sollte man bedenken, dass eine so lange Verzögerung für einen legitimen Benutzer sehr ärgerlich sein kann. Vergessliche Benutzer werden Sie nicht mögen.

Bewährte Praxis Nr. 3: Die Kombination der beiden Ansätze - entweder eine feste, kurze Verzögerung, die nach N Fehlversuchen in Kraft tritt, wie:

• 1-4 Fehlversuche = keine Verzögerung
• 5+ Fehlversuche = 20 Sekunden Verzögerung

Oder eine zunehmende Verzögerung mit einer festen Obergrenze, etwa:

• 1 Fehlversuch = 5 Sekunden Verzögerung
• 2 Fehlversuche = 15 Sekunden Verzögerung
• 3+ Fehlversuche = 45 Sekunden Verzögerung

Dieses endgültige Schema stammt aus den OWASP-Vorschlägen für bewährte Praktiken (Link 1 aus der MUST-READ-Liste) und sollte als bewährte Praxis betrachtet werden, auch wenn es zugegebenermaßen etwas restriktiv ist.

Als Faustregel würde ich jedoch sagen: Je strenger Ihre Passwortpolitik ist, desto weniger müssen Sie die Benutzer mit Verzögerungen nerven. Wenn Sie starke Passwörter (Groß- und Kleinschreibung, alphanumerische Zeichen + erforderliche Zahlen und Symbole) mit mehr als 9 Zeichen verlangen, könnten Sie den Benutzern 2-4 unverzögerte Passwortversuche geben, bevor Sie die Drosselung aktivieren.

Ein DoS-Angriff auf dieses endgültige Anmeldedrosselungsschema wäre sehr unpraktisch. Und als letzten Schliff sollten Sie immer dauerhafte (Cookie-)Anmeldungen (und/oder ein CAPTCHA-verifiziertes Anmeldeformular) zulassen, damit legitime Benutzer nicht einmal aufgehalten werden. während der Angriff läuft . Auf diese Weise wird der sehr unpraktische DoS-Angriff zu einer extrem undurchführbarer Angriff.

Darüber hinaus ist es sinnvoll, die Drosselung von Administratorkonten zu verschärfen, da dies die attraktivsten Einstiegspunkte sind.

TEIL VII: Verteilte Brute-Force-Angriffe

Nebenbei bemerkt werden fortgeschrittene Angreifer versuchen, die Anmeldedrosselung zu umgehen, indem sie ihre Aktivitäten "ausbreiten":

• Verteilung der Versuche auf ein Botnetz, um die Kennzeichnung von IP-Adressen zu verhindern

• Anstatt einen Benutzer auszuwählen und die 50.000 häufigsten Passwörter auszuprobieren (was aufgrund unserer Drosselung nicht möglich ist), wählen sie DAS häufigste Passwort und probieren es stattdessen an 50.000 Benutzern aus. Auf diese Weise umgehen sie nicht nur Maßnahmen wie CAPTCHAs und Login-Drosselungen, sondern erhöhen auch ihre Erfolgschancen, da das häufigste Passwort Nummer 1 viel wahrscheinlicher ist als Nummer 49.995.

• Die Anmeldeanfragen für die einzelnen Benutzerkonten werden in Abständen von z. B. 30 Sekunden gestellt, um unbemerkt zu bleiben.

Die beste Vorgehensweise wäre hier Protokollierung der Anzahl der fehlgeschlagenen Anmeldungen, systemweit und verwenden Sie einen laufenden Durchschnitt der Häufigkeit von Fehllogins auf Ihrer Website als Grundlage für eine Obergrenze, die Sie dann allen Benutzern auferlegen.

Zu abstrakt? Lassen Sie es mich anders ausdrücken:

Angenommen, auf Ihrer Website gab es in den letzten 3 Monaten durchschnittlich 120 unzulässige Anmeldungen pro Tag. Ausgehend von diesem (laufenden) Durchschnitt könnte Ihr System das globale Limit auf das Dreifache dieses Wertes setzen, d. h. 360 Fehlversuche in einem Zeitraum von 24 Stunden. Wenn dann die Gesamtzahl der Fehlversuche über alle Konten hinweg diese Zahl innerhalb eines Tages übersteigt (oder noch besser, wenn Sie die Beschleunigung überwachen und bei einem berechneten Schwellenwert auslösen), wird die systemweite Anmeldedrosselung aktiviert, d. h. kurze Verzögerungen für ALLE Benutzer (immer noch mit Ausnahme von Cookie-Anmeldungen und/oder Backup-CAPTCHA-Anmeldungen).

Ich habe auch eine Frage mit mehr Details und eine wirklich gute Diskussion darüber, wie man knifflige Pitfals vermeiden kann bei der Abwehr von verteilten Brute-Force-Angriffen

TEIL VIII: Zwei-Faktoren-Authentifizierung und Authentifizierungsanbieter

Anmeldedaten können kompromittiert werden, sei es durch Exploits, aufgeschriebene und verlorene Passwörter, gestohlene Laptops mit Schlüsseln oder Benutzer, die sich auf Phishing-Seiten anmelden. Anmeldungen können mit der Zwei-Faktor-Authentifizierung weiter geschützt werden, die Out-of-Band-Faktoren wie Einmal-Codes verwendet, die über einen Anruf, eine SMS, eine App oder einen Dongle empfangen werden. Mehrere Anbieter bieten Dienste zur Zwei-Faktor-Authentifizierung an.

Die Authentifizierung kann vollständig an einen Single-Sign-On-Dienst delegiert werden, bei dem ein anderer Anbieter die Erfassung der Anmeldedaten übernimmt. Dadurch wird das Problem auf eine vertrauenswürdige Drittpartei verlagert. Google und Twitter bieten beide standardbasierte SSO-Dienste, während Facebook eine ähnliche proprietäre Lösung anbietet.

MUST-READ LINKS Über Web-Authentifizierung

1. OWASP-Leitfaden zur Authentifizierung / OWASP-Authentifizierungs-Spickzettel
2. Dos and Don'ts of Client Authentication on the Web (sehr lesenswertes MIT-Forschungspapier)
3. Wikipedia: HTTP-Cookie
4. Persönliche Wissensfragen zur Fallback-Authentifizierung: Security questions in the era of Facebook (sehr lesenswertes Berkeley-Forschungspapier)

Answer 2

Endgültiger Artikel

Übermittlung von Anmeldeinformationen

Die einzige praktische Möglichkeit, Zugangsdaten 100% sicher zu senden, ist die Verwendung von SSL . Die Verwendung von JavaScript zum Hashing des Passworts ist nicht sicher. Häufige Fallstricke beim client-seitigen Passwort-Hashing:

• Wenn die Verbindung zwischen Client und Server nicht verschlüsselt ist, ist alles, was Sie tun anfällig für Man-in-the-Middle-Angriffe . Ein Angreifer könnte das eingehende Javascript ersetzen, um das Hashing zu brechen oder alle Anmeldeinformationen an seinen Server zu senden, er könnte die Antworten des Clients abhören und sich perfekt als der Benutzer ausgeben usw. usw. SSL mit vertrauenswürdigen Zertifizierungsstellen ist darauf ausgelegt, MitM-Angriffe zu verhindern.
• Das vom Server empfangene gehashte Passwort lautet weniger sicher wenn Sie keine zusätzliche, überflüssige Arbeit auf dem Server verrichten.

Es gibt eine weitere sichere Methode namens SRP aber es ist patentiert (obwohl es frei lizenziert ) und es sind nur wenige gute Implementierungen verfügbar.

Speichern von Passwörtern

Speichern Sie Kennwörter niemals im Klartext in der Datenbank. Auch dann nicht, wenn Sie sich nicht um die Sicherheit Ihrer eigenen Website kümmern. Gehen Sie davon aus, dass einige Ihrer Benutzer das Passwort ihres Online-Bankkontos wiederverwenden werden. Speichern Sie also das gehashte Passwort, und werfen Sie das Original weg. Und stellen Sie sicher, dass das Passwort nicht in Zugangs- oder Anwendungsprotokollen auftaucht. OWASP empfiehlt die Verwendung von Argon2 als Ihre erste Wahl für neue Bewerbungen. Wenn dies nicht verfügbar ist, sollte stattdessen PBKDF2 oder scrypt verwendet werden. Und schließlich, wenn keines der oben genannten verfügbar ist, verwenden Sie bcrypt.

Auch Hashes an sich sind unsicher. Zum Beispiel bedeuten identische Kennwörter identische Hashes - dies macht Hash-Lookup-Tabellen zu einem effektiven Mittel, um viele Kennwörter auf einmal zu knacken. Speichern Sie stattdessen die gesalzen Haschisch. Ein Salt ist eine Zeichenkette, die vor dem Hashing an das Passwort angehängt wird - verwenden Sie für jeden Benutzer ein anderes (zufälliges) Salt. Das Salt ist ein öffentlicher Wert, so dass Sie es zusammen mit dem Hash in der Datenbank speichern können. Siehe aquí um mehr darüber zu erfahren.

Das bedeutet, dass Sie den Benutzern ihre vergessenen Passwörter nicht schicken können (weil Sie nur den Hash haben). Setzen Sie das Passwort des Benutzers erst zurück, wenn Sie den Benutzer authentifiziert haben (der Benutzer muss nachweisen, dass er in der Lage ist, E-Mails zu lesen, die an die gespeicherte (und validierte) E-Mail-Adresse gesendet werden).

Fragen zur Sicherheit

Sicherheitsfragen sind unsicher - verwenden Sie sie nicht. Warum? Alles, was eine Sicherheitsfrage kann, kann ein Passwort besser. Lesen Sie TEIL III: Geheime Fragen verwenden en Antwort von @Jens Roland hier in diesem Wiki.

Sitzungs-Cookies

Nachdem sich der Benutzer angemeldet hat, sendet der Server dem Benutzer ein Sitzungs-Cookie. Der Server kann den Benutzernamen oder die Kennung aus dem Cookie abrufen, aber niemand sonst kann ein solches Cookie erzeugen (TODO erklären Mechanismen).

Cookies können gekapert werden Sie sind nur so sicher wie der restliche Rechner des Kunden und die übrige Kommunikation. Sie können von der Festplatte gelesen, im Netzverkehr ausgespäht, durch einen Cross-Site-Scripting-Angriff abgefangen oder von einem vergifteten DNS abgefischt werden, so dass der Kunde seine Cookies an die falschen Server sendet. Senden Sie keine dauerhaften Cookies. Cookies sollten am Ende der Client-Sitzung ablaufen (Schließen des Browsers oder Verlassen Ihres Bereichs).

Wenn Sie Ihre Benutzer automatisch anmelden möchten, können Sie einen dauerhaften Cookie setzen, der sich jedoch von einem Full-Session-Cookie unterscheiden sollte. Sie können ein zusätzliches Kennzeichen setzen, das besagt, dass der Benutzer sich automatisch angemeldet hat und sich für sensible Vorgänge wirklich anmelden muss. Dies ist bei Shopping-Websites beliebt, die Ihnen ein nahtloses, personalisiertes Einkaufserlebnis bieten, aber dennoch Ihre finanziellen Daten schützen wollen. Wenn Sie z. B. zu Amazon zurückkehren, wird Ihnen eine Seite angezeigt, die so aussieht, als seien Sie angemeldet, aber wenn Sie eine Bestellung aufgeben (oder Ihre Lieferadresse, Kreditkarte usw. ändern), werden Sie aufgefordert, Ihr Passwort zu bestätigen.

Finanz-Websites wie Banken und Kreditkarten hingegen enthalten nur sensible Daten und sollten kein Auto-Login oder einen Niedrig-Sicherheitsmodus zulassen.

Liste der externen Ressourcen

• Dos und Don'ts der Client-Authentifizierung im Web (PDF)
  21-seitiger wissenschaftlicher Artikel mit vielen guten Tipps.
• Fragen Sie YC: Bewährte Praktiken für die Benutzerauthentifizierung
  Forumsdiskussion zu diesem Thema
• Wahrscheinlich speichern Sie Ihre Passwörter nicht richtig
  Einführender Artikel über die Speicherung von Passwörtern
• Diskussion: Coding Horror: Wahrscheinlich speichern Sie Ihre Passwörter falsch
  Forumsdiskussion über einen Coding Horror-Artikel.
• Speichern Sie niemals Passwörter in einer Datenbank!
  Eine weitere Warnung vor der Speicherung von Kennwörtern in der Datenbank.
• Passwort knacken
  Wikipedia-Artikel über die Schwächen verschiedener Passwort-Hashing-Verfahren.
• Schluss mit den Regenbogen-Tischen: Was Sie über sichere Passwortschemata wissen müssen
  Diskussion über Regenbogentische und wie man sich dagegen und gegen andere Threads verteidigen kann. Umfasst eine ausführliche Diskussion.

Answer 3

Zunächst einmal möchte ich ausdrücklich darauf hinweisen, dass diese Antwort nicht die beste Lösung für genau diese Frage ist. Sie sollte auf keinen Fall die erste Antwort sein!

Ich erwähne an dieser Stelle die von Mozilla vorgeschlagene BrowserID (oder vielleicht genauer gesagt, die Geprüftes E-Mail-Protokoll ) in dem Bestreben, einen Upgrade-Pfad zu besseren Authentifizierungskonzepten für die Zukunft zu finden.

Ich fasse es folgendermaßen zusammen:

1. Mozilla ist eine gemeinnützige Organisation mit Werte die sich gut mit der Suche nach guten Lösungen für dieses Problem vereinbaren lassen.
2. In der Realität verwenden die meisten Websites heute eine formularbasierte Authentifizierung.
3. Die formularbasierte Authentifizierung hat einen großen Nachteil, nämlich ein erhöhtes Risiko für Phishing . Die Benutzer werden aufgefordert, vertrauliche Informationen in einen Bereich einzugeben, der von einer entfernten Einrichtung kontrolliert wird, und nicht in einen Bereich, der von ihrem User Agent (Browser) kontrolliert wird.
4. Da Browsern implizit vertraut wird (die ganze Idee eines User Agent ist es, im Namen des Nutzers zu handeln), können sie dazu beitragen, diese Situation zu verbessern.
5. Die wichtigste Kraft, die den Fortschritt aufhält, ist Blockierung der Bereitstellung . Lösungen müssen in Schritte zerlegt werden, die für sich genommen einen gewissen inkrementellen Nutzen bieten.
6. Die einfachste dezentralisierte Methode, eine Identität auszudrücken, die in die Internet-Infrastruktur eingebaut ist, ist der Domain-Name.
7. Als zweite Ebene des Ausdrucks der Identität verwaltet jeder Bereich seine eigenen Konten.
8. Das Formular "Konto @ domain" ist prägnant und wird von einer Vielzahl von Protokollen und URI-Schemata unterstützt. Ein solcher Bezeichner ist natürlich am ehesten als E-Mail-Adresse bekannt.
9. E-Mail-Anbieter sind bereits de facto die wichtigsten Online-Identitätsanbieter. Mit den aktuellen Verfahren zum Zurücksetzen von Passwörtern können Sie in der Regel die Kontrolle über ein Konto übernehmen, wenn Sie nachweisen können, dass Sie die zugehörige E-Mail-Adresse des Kontos besitzen.
10. Das Verified Email Protocol wurde vorgeschlagen, um ein sicheres Verfahren auf der Grundlage von Public-Key-Kryptographie zu entwickeln, mit dem Sie gegenüber Domäne B nachweisen können, dass Sie ein Konto bei Domäne A haben.
11. Für Browser, die das Verified Email Protocol nicht unterstützen (derzeit alle), bietet Mozilla ein Shim an, das das Protokoll in clientseitigem JavaScript-Code implementiert.
12. Bei E-Mail-Diensten, die das Verified Email Protocol nicht unterstützen, erlaubt das Protokoll Dritten, als vertrauenswürdige Vermittler aufzutreten und zu behaupten, dass sie den Besitz eines Benutzerkontos überprüft haben. Es ist nicht wünschenswert, eine große Anzahl solcher Drittparteien zu haben; diese Fähigkeit ist nur dazu gedacht, einen Upgrade-Pfad zu ermöglichen, und es ist viel besser, dass E-Mail-Dienste diese Behauptungen selbst bereitstellen.
13. Mozilla bietet einen eigenen Dienst an, der wie eine solche vertrauenswürdige dritte Partei agiert. Dienstanbieter (d. h. vertrauenswürdige Parteien), die das Verified Email Protocol einsetzen, können sich entscheiden, ob sie Mozillas Behauptungen vertrauen wollen oder nicht. Mozillas Dienst verifiziert die Kontoinhaberschaft der Nutzer auf herkömmliche Weise, indem er eine E-Mail mit einem Bestätigungslink versendet.
14. Die Diensteanbieter können dieses Protokoll natürlich zusätzlich zu anderen Authentifizierungsmethoden anbieten.
15. Ein großer Vorteil der Benutzeroberfläche, der hier angestrebt wird, ist der "Identitätsselektor". Wenn ein Nutzer eine Website besucht und sich authentifizieren will, zeigt ihm sein Browser eine Auswahl von E-Mail-Adressen ("persönlich", "Arbeit", "politischer Aktivismus" usw.), mit denen er sich auf der Website identifizieren kann.
16. Ein weiterer großer Vorteil der Benutzeroberfläche, der im Rahmen dieser Bemühungen angestrebt wird, ist damit der Browser mehr über die Sitzung des Nutzers erfährt - als wer sie derzeit angemeldet sind, vor allem - so kann es im Browser Chrom angezeigt werden.
17. Aufgrund des dezentralen Charakters dieses Systems wird eine Bindung an große Websites wie Facebook, Twitter, Google usw. vermieden. Jede Person kann ihre eigene Domain besitzen und somit als ihr eigener Identitätsanbieter auftreten.

Dabei handelt es sich nicht um eine "formularbasierte Authentifizierung für Websites". Aber es ist ein Versuch, von der derzeitigen Norm der formularbasierten Authentifizierung zu etwas Sichererem überzugehen: der browserunterstützten Authentifizierung.

Answer 4

Ich dachte nur, ich würde diese Lösung, die ich gefunden habe, um genau zu funktionieren teilen.

Ich nenne es die Dummy-Feld (obwohl ich das nicht erfunden habe, also schreiben Sie mir das nicht zu).

Kurz gesagt: Sie müssen dies nur in Ihr <form> und prüfen, ob sie bei der Validierung leer ist:

<input type="text" name="email" style="display:none" />

Der Trick besteht darin, dem Bot vorzugaukeln, dass er Daten in ein Pflichtfeld eingeben muss, deshalb habe ich die Eingabe "E-Mail" genannt. Wenn Sie bereits ein Feld namens "E-Mail" verwenden, sollten Sie versuchen, das Dummy-Feld anders zu benennen, z. B. "Firma", "Telefon" oder "E-Mail-Adresse". Wählen Sie einfach etwas aus, von dem Sie wissen, dass Sie es nicht brauchen, und das sich nach etwas anhört, das Menschen normalerweise logisch finden würden, um es in ein Webformular einzugeben. Blenden Sie nun das input Feld mit CSS oder JavaScript/jQuery - was immer Ihnen am besten passt - einfach nicht den Eingang einstellen type a hidden sonst fällt der Bot nicht darauf herein.

Wenn Sie das Formular validieren (entweder client- oder serverseitig), prüfen Sie, ob Ihr Dummy-Feld ausgefüllt wurde, um festzustellen, ob es von einem Menschen oder einem Bot gesendet wurde.

Ejemplo:

Im Falle eines Menschen: Der Benutzer sieht das Dummy-Feld (in meinem Fall "E-Mail") nicht und wird auch nicht versuchen, es auszufüllen. Der Wert des Dummy-Feldes sollte also noch leer sein, wenn das Formular abgeschickt wurde.

Im Falle eines Bots: Der Bot wird ein Feld sehen, das den Typ text und einen Namen email (oder wie auch immer Sie es genannt haben) und wird logischerweise versuchen, es mit den entsprechenden Daten zu füllen. Dabei spielt es keine Rolle, ob Sie das Eingabeformular mit einem ausgefallenen CSS gestaltet haben - Webentwickler machen das ständig. Was auch immer der Wert im Dummy-Feld ist, es ist uns egal, solange er größer ist als 0 Zeichen.

Ich habe diese Methode bei einem Gästebuch in Kombination mit CAPTCHA und seitdem habe ich keinen einzigen Spam-Post mehr gesehen. Ich hatte zuvor eine reine CAPTCHA-Lösung verwendet, die jedoch zu etwa fünf Spam-Beiträgen pro Stunde führte. Das Hinzufügen des Dummy-Feldes in das Formular hat (zumindest bis jetzt) das Auftauchen von Spam verhindert.

Ich glaube, dass dies auch sehr gut mit einem Anmelde-/Authentifizierungsformular verwendet werden kann.

Warnung : Natürlich ist diese Methode nicht 100%ig narrensicher. Bots können so programmiert werden, dass sie Eingabefelder mit dem Stil ignorieren display:none angewendet. Man muss auch an die Leute denken, die eine Form der Autovervollständigung verwenden (wie sie die meisten Browser eingebaut haben!), um alle Formularfelder automatisch auszufüllen. Sie könnten genauso gut ein Dummy-Feld auswählen.

Sie können dies auch ein wenig abwandeln, indem Sie das Dummy-Feld zwar sichtbar lassen, aber außerhalb des Bildschirms, aber das ist ganz Ihnen überlassen.

Seien Sie kreativ!

Answer 5

Ich denke nicht, dass die obige Antwort "falsch" ist, aber es gibt große Bereiche der Authentifizierung, die nicht angesprochen werden (oder der Schwerpunkt liegt auf der Frage, "wie man Cookie-Sitzungen implementiert", und nicht auf der Frage, "welche Optionen zur Verfügung stehen und was die Kompromisse sind".

Meine Änderungsvorschläge/Antworten sind

• Das Problem liegt eher in der Einrichtung der Konten als in der Überprüfung der Passwörter.
• Die Verwendung der Zwei-Faktor-Authentifizierung ist wesentlich sicherer als die raffinierteren Methoden der Passwortverschlüsselung

• Versuchen Sie NICHT, Ihr eigenes Anmeldeformular oder die Speicherung von Passwörtern in einer Datenbank zu implementieren, es sei denn die gespeicherten Daten sind bei der Kontoerstellung wertlos und werden selbst generiert (d. h. im Stil von Web 2.0 wie Facebook), Flickr , usw.)

  1. Bei der Digest-Authentifizierung handelt es sich um einen standardbasierten Ansatz, der von allen wichtigen Browsern und Servern unterstützt wird und bei dem selbst über einen sicheren Kanal kein Passwort gesendet wird.

Auf diese Weise sind keine "Sitzungen" oder Cookies erforderlich, da der Browser selbst die Kommunikation jedes Mal neu verschlüsselt. Dies ist der "leichteste" Entwicklungsansatz.

Ich empfehle dies jedoch nicht, es sei denn, es handelt sich um öffentliche, geringwertige Dienstleistungen. Dies ist ein Problem mit einigen der anderen Antworten oben - versuchen Sie nicht, serverseitige Authentifizierungsmechanismen neu zu implementieren - dieses Problem wurde gelöst und wird von den meisten großen Browsern unterstützt. Verwenden Sie keine Cookies. Speichern Sie nichts in Ihrer eigenen, selbstentwickelten Datenbank. Fragen Sie einfach bei jeder Anfrage, ob die Anfrage authentifiziert ist. Alles andere sollte durch Konfiguration und vertrauenswürdige Software von Dritten unterstützt werden.

Also ...

Erstens verwechseln wir die erstmalige Einrichtung eines Kontos (mit einem Passwort) mit der späteren Überprüfung des Passworts. Wenn ich Flickr bin und Ihre Website zum ersten Mal einrichte, hat der neue Benutzer Zugang zu einem Nullwert (leerer Webspace). Es ist mir wirklich egal, ob die Person, die das Konto erstellt, bei der Angabe ihres Namens lügt. Wenn ich ein Konto für das Intranet/Extranet eines Krankenhauses einrichte, liegt der Wert in allen medizinischen Unterlagen, und deshalb tun sich um die Identität (*) des Erstellers des Kontos kümmern.

Dies ist der sehr, sehr schwierige Teil. Die nur Eine vernünftige Lösung ist ein Netz des Vertrauens. Ein Beispiel: Sie treten dem Krankenhaus als Arzt bei. Sie erstellen eine irgendwo gehostete Webseite mit Ihrem Foto, Ihrer Passnummer und einem öffentlichen Schlüssel und verschlüsseln alles mit dem privaten Schlüssel. Sie besuchen dann das Krankenhaus, und der Systemadministrator sieht sich Ihren Pass an, prüft, ob das Foto mit Ihnen übereinstimmt, und verschlüsselt dann den Hash der Webseite und des Fotos mit dem privaten Schlüssel des Krankenhauses. Von nun an können wir auf sichere Weise Schlüssel und Token austauschen. Das kann jeder, der dem Krankenhaus vertraut (das ist übrigens die geheime Soße). Der Systemadministrator kann Ihnen auch einen RSA Dongle oder eine andere Zwei-Faktor-Authentifizierung.

Aber dies ist eine Los umständlich und nicht sehr Web 2.0. Es ist jedoch die einzige sichere Möglichkeit, neue Konten zu erstellen, die Zugang zu wertvollen, nicht selbst erstellten Informationen haben.

1. Kerberos und SPNEGO - Single-Sign-On-Mechanismen mit einer vertrauenswürdigen dritten Partei - im Grunde verifiziert sich der Benutzer gegenüber einer vertrauenswürdigen dritten Partei. (Anmerkung: Dies ist in keiner Weise die nicht zu vertrauende OAuth )

2. SRP - eine Art clevere Passwortauthentifizierung ohne eine vertrauenswürdige dritte Partei. Aber hier kommen wir in den Bereich von "es ist sicherer, eine Zwei-Faktor-Authentifizierung zu verwenden, auch wenn das teurer ist".

3. SSL Client-Seite - den Clients ein öffentliches Schlüsselzertifikat aushändigen (wird von allen gängigen Browsern unterstützt, wirft aber Fragen zur Sicherheit der Client-Rechner auf).

Letzten Endes geht es um einen Kompromiss - die Kosten eines Sicherheitsverstoßes gegenüber den Kosten für die Implementierung sicherer Ansätze. Eines Tages werden wir vielleicht eine richtige PKI weithin akzeptiert und somit keine eigenen Formulare und Datenbanken zur Authentifizierung mehr. Eines Tages...