Sicheres Loginsystem?

[Matthias Reitinger]

Hallo,

Damit wird Client-seitig gehasht. Da der der Wert 40 Bit hat, das Passworteingabefeld aber nur 30 Zeichen zulässt, kann man ein "abgelauschtes" Passwort nicht eintragen.

Und du meinst wirklich, dass eine solche Zeichenbegrenzung jemanden davon abhalten kann, einen längeren Wert einzugeben/zu verschicken? :suspekt:

Übrigens ist ein SHA1-Hash 160 Bits lang, nur dessen Hexadezimaldarstellung umfasst 40 Zeichen. Aber das meintest du ja vermutlich

Grüße,
Matthias

 

[ezias]

Beim Login ja. Aber danach ist es nicht sichergestellt.

Dem könntest du ja abhilfe schaffen indem du die Ratschläge von [Flex] berücksichtigst und jedesmal überprüfst ob die Daten mit den des "angebliche" identifizierten Benutzers übereinstimmen.

Zu der sache mit den Cookies weis ich nicht ob man da z.B. PHP Code eingeben könnte der dann mitgeparsed wird.

 

[campari]

Dagegen könntest du z. B. zusätzlich die IP in der Session eintragen (zusätzlich vielleicht noch einen Hash aus Browser, OS und allen Infos die einen Benutzer "unique" machen).

Weiss noch nicht ob ich mit dem Schönheitsfehler .php?PHPSESSID=0as9d8zhnßa789sczf8Z7nIIU9Z89zpsdnf97sdf leben will. Wenns garnicht anders geht, ok ist es eine gute Idee.

Und du meinst wirklich, dass eine solche Zeichenbegrenzung jemanden davon abhalten kann, einen längeren Wert einzugeben/zu verschicken?

Ja, das dachte ich bislang. Allerdings erschütterst Du mit Deiner Andeutung meinen Glauben. Wie soll man ein POST-abgefragten Wert anders übertragen als über das Formular?

Zu der sache mit den Cookies weis ich nicht ob man da z.B. PHP Code eingeben könnte der dann mitgeparsed wird.

Lese die Cookie jetzt so aus: htmlentities($_COOKIE['Benutzer']). Damit ist es ja nicht mehr möglich mir Müll unterzujubeln.


Also mal so generell gefragt,: besteht die Abneigung gegen Cookies aus Überzeugung, aber nicht weil es wie in meinem Beispiel oben unsicher ist, oder? Mir ist unklar, was es gegen Cookies einzuwenden gibt. Ok, gegen google.* hab ich auch Cookies deaktiviert, aber was spricht dagegen ein-zwei Cookies zu setzen?
Ich mag Cookies .P

 

[Flex]

Das größte Ziel sollte meiner Meinung nach sein, ein Ergebnis zu schaffen das alle in der gleichen Weise sehen bzw. genießen können.
Wirft eine Page direkt Errors aus bzw. funktioniert sie nicht, weil sie gegen die Sicherheitsoptionen verstoßen (JavaScript, ActiveX, Java Applets, etc.) verbanne ich sie meist direkt.
Und ungewollte Cookies kann ich nunmal nicht leiden...

Ansonsten meine reima wohl eher die Zeichenbegrenzung deines Input Feldes, denn die kann man leicht umgehen. Eher würde ich auf der Website danach mit PHP testen wie der "Zustand" des Strings ist.

 

[Gumbo]

Ja, das dachte ich bislang. Allerdings erschütterst Du mit Deiner Andeutung meinen Glauben. Wie soll man ein POST-abgefragten Wert anders übertragen als über das Formular?

Eine eigene POST-Abfrage abzuschicken, ist nichts Kompliziertes. Jeder, der mit HTML umgehen kann, kann das. Wieso sollte jemand nicht einfach dein Formular kopieren und die entsprechenden Parameter löschen?
Erfordert eine erfolgreiche Verarbeitung noch zusätzliche per HTTP-Header übermittelte Informationen – so etwa Cookie-Daten oder den Referrer – wird es schon etwas komplizierter. Doch mit etwas PHP-Code ist auch das erledigt.

Also mal so generell gefragt,: besteht die Abneigung gegen Cookies aus Überzeugung, aber nicht weil es wie in meinem Beispiel oben unsicher ist, oder? Mir ist unklar, was es gegen Cookies einzuwenden gibt.

Auf der Serverseite ist gegen Cookies selbst wohl nichts einzuwenden – ich finde sie eine klasse Erfindung. Doch die oft naive Verarbeitung der Cookie-Daten ist eher das Problem. Auf Seiten der Benutzer ist es wohl die Angst vor Datenmissbrauch.

 

[Matthias Reitinger]

Hallo,

Ja, das dachte ich bislang. Allerdings erschütterst Du mit Deiner Andeutung meinen Glauben. Wie soll man ein POST-abgefragten Wert anders übertragen als über das Formular?

Beschäftige dich mal mit dem HTTP-Protokoll oder auch allgemein mit Netzwerkprotokollen. Bei einer POST-Anfrage an einen Webserver wird lediglich eine Verbindung zu selbigem aufgebaut und die Formulardaten nach einigen Kopfzeilen im Klartext übermittelt. Es spricht absolut nichts dagegen, sich selber ein Programm zu schreiben, das genau dasselbe macht – nur mit beliebigen POST-Daten. Meist muss man aber nicht mal so weit gehen. Die Überprüfung auf die Anzahl der Zeichen in einem Formularfeld geschieht beim Client, und auf dessen Verhalten hat man als Webentwickler im Endeffekt keinen Einfluss. Bei einem mit der Web Developer Toolbar ausgerüsteten Firefox braucht es sogar nur zwei Mausklicks um sämtliche Maximallängen einer Seite zu deaktivieren. Insofern sind Maximallängen, versteckte/nicht editierbare Formularfelder nur Mittel, um dem normalen Benutzer (oder auch dem Entwickler) das Leben etwas leichter zu machen – für böswillige Angreifer stellen diese Maßnahmen allerdings kein Hindernis dar. Der Grundsatz sollte deshalb immer lauten: traue niemandem, schon gar nicht deinen Benutzern.

Grüße,
Matthias

 

[campari]

Bin zugegeben etwas geschockt, was alles geht. Aber gut, besser ich erfahre es jetzt .p

Mein schönes sha1-gehashe kommt somit in die Tonne.
Bleibt noch Cookies.

Hab jetzt mal probeweise mit $_SESSION['xyz'] geschrieben. Mit Cookies läufts. Aber: es wird nicht alternativ in der URL die PHPSESSID übergeben. Damit ist das System also auch hinfällig.

Jo, und nu? Dann bleibt mir ja nix anderes übrig als mit Cookies zu handeln.

Doch die oft naive Verarbeitung der Cookie-Daten ist eher das Problem.

Was meinst Du mit naiv?
Würdest Du auslesen mit htmlentities($_COOKIE['xyz']) als fahrlässig bezeichnen?


Danke fuer die guten Ideen hier

 

[campari]

Weiss jemand, wie das Login bei phpMyAdmin funktioniert?
Kann Cookies sperren, und in der URL wird keine PHPSESSID übertragen.
Wie geht sowas?

 

[alex130]

Hi
Hat jemand von euch schon ein fertiges und gutes Login System?
thx

 

[Dennis Wronka]

PHPMyAdmin kann auch HTTP-Authentifizierung, dabei muss keine SessionID uebergeben werden und es werden auch keine Cookies benoetigt.