Om nah hoo pez nyeetz, Jörg Reinholz!

Ich würde mich sehr freuen, wenn du dich für SELFHTML engagieren würdest. Ich befürchte aber auch, dass es Gegenwind und Phasen von Desinteresse geben wird und würde mich deshalb noch mehr freuen, wenn das Projekt auch zuende gebracht werden würde.

Matthias

--
Der Unterschied zwischen Java und JavaScript ist größer als der zwischen satt und Sattel.

Om nah hoo pez nyeetz, Sven Rautenberg!

Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

font-size: 1.1em?

Matthias

--
Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Scheuer und Scheuerleiste.

Ich mag diese riesigen Code-Blocker nicht im Fließtext. Die zerreißen ihn vollkommen, vor allem, wenn sie gehäuft in einem Absatz vorkommen. Monospaced-Schrift: Klar. Farbig hinterlegt: Auch. Aber nicht fett und riesig. :)

Ich habe das CSS durchsucht. <pre> geht nicht. <kbd> könnte man missbrauchen...

Jörg Reinholz

Moin!

Tach!

Richtig, das Thema ist notwendigerweise komplex. Deswegen würde ich alles weglassen, was auf die notwendige Komplexität noch unnötige draufsetzt.

In der Hinsicht sollte die Frage in den Raum geworfen werden, wie weit wir gehen wollen.
* Komplette Lösung?
* Nur ein Anriss?

Du kannst keine komplette Lösung in einem Artikel präsentieren, sonst hast du in nahezu jedem Teilaspekt, der für das Thema wichtig ist, zwei bis drei Aspekte, die davon ablenken.

Wenn du eine komplette Lösung anbieten willst, biete sie zum Download an. Viel Spaß bei der Pflege die nächsten Jahre (was leider, auch bei Code in Artikeln, ein grundsätzliches Problem ist, zu dem ich keine Lösung habe).

Was ist für ein aktuelles Login-System zwingend notwendig? Ein User muss sich neu anmelden können mit Username und Passwort, und er muss sich einloggen und dabei das Passwort geprüft kriegen.

Das ist der Stand der Dinge.

password_needs_rehash().
Oha! Das schafft einen völlig neuen Punkt und einen völlig neue Diskussionsbedarf:
* Das Passwort im Hintergrund schweigend neu hashen
* und/oder (auch zu diskutieren!)
* den Benutzer hinsichtlich des schwach gehashten Passworts warnen und ein neues eingeben lassen. Bitte auch an die Verwirrung der Benutzer und die "Kommerzköppe" denken.

Und natürlich das Prüfen des Passworts auf Komplexität
Woll. Das dann gleich mit.

Das Speichermedium für die User steht nicht im Mittelpunkt.
Hab ich gelesen. Mal sehen, was die anderen dazu sagen.

Die auszuliefernden Inhalte auch nicht.
Naja. Ohne den Schutz auch auf andere Dateien (Pics, Medien, Downloads) auszudehnen macht das nicht so viel Sinn - oder? Meinst Du das überhaupt?

Eine "komplette Lösung" müsste ja sinnvollerweise irgendwelchen Content anbieten, den nicht jeder sehen darf. Würdest du noch Usergruppen ins Thema hineinziehen, brauchst du sogar zwei unterschiedliche Inhalte. Und musst außerdem Dinge wie ACL oder RBAC erklären und implementieren (beides bietet allein schon Stoff für jeweils mehr als zwei Artikel, IMHO).

Die Fallback-Lösung für PHP-Versionen kleiner 5.5 ebenfalls nicht (das ist ein Einzeiler mit "Lad die Kompatibilitätslib runter und rufe am Anfang einmal require_once(libdatei.php) auf."). Das sind alles Themen für andere Artikel drumherum.

Hier bin ich ziemlich fest anderer Meinung und habe dafür nach meiner Meinung auch gute Gründe: Wir schreiben den Februar anno 2015. Viele haben in dieser Realität bei ihrem Hoster noch kein PHP 5.5 oder jünger. Ich halte es für keine gute Idee Skripte anzubieten, die bei denen (noch) nicht laufen. Das würde einen Ansehensverlust und eine Menge Rückfragen - nicht nur hier im Forum - nach sich ziehen.

Die Lib läuft bis runter zu PHP 5.3.7. Sie läuft deswegen nicht mit älteren Versionen, weil deren Crypt-Funktion kaputt ist!

Du willst auf kaputter Softwaregrundlage keine Reimplementierung relevanter Hashing-Algorithmen bauen. Es ist unmöglich, bcrypt nativ in PHP zu implementieren - der Laufzeitunterschied zur C-Variante wäre vermutlich recht hoch, was dazu zwingen würde, einen deutlich kleineren Kostenfaktor zu wählen - das gefährdet aber die Sicherheit. Dasselbe gilt für alternative Hash-Algorithmen.

Ich finde es sehr bedauerlich, dass man auf eine Plattform, deren offizieller Support bereits vor über einem halben Jahr endete (18. August 2014), immer noch mit Primärfokus Rücksicht nehmen soll. Wie sollen Entwickler lernen, mit den Möglichkeiten der neuen Versionen umzugehen und sie folgerichtig bei ihren Hostern auch einzufordern, wenn es niemand vormacht?

Abwärtskompatibilität ist kein Primärziel des Artikels, sondern eine Randerscheinung.

- Sven Rautenberg

Moin!

Test:
http://www.fastix.org/test/selfhtml_login/

Es gibt:

• mehrere Benutzer (die stehen auf der Login-Seite mit Password gelistet...)
• mehrere Gruppen
• Benutzer können gesperrt werden und fliegen sofort raus.
• Eine einfache Möglichkeit Gruppenrechte (bisher: für PHP-Skripte) zu vergeben.
• Andere Ressourcen als PHP-Skripte werden auch schon geschützt.

• Login an IP-Adresse gebunden

IPv4? Wie verträgt sich das mit NAT und Zwangsreconnect?

IPv6? Und welchen Sinn macht das dort, wenn Privacy Extensions eingeschaltet sind?

• IDLE-Time (Zeit ohne Aktivität) begrenzt

Sinnvoll.

- Sven Rautenberg

Om nah hoo pez nyeetz, Jörg Reinholz!

Wenn schon warnen, dann doch bitte erst mal den hier. Da stehen Passwörter a) im Programm und das dann noch im Klartetxt.

Dieser wird demnächst auf http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem weiterleiten.

Und der hier erfüllt die von Dir genannten Kritikpunkte hinsichtlich des Kontrollflusses auch.

Und hier verweise ich ebenfalls auf http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem

Matthias

--
Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Manga und Mangan.

Hakuna matata!

Ich sehe da noch deutlichen Handlungsbedarf

Ich habe nie behauptet, dass der Artikel fertig ist. Ich sprach von Fortschritten.

Vollkommen okay, ich wollte auch nie dich persönlich kritisieren. Im Gegenteil, ich bin froh dass du dich darum kümmerst, ich weiß nicht in welcher Verfassung der Artikel vorher war, aber ich kann mir vorstellen, dass du die ein oder andere Falte schon ausgebügelt hast. Ich kann derzeit nicht die Zeit und Motivation aufbringen, mich aktiv im Wiki zu beteiligen, ich bringe stattdessen meine 2 Cent hier im Forum ein und hoffe, dass ich damit bei irgendeinem Freiwilligen auf offene Ohren stoße.

und ich finde, solange der Artikel in diesem schlechten Zustand verweilt, sollten wir ihn mit einer dicken, fetten Warnung versehen.

He, halt mal. Du willst warnen? Das ist ein wenig so als würdest Du wegen eines Steinchens auf dem Weg die Wanderer in den Sumpf schicken:

Ich halte es ehrlichgesagt für selbstverständlich, dass wir unsere Leserschaft vor unfertigen Artikeln mit bekannt gewordenen Defiziten warnen. Ich hätte nicht gedacht, dass wir darüber ernsthaft diskutieren müssen. Was die anderen beiden Artikel angeht, die habe ich nicht gelesen, aber falls diese in einem ähnlichen Zustand sein sollten, dann sollten wir auch davor warnen.

Hakuna matata!

Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist.

Wenn ein Angreifer den Verkehr wirklich mitschneidet, dann kann man davon ausgehen, dass dieser auch die Server-Antwort zu sehen bekommt, in der dann auch schon die neue Session-ID übermittelt wird. Der Angreifer könnte daraufhin sofort eine neue Anfrage an den Server senden und damit den regulären Nutzer aus seiner eigenen Sitzung aussperren.

Siehe dazu auch: http://forum.de.selfhtml.org/archiv/2014/3/t216939/#m1489011

Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.

Das hat man doch schon dadruch erreicht, dass die Credentials nur einmal fällig werden und danach auf Session-ID zurückgegriffen wird, um den Nutzer erneut zu identifizieren. Was trägt es da an zusätzlicher Sicherheit bei, die Session-ID ständig zu erneuern?

Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist.

Also mir sind keine Perfomance-Bottlenecks von HTTPS bekannt und dem Tradeoff Sicherheit für Performance kann ich auch im Allgemeinen nicht viel abgewinnen.

Wenn man session_regenerate_id() zudem bei jeder Anfrage ausführt, dann können keine Anfragen des selben Nutzers mehr parallel bearbeitet werden. Denn wenn die zweite Anfrage eintrifft, ist die Session-ID von der ersten Anfrage bereits für ungültig erklärt worden.

Auch dazu hatte molily schon mal ein paar Worte verloren:
http://forum.de.selfhtml.org/archiv/2014/4/t217253/#m1491970

Moin!

session_regenerate_id(); // erneuert die Session-ID,

#                         // erschwert Session-Hijacking

>   
> > Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.  
>   
> Danke für den konstruktiven Hinweis. Ich habe der Funktion session\_regenerate\_id() den Parameter true hinzugefügt (damit wird seit PHP 5.1. die alte Session gekillt) und mir auf den Zettel geschrieben, dass dieses, so die Diskussion hier nichts besseres ergibt,  an die Nicht-Nutzung von https gebunden wird.  
  
Session-Fixation geht auch mit HTTPS. Es ist eine gute Idee, bei HTTPS ebenso neue Session-IDs zu erzeugen, wenn der User seine Rechte in seiner Session erhöht, d.h. vom unangemeldeten User zum angemeldeten User wird, und von dort evtl. nochmal zum Admin. Jede Erhöhung der Rechte sollte eine neue Session-ID ergeben.  
  

> Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist. Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.  
  
Unverschlüsselte Kommunikation ist sowieso anfällig gegen alles. Der Knackpunkt ist, dass auch Verschlüsselung nicht gegen Angriffe schützt!  
  

> Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist. Deshalb wäre ich beim Stand der bisherigen Diskussion für:  
>   
> https: keine Umbennnung  
  
Falsch.  
  

> http: Umbenennen mit session\_regenerate\_id(true)  
  
Richtig.  
  
 - Sven Rautenberg