Moin!
angeregt durch entsprechende Threads zu diesem Thema hier im Forum, hab ich heute einen kleinen aber feinen Artikel dazu geschrieben, hier ist er nun.
Ein schlechter Artikel, der vor allem durch die unwissentlichen Nebendetails Schaden anrichtet.
1. Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext. Problematisch ist dabei insbesondere das Abschneiden des Passworts auf 8 Zeichen maximal, sowie der schwache und heutzutage leicht knackbare DES-Algorithmus mit nur 56 Bit.
Minimum wäre an dieser Stelle sowas wie MD5 - auch das ist schon böse angegriffen worden, aber für kurze Passwortstrings vielleicht noch als gerade so ok anzusehen. Da aber überall, wo MD5 existiert, auch SHA-1, SHA-256 oder ggf. SHA-512 existieren, sollte man direkt diese Funktionen verwenden.
2. Die Zufälligkeit der Funktion makeSID wäre auch erst mal anzuzweifeln. Da stecken mir zu viele Informationen drin, die keinesfalls zufällig sind: Zeit in Sekunden, Prozess-ID, und eine "Auswahl" an Textzeichen, die aus irgendeinem Grund in ihrer Zeichenvielfalt eingeschränkt wurden.
Das allein sind für mich drei Anzeichen für "Vorsicht". Und da hilft auch nicht das Argument, dass die Funktion ja ausreichend "verschiedene" SIDs produziert und bei 500.000 Aufrufen kein Duplikat ausspuckt. Eine Zählschleife von 1 bis 500.000 produziert nämlich denselben Effekt.
Nur mal so angedacht: Wenn der eine Request dem Opfer eine SID generiert, dann hat ein Angreifer im besten Fall eine ganze Sekunde lang Zeit, mit massenhaften Requests dieselbe Prozess-ID wie das Opfer zu bekommen - wenn er dann noch den Zufallsgenerator passend auf Startwert setzen kann (seed), dann kann er dieselbe SID bekommen.
Wo kommt die Funktion her? Wer garantiert für ihre Zuverlässigkeit? Mit Eigenproduktionen erleidet man sehr leicht Schiffbruch!
3. Die Forderung, die Session-ID in einer Datenbank explizit mit UNIQUE-Index abzuspeichern, um Duplikate zu verhindern, ist absurd. Eine vernünftige SID-Funktion produziert ausreichend sicher keine Duplikate.
4. Warum wird kein Session-Framework aus CPAN benutzt? CPAN ist doch der Stolz der Perl-Community, weil da die Perlen der beliebig erweiterbaren Perl-Funktionalität gespeichert sind. Mit Apache::Session und CGI::Session stehen zwei Pakete bereit, die ausreichend hohe Versionsnummern haben und sich irgendwie anbieten.
Bei PHP würde niemand auf die Idee kommen, den Standardmechanismus zu ignorieren und immer selbst was zu schreiben. Klassischer Fall von NIH-Syndrom, würde ich meinen.
- Sven Rautenberg