Hallo einfache Frage: kann man eine sichere Passwortabfrage machen ohne Javascript ? wenn ja hat wer nen Link wo ich ein Beispiel sehen kann ? Danke lg
äh...ja mit php zum Beispiel. Beispiele gibts bei google zu hauf und was meinst du mit "sicher"?
mit sicher meine ich: ohne das PWD im klartext im Internet zu verschicken !
H. D. schrieb: > mit sicher meine ich: > > ohne das PWD im klartext im Internet zu verschicken ! HTTPS/SSL. Muss dein Server aber anbieten.
Du suchst SSL/TLS. Andreas
Ok aber ohne SSL gehts nicht sehe ich das richtig ?
H. D. schrieb: > Ok > > aber ohne SSL gehts nicht sehe ich das richtig ? Ohne SSL geht dein PW im Klartext über die Leitung, ja.
H. D. schrieb: > kann man eine sichere Passwortabfrage machen ohne Javascript ? Gegenfrage: Gibt es eine sichere Passwortabfrage die auf JS basiert? Ich behaupte mal nicht. Reinhard S. schrieb: > Ohne SSL geht dein PW im Klartext über die Leitung, ja. Man muß ja nicht ein PW versenden da gibt es genug andere Möglichkeiten. Sicherlich ist SSL erstmal am einfachsten da von nahezu jedem Server/Client unterstützt.
.htaccess
Läubi .. schrieb: > Gegenfrage: Gibt es eine sichere Passwortabfrage die auf JS basiert? Ich > behaupte mal nicht. Klar gibt es das, zumindest gegen passive Angreifer. Mit Javascript kannst du ohne weiteres ein Challenge-Response-Verfahren implementieren. Eine Möglichkeit ohne SSL und ohne JS währe ansonsten noch, HTTP mit Digest-Authentifizierung zu machen, da wird auch kein Passwort im Klartext übertragen. Nicht schützen können dich beide Verfahren allerdings gegen aktive Angreifer (Man In The Middle), da keine Verifikation der Gegenseite möglich ist. Immerhin verrätst du dem Angreifer in diesem Fall aber immer noch nicht dein Klartextpasswort, du ermöglichst ihm "nur" Zugriff auf die Zielseite. Andreas
was man noch amchen könnte, um das PW nicht offen durch die Leitung zu schicken. (Allerdings wohl mit JS): Passwort auf dem Server in der DB md5 kodiert hinterlegen. Das Passwortfeld bzw. sein Inhalt dann von dem Client md5 kodieren lassen und übertragen.
Basti B. schrieb: > Passwort auf dem Server in der DB md5 kodiert hinterlegen. Das ist ja wohl das mindeste was man grundsätzlich immer machen sollte.
K. Laus, lies dir bitte meinen Beitrag ein paar male durch... Danke...
Den habe ich schon gelesen, aber es hört sich so an, als müsse man extra darauf hinweisen, dass man Passwörter verschlüsselt speichert. Sowas muss Standard sein.
.htaccess über SSL/TLS - und Alles wird gut!
Basti B. schrieb: > Passwort auf dem Server in der DB md5 kodiert hinterlegen. > > Das Passwortfeld bzw. sein Inhalt dann von dem Client md5 kodieren > lassen und übertragen. Ähm, nein. Damit wird dann eben der MD5-Hash selbst zum "Passwort", ein Angreifer muss nur einmal den Hash mitlesen und sendet den dann in Zukunft selbst an den Server. Wie schon erwähnt, wenn man den Übertragungsweg aus welchem Grund auch immer nicht verschlüsseln kann, dann ist Challenge-Response-Authentifizierung ein Mittel der Wahl. http://de.wikipedia.org/wiki/Challenge-Response-Authentifizierung Damit gibt man dann einem Angreifer höchstens Zugriff auf die aktuelle Session (ausser er kann dann hingehen und z.B. in der Anwendung das Passwort auf ein eigenes ändern). Andreas
Fazit: ohne verschlüsselten Übertragungskanal keine Sicherheit.
K. Laus schrieb: > darauf hinweisen, dass man Passwörter verschlüsselt speichert. Erstens ist MD5 keine Verschlüsselung und zweitens wird so die Sicherheit nicht erhöht. Einziger "Sinn" hinter dem ganzen ist, das du nicht das PW des users im Klartest in der DB hinterlegst, und trotzdem prüfen kannst ob derjenige das gleiche PW angab aus dem die MD5 summe entstand (mit einer gewissen Wahrscheinlichkeit). Andreas Ferber schrieb: > Klar gibt es das, zumindest gegen passive Angreifer. Mit Javascript > kannst du ohne weiteres ein Challenge-Response-Verfahren implementieren. DIe basiert dann aber auf irgenwas Serverseitigen und hat nix mit JS zu tun, den was machst du den wenn du (wie auch immer) feststellst, dass die Authentifizierung erfolgreich war? Mit JS kannst du maximal ein Cookie setzen und die Seite neu laden, bist dann aber immer noch darauf angewiesen das der Server das richtig zuordnet und dich in den zu schützenden Bereich "einläßt".
Läubi .. schrieb: > DIe basiert dann aber auf irgenwas Serverseitigen und hat nix mit JS zu > tun Wie soll denn auf dem Client der Response berechnet werden, wenn nicht mit JS? > Mit JS kannst du maximal ein > Cookie setzen und die Seite neu laden, bist dann aber immer noch darauf > angewiesen das der Server das richtig zuordnet und dich in den zu > schützenden Bereich "einläßt". Nein Läubi, da hast du ziemlich falsche Vorstellungen von dem, was JS kann. Für Cookies braucht man clienseitig kein JS.
Uhu Uhuhu schrieb: > Wie soll denn auf dem Client der Response berechnet werden, wenn nicht > mit JS? Mit dem Taschenrechner, Java, Systemdienstent, ActiveX es gibt so viele Möglichkeiten. Uhu Uhuhu schrieb: > Nein Läubi, da hast du ziemlich falsche Vorstellungen von dem, > was JS kann. Woher willst du den wissen was für Vorstellungen ich von JS habe? Ich hab zufällig Anfang des Jahres sehr intensiv mit JS gearbeitet. Uhu Uhuhu schrieb: > Für Cookies braucht man clienseitig kein JS Hab ich auch nie behauptet. Die Frage bleibt einfach, setze folgende Liste fort: - Server liefert "Challenge" - Client liefert "Response" - Server meldet "Ok" - Client .... Wie soll deiner Meinung nach nun der Client (nur auf JS basierend) ohne Zutun des Servers auf eine geschützte Resource zugreifen können? Klar kann der Server anstelle von "ok" einfach die fragliche Datei als XML/JSON/... zurückliefern, aber sobald du die Seite neu lädst ist das futsch, und meist möchte man eben doch das der User "eingeloggt" bleibt, und dafür braucht es immer die Mitarbeit des Servers. Und genaugenommen ist ein CR auch schon vom Server abhängig also auch nicht JS "basiert", sondern auf Serverseite läuft auch wieder ein entsprechendes Gegenstück.
Läubi .. schrieb: > Mit dem Taschenrechner, Java, Systemdienstent, ActiveX es gibt so viele > Möglichkeiten. Typische Läubi-Antwort. Das gibt dann die super-nutzerfreudlichen Webapps, für die man entweder irgendwelche Plugins im Browser braucht, die dann womöglich auch noch für jede Umgebung eine eigene Version brauchen - wie zu Zeiten des Browserkrieges. Aber das Leben ist hart und warum soll es hier anders sein... > Wie soll deiner Meinung nach nun der Client (nur auf JS basierend) ohne > Zutun des Servers auf eine geschützte Resource zugreifen können? Es wird ganz normal über SSL/TLS eine Verschlüsselte Verbindung aufgebaut. Damit weiß der Client, daß er es mit dem richtigen Server zu tun hat - vorausgesetzt, er verfügt über ein verläßliches Zertifikat. Der Server weiß noch nicht, mit wem er es zu tun hat. Das Challenge/Response-Verfahren benutzt nun der Server, um den Client zu zu authentifizieren. Anschließend gehts über normal SSL/TLS weiter - wie man das so zu machen pflegt. > Wie soll deiner Meinung nach nun der Client (nur auf JS basierend) ohne > Zutun des Servers auf eine geschützte Resource zugreifen können? Ohne Server geht sowieso nichts - ob mit, oder ohne CR. Der Vorteil von JS ist, daß es auf allen aktuellen Browsern verfügbar ist.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.