Ist SSL sicher genug für die Verwendung sensibler Daten (wie Passwort) in der Abfragezeichenfolge? Gibt es zusätzliche Optionen zur Implementierung?Wie sicher ist das Versenden sensibler Daten über https?
Antwort
SSL bietet sichere, Transport-Level-Sicherheit. Niemand zwischen Client und Server sollte in der Lage sein, die Informationen zu lesen.
Aber Sie sollten Ihre Meinung ändern über sensible Daten in der Abfragezeichenfolgeflag zu schreiben. Es wird in der Browserhistorie angezeigt und ist in der Adressleiste des Browsers und in den Protokollen auf dem Server sichtbar. Siehe diesen Artikel: How Secure Are Query Strings Over HTTPS?
Wenn Abfragezeichenfolgen ist Ihre einzige Option (ich bezweifle es), hier ist ein interessanter Artikel about securing query strings.
sollten Sie niemals kritisch sensitive mit Abfragezeichenfolgen senden!
Ja, es ist sicher genug. Zwar stimme ich zu, dass es normalerweise keine gute Idee ist, Dinge wie diese in einer Abfragezeichenfolge zu haben, aber es ist in Ordnung, wenn es keine Abfragezeichenfolge ist, die in der Adressleiste angezeigt wird. Wenn es in der Adressleiste angezeigt wird, verlieren Sie aus offensichtlichen Gründen eine Sicherheitsstufe (vorbeilaufende Personen usw.)
Sollte niemand Hash-Passwörter senden? - Vergiss es, wenn ich falsch liege.
SSL ist so ziemlich die höchste Sicherheit, die Sie bekommen können.
Wenn Sie Web mit https sprechen öffnen kann, dann würden Sie einige JavaScript mokeying über zu tun haben. So gut wie jeder Hack, der das SSL kaputt machte, würde auch den Austausch des JavaScript ermöglichen (wenn auch nicht automatisch). –
Sensible Daten in der Abfragezeichenfolge ist eine schlechte Idee, zufällige Passanten können die Abfragezeichenfolge sehen und es wäre eine Versuchung zu Lesezeichen, die wirklich nicht sicher ist.
SSL ist ziemlich sicher, wenn Sie Internet-Banking betreiben und Sie darauf vertrauen, dann ist SSL auch für Sie gut genug.
einverstanden mit der SSL-Sicherheit * ish und die Abfragezeichenfolgeflag Ausgabe
erinnern ist, dass es Einschränkungen auf SSL sind -
sicherzustellen, dass die cert Wurzel zertifiziert ist.
einige Windows 2000-Maschinen benötigen ein sp für die 128-Bit-ssl angewendet haben, zu arbeiten, wenn es nicht dort dann geht es auf 40bit oder Doenst Last (wenn ich mich recht erinnere)
Einige Software-Firewalls wie ISA - wo du die sichere Seite und das Zertifikat darin veröffentlichst - handle wie ein Mann in der Mitte.
Sichere auf ISA dann Secure to LAN. aber der große Faktor hier ist das "dann" als ISA wird Protokollieren dann Protokollierung ist ein Problem, wie das Passwort auf der Abfrage Zeichenfolge und Post zu sehen - was bedeutet, dass jeder (Admin) sehen kann ...
So suchen sichere Hashing-Algorithmen in Ihrer Sprache, um das Passwort einfach zu hashen.
Es gibt keine "sicher genug", Sicherheit ist keine statische Sache mit einer Bool-Eigenschaft, die entweder falsch oder wahr ist.
SSL ist gut, aber es hängt davon ab, wie sicher der private Schlüssel auf der Serverseite ist, wie viele Bits der Schlüssel hat, den verwendeten Algorithmus, wie vertrauenswürdig die verwendeten Zertifikate sind, etc ....
Wenn Sie jedoch mindestens SSL verwenden, werden alle Ihre übertragenen Daten verschlüsselt (mit Ausnahme der Ziel-IP, da sie zum Routen Ihres Pakets verwendet wird).
Ein weiterer Punkt, den Sie beachten sollten, ist - wenn Sie Ihren Passwort-Abfrage-String von Hand in Ihrem Browser eingeben, kann es in Ihrem lokalen Browser-Cache (in einer vollständig unverschlüsselten lokalen Datei) enden. Verwenden Sie also besser POST und nicht GET-Transfer-Mechaniken.
Wenn Sie wirklich an Sicherheit interessiert sind, empfehle ich mehr Forschung zu diesem Thema, weil meistens nicht der Algorithmus der schwächste Punkt in der Sicherheit ist.
SSL ist sicher, aber denken Sie daran, dass jede Verschlüsselung unterbrochen werden kann, wenn genügend Zeit und Ressourcen zur Verfügung stehen. Da Sie nicht wissen, welche Pakete ein Kennwort enthalten und welche nicht, müssen Sie den gesamten verschlüsselten Datenverkehr entschlüsseln, um den richtigen zu finden. Dies ist im allgemeinen Fall unlösbar.
Ein Login-Formular benötigt jedoch eine Eingabe [type = text], um es einzugeben. Es würde Arbeit erfordern, dies zu "entpacken" und die Anfrage in eine HTTP-GET-Anfrage umzuwandeln, die Abfrage-Zeichenfolgen anstelle eines POST mit den Daten in den Formularparametern verwendet. Ich kann mir nicht vorstellen, warum irgendjemand das tun würde. Sobald das Passwort vom Benutzer eingegeben wurde (und der Benutzer authentifiziert wurde), verwenden Sie die Authentifizierung und nicht das Passwort. Wenn Sie das Passwort für den Identitätswechsel behalten möchten, sagen Sie es serverseitig und vorzugsweise in einer sicheren Zeichenfolge. Wenn Sie versuchen, Single-Sign-On (geben Sie meine ID/Passwort einmal für viele Websites), dann verwenden Sie eine Art von zentralen Authentifizierungsdienst (CAS) - OpenID, WindowsLive - oder implementieren Sie Ihre eigenen.
Je weniger ein Kennwort die Leitung kreuzt, desto besser.
Und es gibt immer die Browser-Adressleiste zu berücksichtigen, die argumentieren würde, dass Sie alle sensiblen Daten verschlüsseln und verschlüsseln müssen, die Sie in Abfragezeichenfolgen wie zuvor erwähnt einfügen.
Selbstsignierte Zertifikate sind SSL-Zertifikate, die von Ihnen selbst erstellt und signiert werden. Das bedeutet, dass Sie keine Zertifizierungsstelle (CA) von Drittanbietern benötigen, um Ihr Zertifikat zu signieren, , aber bedeutet, dass Browser standardmäßig eine Warnung ausgeben, da ein selbstsigniertes Zertifikat nicht zuverlässig (Ihr Browser hat) eine Liste der vertrauenswürdigen CAs) überprüfen, dass der Unterzeichner des Zertifikats genau das ist, was das Zertifikat sagt.
Betrachten Sie die Situation, in der Sie ein SSL-Zertifikat "im Namen von" einer bestimmten Redmond-basierten Software-Firma erstellen. Wenn Ihr HTTP-Server dieses Zertifikat, das Sie selbst signiert haben, einem Client vorlegt, warnt der Benutzeragent, dass dieses Zertifikat möglicherweise nicht wirklich dem entspricht, von dem es sagt, dass es ist. Eine Zertifizierungsstelle wird - durch Papierkram, die tatsächliche, tatsächliche Art des toten Baums - die Identität der Partei, die die Unterzeichnung anfordert, überprüfen, daher ist sie vertrauenswürdig.
Hoffe, das hilft.
Also, ich kann dann dieses Zertifikat in meiner vertrauenswürdigen Gruppe hinzufügen. Später sollte es funktionieren, ohne zu fragen, zumindest für mich. :-) Recht? –
Ja. (Oder wenn Sie die Peer-Verifizierung in SSL nicht benötigen, aber dennoch die Sicherheit wünschen, können Sie die Überprüfung in der von Ihnen verwendeten Bibliothek deaktivieren (mindestens cURL unterstützt dies für HTTPS). – AKX
ssl Inspektor ssl Verkehre http://www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf
Nur wenn das Zertifikat auf dem Server installiert wurde Client-Maschinen. Es funktioniert, indem die SSL-Verbindung lokal mit einem eigenen Zertifikat beendet wird und als "Mann in der Mitte" fungiert. Wenn die CA nicht installiert ist, werden auf den Clients SSL-Warnungen angezeigt. – duskwuff
Und möglicherweise in Logs auf dem Webserver Ende der Dinge. –
Tom: Hinzugefügt diesen Vorschlag, danke! – splattne
POST anstelle von GET sollte funktionieren? –