Frage:
Ist es sicher, eindeutige Benutzernamen / Passwörter über eine https-Verbindung zu senden, um Benutzer zu authentifizieren?
Emiliano
2014-08-04 18:56:32 UTC
view on stackexchange narkive permalink

Ich richte einen HTTP-Heimserver ein, der JSON-Daten an / von verschiedenen Clients (Android- und iPhone-Apps) senden und empfangen kann.

Ich möchte den Zugriff nur bestimmten Benutzern und Benutzern ermöglichen Ich denke darüber nach, einen einfachen Mechanismus für Benutzernamen und Kennwörter zu verwenden, da das Einrichten von Clientzertifikaten für dieses kleine Projekt etwas übertrieben erscheint.

Natürlich kann ich keine eindeutigen Kennwörter vom Client an den Server senden auf einfachem HTTP könnte es sonst jeder lesen, auf dem wireshark / tcpdump installiert ist. Ich denke also über den folgenden Mechanismus nach:

  1. Der HTTP-Server kann als HTTPS-Server eingerichtet werden.
  2. Der Server verfügt auch über eine Datenbank mit Benutzernamen und Kennwörtern (möglicherweise Kennwörter) mit bcrypt gespeichert)
  3. Der Client öffnet die HTTPS-Verbindung, authentifiziert den Server (daher ist ein Serverzertifikat erforderlich) und nach dem Austausch des Hauptschlüssels sollte die Verbindung verschlüsselt werden.
  4. Der Client sendet den Benutzernamen / das Kennwort eindeutig an den Server.
  5. Der Server führt bcrypt für das Kennwort aus und vergleicht es mit dem in der Datenbank gespeicherten Kennwort.
    6. ol>

    Gibt es welche Problem mit dieser Art der Konfiguration? Das Passwort sollte sicher sein, da es über eine verschlüsselte Verbindung gesendet wird.

Um die Antworten zu ergänzen, die Sie bereits erhalten haben, würde ich in dieser Art der Einrichtung empfehlen, sich das Anheften von Zertifikaten anzusehen, um MITM-Angriffe abzuschwächen ...
Vielleicht sollten Sie das Passwort haschen, anstatt es zu verschlüsseln (oder zusätzlich dazu).
Auch wenn es sicher ist, wenn Sie https verwenden.Ein Problem, das ich in anderen Fragen gelesen habe, ist, dass der Benutzername und das Passwort in die Serverprotokolle geschrieben werden, wenn sie direkt in den URLs übergeben werden.Es kann gefährlich sein, wenn die Sicherheit der Protokolle beeinträchtigt wird.
Acht antworten:
AJ Henderson
2014-08-04 21:23:04 UTC
view on stackexchange narkive permalink

Ja, dies ist die Standardpraxis. Wenn Sie etwas anderes tun, bietet dies nur einen minimalen zusätzlichen Vorteil (und kann in einigen Fällen die Sicherheit beeinträchtigen). Solange Sie eine gültige SSL-Verbindung zum richtigen Server überprüfen, ist das Kennwort auf dem Kabel geschützt und kann nur vom Server gelesen werden. Sie erhalten nichts, wenn Sie das Kennwort vor dem Senden verschleiern, da der Server dem Client nicht vertrauen kann.

Die Informationen können ohnehin nur verloren gehen, wenn die SSL-Verbindung kompromittiert wurde und wenn die SSL-Verbindung irgendwie kompromittiert wurde. Das "getarnte" Token ist immer noch alles, was für den Zugriff auf das Konto erforderlich ist. Es ist also nicht gut, das Passwort weiter zu schützen. (Es bietet wohl einen leichten Schutz, wenn sie dasselbe Passwort für mehrere Konten verwendet haben, aber wenn sie dies tun, sind sie zunächst nicht besonders sicherheitsbewusst.)

Wie MyFreeWeb hervorhob, Es gibt auch einige ausgefeilte Systeme, die eine Challenge-Antwort verwenden können, um sicherzustellen, dass das Kennwort vom Client gehalten wird, aber diese sind wirklich ausgefeilt und werden überhaupt nicht häufig verwendet. Sie bieten auch noch nicht viele zusätzliche Vorteile, da sie das Kennwort nur vor einer Gefährdung auf einem aktiv gehackten Server schützen.

@AJHenderson +1, wenn der Client den Hash sendet, wäre definitiv schlecht, da der Zweck des Authentifizierungsprotokolls darin besteht, sicherzustellen, dass der Besucher das richtige * Passwort * kennt, nicht das richtige Passwort * Hash *. Wenn eine böswillige Partei den Hash erhalten könnte (gestohlene Passwortdatenbank, Mann in der Mitte, was auch immer) und das System sich darauf verlassen würde, dass der Besucher den Hash anstelle des Passworts sendet, wäre jede Vorstellung von echter Sicherheit aus dem Fenster.
Es hat manchmal Vorteile, auf dem Client zu hashen und dann auf dem Server etwas mehr zu hashen. Dies kann dazu beitragen, dass das Kennwort in Klartextprotokollen auf dem Client, Server und im Netzwerk verschleiert wird.
@Craig Es ist vollkommen in Ordnung, den Client den teuren gesalzenen Hash berechnen zu lassen, solange Sie vor dem Speichern einen billigen ungesalzenen Hash auf den Server anwenden (oder eine andere Art von Einwegfunktion wie die modulare Exponentiation).
@AndyBoura - Wenn Sie das System so gestalten, dass Sie clientseitiges Hashing unterstützen, haben Sie die Kontrolle über das Netzwerk- und Serververhalten für Teile, die Zugriff auf den Klartext haben. Es stimmt, Sie werden nicht durch Hashing auf dem Client geschädigt (außer durch verlorene Zeit), nur solange Sie keinen wesentlichen Einfluss auf die Hashing-Menge auf dem Server haben.
@CodesInChaos - Ich würde nur dafür sorgen, dass es etwas weniger schlimm ist. Selbst wenn ein komplexer Hash verwendet wird, um eine "längere" Eingabe zu machen, ist dies nur eine Schlüsselerweiterung, und ein Angreifer kann sehr leicht viele billige Hashes erstellen. In der Praxis spielt es möglicherweise keine Rolle, ob die clientseitige Hash-Ausgabe lang ist und in beiden Hashs keine Schwachstellen vorhanden sind, die die Erweiterung von einfachen Werten einschränken. Es ist auch wichtig zu beachten, dass Sie in einem solchen Fall sowohl die clientseitigen als auch die serverseitigen Hashes salzen müssen. Ich bin immer noch ein bisschen zweifelhaft in Bezug auf die Kosten und den Nutzen.
@AJHenderson Clientseitiges Hashing bietet mehrere Vorteile: 1) Längeres Zeitlimit, da der Client nicht viele Anmeldungen gleichzeitig verarbeiten muss. 2) Vermeidet DoS, da der Server keinen teuren Hash berechnen muss. 3) Der Server lernt das Passwort nicht. | Der Hauptnachteil ist, dass Clients häufig eine langsamere CPU als der Server haben. | Ich verstehe nicht, warum der serverseitige Hash ein Salt verwenden sollte, wenn der clientseitige Hash bereits eines verwendet.
@CodesInChaos - Weil nichts clientseitig vertraut wird. Ein Angreifer kann den gesamten langsamen Prozess überspringen, indem er den Client vollständig umgeht. Sie müssen sicherstellen, dass Sie keine Regenbogentabelle mit billigen, schnellen Hashwerten erstellen können. Es ist nicht machbar, wenn Sie jeden salzen und vorausgesetzt, der Zwischen-Hash ist lang genug. Andernfalls erstellen Sie einfach eine Regenbogentabelle mit Hash-Werten, die mit einer sehr, SEHR schnellen Rate generiert werden können, wenn sie billig sind.
@AJHenderson Offensichtlich muss der Zwischenwert groß genug sein, um eine Aufzählung zu vermeiden, mindestens 128 Bit, vorzugsweise 160-256, um Angriffe mit mehreren Zielen zu berücksichtigen. Da die Verwendung eines richtigen Hashs wie SHA-256 so einfach ist, sehe ich keinen Grund, unnötige Komplikationen wie ein Salz hinzuzufügen.
@CodesInChaos - Ja, wenn Sie einen ausreichend großen Zwischen-Hash verwenden und sicher sind, dass er sich gut verhält (wirklich zufällige Verteilung), sollte dies in Ordnung sein, solange der anfängliche Hash gesalzen ist und lange genug dauert, um die Verwendung einer vollständigen Aufzählung des zu erzwingen Zwischen-Hash-Raum (oder zumindest nahezu voll)
Stellen Sie sicher, dass Sie über POST und nicht über GET senden :-) GETs sind im klaren.
Wenn es sich um Probleme wie POST oder GET handelt, sollten Sie außerdem die Vorwärtsgeheimnis implementieren, damit Ihre sicheren Sitzungen später nicht von jemandem entschlüsselt werden können, der den privaten Schlüssel Ihres Servers erhält.
Kennwort- / Hash-Konversation [Fortsetzung im Chat] (http://chat.stackexchange.com/rooms/16227/discussion-between-aj-henderson-and-craig).
Insbesondere bei einer clientseitigen Anwendung würde ich wahrscheinlich immer noch eine Hash-Version des Kennworts über die Leitung verwenden, da ich es für möglich halte, dass aus irgendeinem Grund eine unverschlüsselte Verbindung hergestellt werden könnte (durch einen Programmierfehler, fehlerhaftes App-Update) , falsche Einstellungen der zugrunde liegenden Bibliothek, so dass eine Umleitung zu einem http-Server akzeptiert wird ...) * Alle für den Fall des gleichen Passworts für mehrere Konten, außerdem sind Sie vor jemandem geschützt, der Zugriff auf Ihren Server hat, um Klartext-Passwörter zu erhalten ...
@Falco - und ein Programmierfehler können dazu führen, dass der Hash ebenfalls unsicher ist. Sie müssen das Verhalten von sicherheitsrelevantem Code überprüfen und nicht nur hoffen, dass es richtig funktioniert. Je komplexer Sie einem System hinzufügen, desto schwieriger ist die Validierung und desto wahrscheinlicher tritt ein Fehler oder eine Sicherheitsanfälligkeit auf. Sie müssen beurteilen, wie viel Nutzen Sie für einen bestimmten zusätzlichen Aufwand erhalten. Letztendlich ist das zusätzliche Fehlerrisiko bei der Implementierung den minimalen Gewinn an zusätzlichem Widerstand nicht wert.
@AJHenderson: Sie geben an: "Ja, dies ist die Standardpraxis." Haben Sie eine Referenz, um diese Aussage zu machen? Ich suche nach Best Practices von einer bekannten Autoritätsquelle, wie vielleicht NIST oder sogar einem O'Reilly-Buch.
Gewährleistet diese "Standardpraxis" auch vollständige Sicherheit, wenn wir im Rahmen unserer Kommunikation "goto fail" oder "HTTPS-Freak" haben? Und wenn zwei SSL-Versionen defekt sind, sind wir sicher, dass die aktuelle Version sicher ist?
@h22 Ich nehme an, wir können nicht hundertprozentig sicher sein, aber wenn dies nicht der Fall ist, sind Passwörter das geringste unserer Anliegen. Außerdem sind wir uns in Bezug auf TLS viel sicherer als in Bezug auf ein selbst entwickeltes clientseitiges Hashing oder Verschlüsselungssetup. Wenn Sie sagen, dass dies unter die Praxis "Rollen Sie nicht Ihre eigenen" fällt.
"Eigenverschlüsselung" klingt zwar nicht gut, aber es gibt auch Standard-Kryptografie-Bibliotheken.
@h22 Die hausgemachte Verschlüsselung gilt nicht nur für Algorithmen oder Bibliotheken, sondern auch für Protokolle. Es gibt viele Möglichkeiten, wie ein Passwortaustausch zusammenbrechen kann. Wenn Sie beispielsweise eine clientseitige Verschlüsselung durchgeführt haben, ohne dass jedes Mal eine andere Herausforderung an den Client gesendet wurde, hat die Verschlüsselung überhaupt nichts zu tun, da sie nur die Mittel zum Generieren eines Kennworts verdeckt, das nur durch ssl geschützt ist (seit dem Der vom Client generierte Wert ist immer der gleiche, was ihn zum "echten" Passwort macht.) Es gibt alle möglichen Fallstricke, sowohl offensichtliche als auch nicht offensichtliche.
Es bleibt die Tatsache, dass Protokolle wie ssl weitaus mehr getestet und analysiert werden als alles, was Sie als Ihre eigene Suite erstellen. Wenn Ihre eigenen Sachen über andere Sachen gelegt werden, kann dies zu Seitenkanalangriffen führen. Die Tatsache, dass es so lange gedauert hat, bis Probleme in ssl entdeckt wurden, sollte ein Vertrauensbildner sein. Selbst mit einer Menge Augen sind Schwachstellen schwer zu finden. Außerdem bedeutet dies, dass Probleme von Forschern gefunden und angekündigt werden, die sich mit solchen Dingen befassen.
Ist das noch eine gute Antwort?Ich würde nicht erwarten;Einige Orte installieren zusätzliche Zertifikate und führen beispielsweise HTTPS MitM-Angriffe durch.Ich habe an anderer Stelle einige Diskussionen darüber gesehen, was ein besseres System sein sollte, aber nicht genug, um zu beurteilen, ob es von Menschen war, die Sicherheit tatsächlich verstanden haben.
@DanielH Wenn jemand Zugriff auf die Installation von Stammzertifikaten hat, hat er Zugriff auf das Schlüsselprotokoll.Wenn Sie einem Computer nicht vertrauen, geben Sie Ihr Passwort nicht ein.Der Schutz vor kompromittierten Clients erfordert einen völlig anderen Mechanismus, z. B. Smartcards, die sich authentifizieren können, ohne das Geheimnis preiszugeben. Dies erfordert jedoch zusätzliche Hardware für den Client und ist für die meisten Anwendungen nicht praktikabel.
@AJHenderson Es gibt Möglichkeiten, einen Client dazu zu bringen, ein kompromittiertes Zertifikat zu erhalten, mit dem Sie keinen Keylogger installieren können. Ich ziehe diesen Teil meines Widerspruchs jedoch trotzdem zurück, da Sie damit auch den Anmeldebildschirm ändern können und nur wenige Clients dies überprüfendas jedes Mal für Änderungen.Dies würde nur vor teilweisen, aber nicht vollständigen Serverkompromissen (die je nach Architektur und Unternehmenssicherheitspraktiken plausibel sein können oder nicht) oder Angriffen schützen, die passives Evesdropping, aber keine aktive Interferenz mit HTTPS ermöglichten (wahrscheinlich vorhanden, aber sehr selten)).
@AJHenderson Obwohl mich das meiste davon überzeugt hat, dass mehrere Unternehmen, denen ich vertraue, überdurchschnittlich sicher zu sein, das eingegebene Passwort scheinbar unverschlüsselt über HTTPS hinaus senden.Ich bin überrascht;Ich hätte erwartet, dass eine Methode, die dies nicht tut, zum Standard für die vielleicht kleine Verbesserung geworden ist, die sie bietet, insbesondere angesichts der Tatsache, dass der Kampf gegen die Wiederverwendung von Passwörtern ein verlorener Kampf ist.
@DanielH Wie würden Sie ein vertrauenswürdiges Stammzertifikat installieren, ohne dass der Administrator mindestens für kurze Zeit Zugriff auf die Box hat?Wenn Sie über diese Zugriffsebene verfügen, können Sie auch auf andere Weise schändlich sein, wenn Sie dies möchten.Und wie Sie zu Recht betont haben, bedeutet die MitM-Fähigkeit, dass jeder clientseitige Mechanismus besiegt werden kann, wenn er nicht in eine App und nicht in eine Website integriert ist.
@AJHenderson Sie können ein Zertifikat kompromittieren, entweder ohne es zu bemerken oder den Angriff auszuführen, bevor es widerrufen wird.Sie können Kunden ansprechen, die noch über das Zertifikat [Superfish] (https://en.wikipedia.org/wiki/Superfish) oder ein gleichwertiges Zertifikat eines der zahlreichen anderen Dienstprogramme verfügen, die ähnliche Aufgaben ausführen.Sie könnten eine inhaltsfilternde Middlebox oder Middleware verkaufen, die einen gültigen Grund für MitMing hätte, und dann entweder das Zertifikat nicht schützen oder es für schändliche Zwecke verwenden.Sie könnten eine Zertifizierungsstelle dazu verleiten, Ihnen ein Zertifikat für eine Site auszustellen, die Sie nur teilweise kontrollieren.Usw.
@DanielH ok, das ist ein völlig anderer Kontext als Ihr erster Kommentar zu Orten, an denen Zertifikate für MitM-Proxy installiert werden.Die soeben beschriebenen Fälle sind weitaus seltener und die meisten haben entweder Abhilfemaßnahmen oder sind sehr seltene Fälle oder gelten nur für Systeme, die ansonsten anfällig für Angriffe auf den Client selbst sind.
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (https://chat.stackexchange.com/rooms/90709/discussion-between-daniel-h-and-aj-henderson).
Neil McGuigan
2014-08-04 22:26:15 UTC
view on stackexchange narkive permalink

Nicht unbedingt.

Sie müssen außerdem Folgendes sicherstellen:

  1. Ihre Site ist gegen Fälschungen von standortübergreifenden Anforderungen geschützt. Verwenden Sie das Synchronisieren des Token-Musters.

  2. Ihre Site ist vor Angriffen zur Sitzungsfixierung geschützt. Ändern Sie die Sitzungs-ID beim Anmelden.

  3. Wenn Sie Sitzungscookies verwenden, ist Ihre gesamte Site HTTPS, nicht nur die Anmelde-URL, und Ihr Sitzungscookie ist nur als sicher und nur als http gekennzeichnet (kein JavaScript-Zugriff). Der Browser sendet ein Sitzungscookie unverschlüsselt, wenn der Benutzer http: // yoursecuresite eingibt (in derselben Browsersitzung).

  4. Sie verwenden ein aktuelles Protokoll. SSL 1 und 2 sind defekt und 3 möglicherweise auch. Versuchen Sie, TLS 1.1 oder 1.2 zu verwenden.

  5. Sie verwenden eine starke Verschlüsselung.

  6. Sie verwenden keine HTTP-Komprimierung (GZip) oder TLS-Komprimierung. Wenn auf Ihrer Website Benutzereingaben angezeigt werden (wie bei einer Sucheingabe), kann ich Ihre CSRF-Token und Ihre Bankkontonummer ermitteln, wenn Sie die Komprimierung verwenden.

  7. Ihr Server tut dies nicht Ermöglichen Sie eine unsichere Neuaushandlung des Clients.

  8. Sie verwenden einen 2048-Bit-RSA-Schlüssel (oder das Äquivalent für einen EC-Schlüssel) und niemand kennt Ihren privaten Schlüssel.

  9. Sie verwenden HSTS, sodass der Browser direkt zu https wechselt, selbst wenn der Benutzer http

  10. eingibt Ihre historische Kommunikation ist auch dann sicher, wenn Ihr privater Schlüssel durchgesickert ist.

    11. ol>
Wenn die gesamte Site https ist, muss das Cookie weiterhin als sicher markiert werden? Sie würden aufgrund der TLS-Schicht immer noch "kostenlos" verschlüsselt, oder?
Können Sie Punkt 6 erklären? Warum würde die Komprimierung die Verbindung weniger sicher machen?
Ja, Sie möchten immer noch ein sicheres Cookie, nur http, da es immer noch gestohlen werden kann, wenn nicht. Siehe xss. Durch die Komprimierung wird die Verschlüsselung beendet. Siehe BEAST- und CRIME-Angriffe.
@Emiliano: Auch wenn Ihre Site nur HTTPS ist, kann ein Angreifer einen Mann im mittleren Angriff einrichten und einen gefälschten Server einrichten, der einfaches HTTP verwendet und so genanntes SSL-Stripping ausführt. Der Browser sendet das Cookie des Benutzers an den gefälschten Server. Um dies zu vermeiden, benötigen Sie Secure Cookie- und HSTS-Richtlinien.
9. Setzen Sie PFS ein, um das Risiko zu verringern, dass jemand (zum Beispiel eine böse Regierung) Ihre privaten Schlüssel stiehlt.
8. Das ist der springende Punkt bei HTTPS ... 1. Nicht relevant für mobile Clients. Es ist unwahrscheinlich, dass Cookies und Sitzungen vorhanden sind. 6. Was ist los mit Kompressionen? - Normalerweise erfordert ein Server, der JSON-Dienste bereitstellt, die Authentifizierung aller Anforderungen.
@njzk 1. URLs können weiterhin in einem Browser durchsucht werden, daher ist dies relevant. 3. Hängt von seiner Implementierung ab, die sowieso erwähnenswert ist. 6. Siehe BEAST- und CRIME-Angriffe.
@NeilMcGuigan: Ist es möglich, die Passwortlänge zu erraten, wenn sie eindeutig über HTTPS gesendet wird?
@user2284570 "Im Klartext" und über "HTTPS" sind Gegensätze.
@NeilMcGuigan: Ich wollte damit meinen, dass ich sie nicht mit Hash oder zusätzlicher Verschlüsselung übertrage.
mricon
2014-08-04 19:07:11 UTC
view on stackexchange narkive permalink

Solange Sie die Gültigkeit des Zertifikats überprüfen, ist dies vollkommen in Ordnung und wird ständig durchgeführt.

kasperd
2014-08-04 19:15:11 UTC
view on stackexchange narkive permalink

Die meisten Websites, die normalerweise als sicher eingestuft werden, verfolgen weitgehend den von Ihnen beschriebenen Ansatz. Oder anders ausgedrückt, Sie haben einfach den etablierten Industriestandard beschrieben.

Ich würde davon abraten, einen Ansatz zu verwenden, der weniger sicher ist als der von Ihnen erwähnte. (Ob bcrypt besser oder schlechter ist als andere gesalzene Hashes, ist eine Diskussion, auf die ich nicht eingehen werde. Verwenden Sie nur nichts Schwächeres als einen gesalzenen Hash.)

Wenn Sie sich als haben möchten Sicherheit über den etablierten Industriestandards, es stehen andere Optionen zur Verfügung. In allen Bereichen Ihrer Anwendung ist jedoch ein enormer Aufwand erforderlich, damit sich die Anwendung lohnt.

Zu den sichereren Bereichen der Kennwortüberprüfung gehören:

  • Schutz des Servers vor DoS Angriffe durch Auslagern des größten Teils der Berechnung während der Validierung auf den Client. Das heißt, Iterieren Sie das Hashing nicht auf der Serverseite, sondern nur auf der Clientseite und führen Sie den letzten Hashing-Schritt auf dem Server aus.
  • Schutz vor Kennwortlecks, wenn der Server durch Ableiten eines öffentlichen Schlüsselpaars aus dem Kennwort gefährdet wird und niemals Lassen Sie den Server das Passwort oder den geheimen Schlüssel sehen.
Andy Boura
2014-08-05 12:46:40 UTC
view on stackexchange narkive permalink

Wie andere gesagt haben, ist dies ein Standardansatz.

Für eine persönliche Website würde ich sie jedoch nicht unbedingt befolgen ... Ich würde ein Verbund-Login von Facebook, Google oder ähnlichem verwenden, da ich auf diese Weise keine Probleme mit dem Lebenszyklus eines Kontos behandeln muss kann Google 2-Faktor-Authentifizierung usw. verwenden.

Es erspart Ihnen, einige Formulare und Felder in Ihrer Datenbank zu haben, was bedeutet, dass weniger Fehler auftreten.

Natürlich müssten Sie weiterhin die Benutzer autorisieren, auf die Sie zugreifen möchten, entweder über eine Funktion des Authentifizierungsanbieters, z. B. eine Facebook-Gruppe, eine Art Whitelist zulässiger Benutzer oder eine Genehmigungsarbeit fließen von Ihrem Konto ab. Manchmal geschieht dies, indem Benutzer eingeladen werden: Geben Sie ihnen eine URL mit einem eindeutigen Sicherheitscode und das System, das diese bei der ersten Anmeldung mit einem Auth-Anbieter verknüpft. Alternativ können Benutzer automatisch authentifizieren und den Zugriff anfordern. Dies versetzt sie in einen "ausstehenden" Zustand. Anschließend stellen Sie eine Schnittstelle bereit, über die Sie sich anmelden und genehmigen können.

Bit Ich möchte nicht, dass jeder beitritt: Ich möchte nur bestimmten Benutzern (z. B. meinen Freunden) die Erlaubnis geben.
Ja, Sie benötigen eine Liste der E-Mails, die noch zulässig sind. Sie überprüfen dies dann anhand der Verbund-ID.
Ah, damit ich eine weiße Liste implementieren kann, meinst du? Das ist interessant, ich werde mich auch mit diesem Ansatz befassen.
Korrekt. Sie könnten möglicherweise sogar Ihre Facebook-Freundesliste oder eine Gruppe für Auth verwenden, aber ich kenne keine Details darüber, wie Sie dies tun würden.
Weitere Autorisierungsinformationen zur Beantwortung hinzugefügt.
200_success
2014-08-05 21:33:55 UTC
view on stackexchange narkive permalink

HTTPS macht die Authentifizierungsanforderung während der Übertragung nicht mehr verfügbar. Um es jedoch "sicher" zu machen, müssen Sie noch andere Dinge richtig machen. Beispiel:

  • Die gesamte Anmeldeseite und alle ihre Abhängigkeiten sollten auch über HTTPS bereitgestellt worden sein, obwohl dann kein Kennwort übertragen wird. Wenn ein Angreifer einen Teil davon (z. B. JavaScript, CSS oder Bildressourcen) über unverschlüsseltes HTTP bereitstellt, kann das Erscheinungsbild oder Verhalten der Anmeldeseite durch einen Man-in-the-Middle-Angriff geändert werden.

    Browser behandeln gemischte HTTP / HTTPS-Inhalte mit unterschiedlichem Verdacht. Einige unterdrücken lediglich das "Schlosssymbol" in der Benutzeroberfläche. Weitere paranoide Browser lehnen es ab, die unverschlüsselten abhängigen Ressourcen insgesamt zu laden. In jedem Fall sollten Sie die gesamte Anmeldeseite über HTTPS bereitstellen.

  • Senden Sie das Kennwort nicht in der Abfragezeichenfolge eines HTTP-GET. Webserver sind normalerweise so konfiguriert, dass sie die URLs von Anforderungen protokollieren, einschließlich des Abfragezeichenfolgenabschnitts der URL. Geben Sie das Passwort stattdessen in einen POST-Text ein. (Sie können auch die HTTP-Authentifizierung RFC 2617 verwenden, die Unterstützung für die Abmeldung ist jedoch unvollständig.)

Ah ja, ich erinnere mich immer daran, dass GET eine schlechte Idee ist, da es auf dem Client-System sichtbar ist und möglicherweise im Client-Verlauf landet. Vergessen Sie jedoch, dass Server möglicherweise auch die Parameter protokollieren.
h22
2015-10-27 17:39:55 UTC
view on stackexchange narkive permalink

Wikipedia mit der vollständigen Seite historischer HTTPS-Sicherheitsprobleme.

HTTPS-Sicherheitslücken sind bereits aufgetreten (warum sind die beiden älteren Versionen defekt? Und was ist "goto fail")? Was ist 'https freak'?).

Ich schlage nicht vor, HTTPS loszuwerden, aber wenn Sie etwas Zusätzliches darunter legen, schadet dies in den meisten Fällen nicht. Wenn Sie bereits ein unverschlüsseltes Passwort über diesen Kanal senden können, können Sie wahrscheinlich alles senden, was Sie möchten.

D.H.
2015-10-28 18:16:09 UTC
view on stackexchange narkive permalink

Die Verwendung von HTTPS verhindert nicht, dass versucht wird, das Kennwort brutal zu erzwingen. Wenn Sie also Ihre eigene Benutzerkontoverwaltung durchführen, sollten Sie Funktionen wie minimale Kennwortkomplexität und Kontosperrung / maximale Anzahl von Wiederholungsversuchen berücksichtigen, die solche Versuche verhindern würden.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...