hallophp

Hallo,

wie sieht es denn hier mit der Sicherheit aus? und was ist im Allgemeinen bei login-Systemen mit Sessions zu beachten? - md5-Verschlüsselung von Passwörtern heißt ja nicht gleich, dass es sicher ist!

Gruß und Danke,
hallophp

Mister Ad

mepeisen

Zuerst solltest du gedanklich voneinander trennen: Verschlüsselung und Hash. Nicht jede Datenverfälschung ist automatisch eine Verschlüsselung. Ein Hash ist eine Datenverfälschung aber führt zu doppeldeutigen Ergebnissen. Sprich:

Wenn dein Hash aus "meinPasswort" den Text "a1a2a4" ergibt, jedoch der Hash aus "meinNeuesPasswort" ebenfalls "a1a2a4" ergibt, hast du ein gewaltiges Problem. Genau sowas macht ein Login-Script unsicher und anfällig gegenüber Rainbow-Tables. Solche Rainbow-Tables sind quasi Passwort-Listen, die einfach per Ausprobieren in dein Loginformular gesteckt werden. Die Rainbow-Tables interessieren sich nicht dafür, das richtige Passwort auszuspähen, sondern einfach irgendeines, das von deinem Script zufällig als das richtige abgesehen wird. Und daher müssen die auch nur einen Bruchteil der theoretisch denkbaren Passwörter ausprobieren.

Alleine aus dem Blickwinkel ist das von dir verlinkte Login-Script bereits als sehr unsicher zu bezeichnen. Es ist gut für ein Lern-Beispiel, bei dem die Sicherheit unwichtig ist, lässt sich jedoch mit einfachsten Mitteln knacken.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nikosch

Das Tutorial nutzt kein mysql_real_escape_string, dafür $_REQUEST und veraltete Techniken wie:
Das wäre meine Kritik am Ganzen.

Wen wunderts:
Auf solche Sachen muß man achten!

Was die Hashes betrifft - mepeisens Aussage finde ich unzutreffend.
Richtig, Hashes sind keine Verschlüsselung. Das andere ist imho falsch: Rainbowtabellen machen sich zum Prinzip, Trivialpasswörter auf deren berechneten Hashwert abzubilden, um diese schnell abrufen und zum Ermitteln eines Passwortes zu einem anderweitig ermittelten gültigen Hash benutzen zu können. Hash-Kollisionen sind statistisch dagegen sehr unwahrscheinlich, weshalb ein Hashing mit einem benutzten Seed (geheime Passwortverlängerung) schon verhältnbismäßig sicher sein kann. Hash-Kollisionen sind dann eben das Restrisiko.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Du vergisst da eines: In obigem Beispiel gab es keinerlei Salz, Nikosch. Klar, je nachdem, ob du das Salzt und wie extrem, ob du doppeltes Hashing nutzt u.ä., kannst du das soweit treiben, dass jede derzeit denkbare Rainbow-Table unbrauchbar wird.
Dann hast du jedoch ein zweites Problem: Wenn du ein Open-Source-Produkt verwendest, kannst du einen Angreifer durchaus in die Lage versetzen, das Salz zu errechnen, wenn er einen eigenen Account hat und durch Ausprobieren Hash-Kollisionen findet.

Es gibt bzgl. Sicherheit ein gewaltiges Kommunikationsproblem: Sicherheit bezieht sich auf Angriffsmethoden und auf Anforderungen. Zu sagen, dass etwas sicher ist, impliziert, dass man dabei Angriffsmethoden im Hinterkopf hat und eine Anforderung an die Höhe der Sicherheit.
Natürlich würde kaum jemand je versuchen, das Salz wie oben beschrieben zurückzurechnen, auch wenn es durchaus denkbar wäre. Zum einen braucht man dazu Zeit und Rechnerpower und zum zweiten gibt es andere deutlich effektivere Angriffsmethoden. So gesehen ist das Salten entsprechend sicher.

Aber es gibt einfach umzusetzende Varianten, die noch sicherer sind, beispielsweise ein Salz, was zusätzlich in der Datenbank hinterlegt wird und sich pro User unterscheidet. Beispielsweise die Microsekunden bei der Registrierung.

Hashmethoden haben beispielsweise gegenüber 2-Weg-Verschlüsselungen einen entscheidenden Vorteil: Fällt die Datenbank einmal in falsche Hände, lässt sich das tatsächliche Passwort nicht mehr zurückrechnen. Heutzutage verwenden viele User auf hunderten Webseiten den gleichen Benutzernamen und das gleiche Passwort. Einfach aus Notwendigkeit, sich nicht hunderte Passwörter zu merken. Schafft man als Angreifer, eine unsichere Webseite zu knacken, um so aus einer Datenbank tausende Passwörter auszulesen, die dort im Klartext gespeichert sind, hat man bereits Geld verdient. Solche Benutzername-Passwort Kombinationen kann man durch Ausprobieren auf anderen Webseiten schnell versilbern.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nikosch

Nö, habe ich nicht vergessen. Ich habe nur gesagt, dass Deine Aussagen in meinen Augen Quatsch sind, weil eben nicht die Kollision das Problem bei Rainbowtables sind, sondern die Trivialpasswörter ohne Salt. Gegen Kollision kannst Du so oder so nichts zun.
Merkst Du was?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Ich brauch nichts zu merken, ich weiß doch bereits von Anfang an worauf du hinaus willst. Nur drehen wir uns im Kreis: Meine Aussagen sind keinesfalls Quatsch, wenn man den richtigen Bezug herstellt. Deine Aussagen sind aber auch kein Qutsch, wenn man den richtigen Bezug herstellt. Der Unterschied ist, dass wir zwei beiden andere Maßstäbe anlegen, deswegen ist meine Aussage in deinen Augen Qutasch

Nichts anderes ist gemeint mit meinem obigen Absatz über das "Kommunikationsproblem". Wir zwei wissen beide, was sicherer ist und was nicht. Und wir zwei beide wissen, dass es im Prinzip kein perfekt gesichert gibt, sondern dass es immer nur eine Frage eines Wettrüstens ist.
Bei der Antwort auf die Frage "Ist XYZ sicher?" muss man immer mit kommunizieren, welche Attacken man im Sinn hat und welche Anforderungen. Eine Antwort "Ja" darf es bei dieser Frage niemals geben, denn es gibt immer nur die Antwort "Ja, weil derzeit keine Attacken bekannt sind oder der Aufwand für Rechenleistung etc. zu hoch, um das zu knacken." oder die Antwort "Ja, weil der Aufwand so hoch ist, dass es unattraktiv wird für einen professionellen Hacker."

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nikosch

Ich wollte Dich auch nicht anmachen Aber das weißt Du hoffentlich.
Mit
meinte ich den Widerspruch in Deiner Aussage. Fällt die Datenbank in falsche Hände, lässt sich das tatsächliche Passwort natürlich zurückrechnen, wenn man den Salt brav in den selben Datensatz geschrieben hat.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Ich habe mich auch nicht angemacht gefühlt gewesen tun

Aber eine Aussage von dir ist schlichtweg falsch. Ein MD5 kannst du niemals zu einem Ursprungspasswort zurückrechnen. Ich hoffe du hast das so auch nicht gemeint, denn dann hättest du ein gravierendes Verständnisproblem, was MD5 tut. Du kommst bestenfalls zufällig mal auf das ursprüngliche Passwort. Das, was du kannst, ist ein Alias zu errechnen, wenn du die Datenbank hast. Sprich: Du kannst problemlos ohne weiteren Zugriff auf die Webseite Account-Passwort Paare ermitteln. Dieses Paar funktioniert jedoch (Salt vorausgesetzt) niemals auf einer anderen Webseite, sofern nicht zufällig die Salts dort übereinstimmen, wovon ich mal ausgehe.

Meine Argumentation: Du kannst versuchen, Passwörter zu erraten. Dabei kannst du die Rainbow-Tables als Wörterbücher mißbrauchen, indem du gezielt Passwörter verwendest, die deinen Algorithmus (bei Open Source bekannt) erfüllen und die der Reihe nach MD5s durchgehen. Bei MD5-Hashes, die einfach durch "statisches" Salz angereichert werden, nimmst du eins oder gleich eine ganze Reihe von bekannten User-Passwort-Paaren und nimmst diese als Grundlage um den Algorithmus zu ermitteln.
Du redest davon, eine bereits gehackte Datenbank (beispielsweise per SQL-Injection ist der MD5 des Admins ausgelesen worden) zu nutzen, um via Rainbow-Tables ein funktionierendes Passwort zu ermitteln.

Das sind zwei völlig verschiedene Angriffsvarianten und zwei völlig verschiedene Schuhe. Klar, sofern Passwörter einfach sind, führt eine Rainbow-Table zufällig zum Ursprungspasswort (Passwort "hund" wird sicher auch in einigen Rainbow-Tables verwendet). Aber die Rainbow-Tables decken nicht nur diese Art des Wörterbuchs ab. Sie lassen sich für mehrere Formen der Hackerangriffe mißbrauchen. Oder anders ausgedrückt: Du hast eine bestimmte Unterart der Rainbow-Tables im Sinn. Zu der Familie gehören aber auch Tabellen, die auf kryptischen Passwörtern basieren und im Sinn haben, jeden denkbaren Hashcode über algorithmen auf ein funktionierendes Passwort zu mappen.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

hallophp

d.h. heißt also ich ersetzte die $_REQUEST-Anweisungen mit mysql_real_escape_string? - oder muss ich dafür das gesamte Login-System verändern?

das würde ja nur das Eintragen der sog. Testbenutzer betreffen; dieses Skript habe ich sowieso ersetzt, oder kommt das noch an einer anderen Stelle vor?

ansonsten gibt es nichts auszusetzen? - das wäre mir auch lieber, da ich das Login-System schon integriert habe.

Gruß und Danke (für die Diskussion ),
hallophp

nikosch

@hallo: Bitte benutze die Forensuche und/oder Google zu den Themen $_REQUEST und real_escape. Und nein, das sind zwei getrennte Probleme.

Das ist klar. Ich kan aber ein Ursprungspasswort (passendes Passwort) ausrechnen (genauer: ermitteln).

Das hat aber nichts mit Rainbow-Tabellen zu tun, sondern ist eine Wörterbuchattacke. Rainbows machen nur Sinn, wenn über eine Codelücke möglich ist, über Bruteforce o.ä. gültige Hash/User kombinationen zu ermitteln.

Aber lass uns hier aufhören, wir wissen beide, wovon wir reden

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--