mikrocontroller.net

Forum: Offtopic sichere Passwortabfrage ohneJavascript


Autor: H. D. (c3po)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. B. (funky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
äh...ja mit php zum Beispiel.  Beispiele gibts bei google zu hauf

und was meinst du mit "sicher"?

Autor: H. D. (c3po)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit sicher meine ich:

ohne das PWD im klartext im Internet zu verschicken !

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H. D. schrieb:
> mit sicher meine ich:
>
> ohne das PWD im klartext im Internet zu verschicken !

HTTPS/SSL. Muss dein Server aber anbieten.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du suchst SSL/TLS.

Andreas

Autor: H. D. (c3po)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok

aber ohne SSL gehts nicht sehe ich das richtig ?

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H. D. schrieb:
> Ok
>
> aber ohne SSL gehts nicht sehe ich das richtig ?

Ohne SSL geht dein PW im Klartext über die Leitung, ja.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.htaccess

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: El Jefe (bastihh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: K. Laus (trollen) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: El Jefe (bastihh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
K. Laus,

lies dir bitte meinen Beitrag ein paar male durch...

Danke...

Autor: K. Laus (trollen) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.htaccess über SSL/TLS - und Alles wird gut!

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-Au...

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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fazit:
ohne verschlüsselten Übertragungskanal keine Sicherheit.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.