PHP Passwort abfragen knacken

[Andrew Msliller]

Hey,

Ich hab mir heute folgendes gedacht:

Auf manchen websites findet man PHP Passwort requests.
Wenn man Weiss welche Variable für das Passwort steht kann man doch mittels eines PHP Scripts eine Schleife machen die zahlen und buchsteben systhematisch durchläuft

erst 0-9 dann a-z irgendwann mal az oder zz oder zzz oder 156zz oder dg456dgssd4g654nbv54gzn5j46gh ...

man brüchte nur einen rückgabe wert um das zu kontrollieren und um die schleife dann abzubrechen.

habt ihr schonmal über sowas in der richtung nachgedacht?

wenn nicht einfach nichts schrieben, ich möchte nur "mitdenkende" antworten

THX
Andrew Msliller

[Steffen]

Hallo Held,

das Passwort wird nicht in irgendeiner Variablen gespeichert, sondern afaik in $_SERVER["PHP_AUTH_PW"]. diese variable kannst du bei sicherer programmierung (zB register_globals=off bzw. vermeidung von globalen variablen) nicht über GET oder POST setzen.

aber unabhängig davon kannst du jedes passwort/benuztername über eine bruteforce-attacke knacken. allerdings solltest du dir folgende rechnung mal reinziehen:

es gibt 26 kleine + 26 große buchstaben + 10 zahlen (die sonderzeichen lasse ich mal außen vor) => 62 zeichen:
daher hast du zB für passwörter mit max 4 buchstaben
62^4=14.776.336 möglichkeiten mit 4 buchstaben

• 62^3=238328 mit 3 buchstaben
• 62^2=3844 ...
• 62 ...
  =============
  15.018.570 möglichkeiten  für passwörter mit MAX 4 zeichen!
  du kannst es mal für 5 und 6 ausrechnen, dann geht's richtung unendlich.
  und du weist auch nicht mal unbedingt den benutzernamen, für den das passwort passt.

du kannst aber gerne mal ein script schreiben und so eine atacke laufen lassen und laufen lassen und laufen lassen und laufen lassen...

aber rein theoretisch ist es natürlich so möglich überall einzudringen.

hochachtungsvoll,
steffen

[backbone]

hi,

will noch was zum oberen post ergenzen:

wenn man noch sicherer programmieren will dann setzt man nach 3 fehlerhafen loginversuchen ein delay ein so das es dauert bis nen antwort kommt oder es wird ein freischaltcode an die mailadresse des users geschickt um selbst wenn das passwort rausgefunden wird man den code benötigt.

tschau

[Steffen]

hallo,
ich habe auch nochwas hinzuzufügen:
ich praktiziere es eigentlich immer so, dass nach dem 3. fehlerhaften loginversuch der dialog nicht mehr erscheint, sondern die meldung, wie wenn man auf abbrechen klickt.
denkbar wäre neben den bereits genannten lösungen auch, den account für einige minuten zu sperren (um diesem thread wenigstens ein bischen sinn zu entlocken).

steffen

[Henryk Plötz]

Moin,

ich praktiziere es eigentlich immer so, dass nach dem 3. fehlerhaften loginversuch der dialog nicht mehr erscheint, sondern die meldung, wie wenn man auf abbrechen klickt.

Ähm, bloß dass HTTP die Information "3. fehlerhafter loginversuch" nicht hergibt. Selbe Begründung wie bei der "User Online"-Anzeige.

[Steffen]

Ähm, bloß dass HTTP die Information "3. fehlerhafter loginversuch" nicht hergibt. Selbe Begründung wie bei der "User Online"-Anzeige.

du hast wohl noch nie so einen login gebaut...
zum einen könnte man das auf ebene der bentuzernamen aufbauen und die fehlgeschlagenen logins loggen.
aber es ist viel einfacher, denn wenn ich mich recht erinnere wird die verbindung zwischen der übermittlung der benutzerdaten/neuanforderung trotz aller tücken des HTTP-protokolls nicht getrennt. daher kann man einfach in einer schleife im php-script die versuche mitzählen und ab einer bestimmten zahl aussteigen.

mfg,
steffen

[JvM]

Wenn man ne kleine Zeitverzögerung der Fehlermeldung von ein paar Sekunden oder so reinbaut, dann ist brute-force so gut wie unmöglich. oder nicht?

[Henryk Plötz]

Moin,

du hast wohl noch nie so einen login gebaut...

Habe ich. Mehrfach. Und ich habe die relevanten RFCs gelesen.

zum einen könnte man das auf ebene der bentuzernamen aufbauen und die fehlgeschlagenen logins loggen.
aber es ist viel einfacher, denn wenn ich mich recht erinnere wird die verbindung zwischen der übermittlung der benutzerdaten/neuanforderung trotz aller tücken des HTTP-protokolls nicht getrennt. daher kann man einfach in einer schleife im php-script die versuche mitzählen und ab einer bestimmten zahl aussteigen.

Muhaha, verzeihe wenn ich das nicht ernst nehmen kann, aber _du_ hast wohl noch kein Login gebastelt.

a) Es gibt gar kein 'Login', bei HTTP Authentication wird jeder Request einzeln authentifiziert und authorisiert.
b) Wie willst du auf Benutzernamengrundlage den Authentifizierungsdialog nicht erscheinen lassen, wenn der Benutzername doch in diesem Dialog eingegeben wird.
c) Selbstverständlich bringt ein Zähler im PHP-Skript genau gar nichts, da ein Authentifizierungsversuch immer genau mit einem Request gekoppelt ist, und das PHP-Skript (wie mit wenigen Ausnahmen bei allen serverseitigen Skripttechnologien) nur während der Bearbeitung eines Requests läuft.

Es ist mir eine Freude dir http://www.nuhr.de/home_bar.html ans Herz legen zu dürfen.

[Christian Seiler]

Hallo Henryk,

a) Es gibt gar kein 'Login', bei HTTP Authentication wird jeder Request einzeln authentifiziert und authorisiert.

Bei HTTP-Authentifizierung: ja. Allerdings kann man auch eine Authentifizierung, die sich Sessions als Hilfsmittel zur Benutzerwiedererkenung bedient, bauen. Und bei dieser ist es dann sehr wohl möglich, einen Benutzer nach soundsoviel fehlerhaften Loginversuchen temporär (oder permanent) zu sperren.

Viele Grüße,
Christian

[Steffen]

hallo,

ok, ich habe mich da wirklich in einigen punkten vertan.

da ich seit längerem immer direkt die .htaccess-authentifizierung nutze habe ich einiges durcheinandergeschmissen.

ich hatte nur noch in erinnerung, dass nach 3 erfolgreichen anmeldeversuchen auf einer meiner seiten kein login-fenster mehr kam. ich habe jetzt feststellen müssen, dass es nur durch den internet-explorer so gemacht wird (NEIN, ich surfe NICHT mit dem ie - ich nutze ihn lediglich zum testen von lokalen seiten).

bei der behauptung,dass die verbindung zwischen den login-versuchen nicht getrennt wird, hatte ich mich vorhin durch opera blenden lassen, der mit der ladezeit nicht wieder von vorne anfängt, sondern die ganze zeit weiterläuft.

festzustellen, ob ein account gehackt wird, kann man jedoch schon, indem man die fehlerhaften logins in eine datenbank einträgt. wenn dann ein limit überschritten wurde, kann man keine login-aufforderung mehr senden oder ähnliches.

mfg,
steffen

[Sven Rautenberg]

Moin!

festzustellen, ob ein account gehackt wird, kann man jedoch schon, indem man die fehlerhaften logins in eine datenbank einträgt. wenn dann ein limit überschritten wurde, kann man keine login-aufforderung mehr senden oder ähnliches.

Und damit eröffnet man eine wunderbare Tür für Angreifer, die durch fehlerhafte Logins bei bekannten Usernamen den Usern ihr Login blockieren können.

Genauer: Man braucht eigentlich schon gar keine Passwörter mehr zu bruteforcen, sondern muß lediglich Usernamen bruteforcen - bzw. reicht da sicherlich auch eine Wörterbuchattacke.

Merke: Bei allen Dingen, die es erlauben, einen Service nicht mehr nutzen zu können, läuft man Gefahr, dass es mißbraucht wird und ärgerlichen manuellen Zusatzaufwand erfordert.

- Sven Rautenberg

[TomIRL]

Hallo

das Passwort wird nicht in irgendeiner Variablen gespeichert, sondern afaik in $_SERVER["PHP_AUTH_PW"]. diese variable kannst du bei sicherer programmierung (zB register_globals=off bzw. vermeidung von globalen variablen) nicht über GET oder POST setzen.

Na das stimmt aber nicht!
Ich kann mittels $_get sehr wohl die "falschen" Passwörter einlesen!
Viele Grüße aus Berlin
TomIRL

[Johannes Zeller]

Hallo Andrew

man brüchte nur einen rückgabe wert um das zu kontrollieren und um die schleife dann abzubrechen.

Das was du beschreibst, ist eine Brute-Force Attacke, bei der alle Möglichen Zahlenkombinationen ausprobiert werden. Das funktioniert jedoch nicht so leicht, wenn genügend Zeichen für das Passwort verwendet werden. Bei 8 Zeichen Groß- und Kleinbuchstaben und Zahlen, gibt es z.B. 62 hoch 8 Möglichkeiten, das sieht als Zahl ungefähr so aus:
    228 340 105 600 000, oder über 228 Billionen Möglichkeiten. Mit heutigen Rechnern dauert es schon ziemlich lange, wenn man so etwas ausprobieren will. Mann muss jedoch bedenken, dass die Computer in Zukunft auch immer schneller werden, deshalb sollte man IMHO Passwörter nehmen, die mindestens 10 Zeichen lang sind.

Eine Brute-Force Attacke ist natürlich nicht besonders wirksam, auch wenn die genannten Zahlen, natürlich nur die Größtmögliche Anzahl an benötigten Versuchen ist, meistens würde das richtige Passwort viel früher gefunden. Als Absicherung gegen solche Attacken hilft es auch, eine Zeitverzögerung beim Login einzubauen.

Selbstverständlich gibt es auch subtilere Mittel, um ein Passwort zu knacken. Am Gefährlichsten sind Sicherheitslücken im System oder Fahrlässiger Umgang mit dem Passwort (aufschreiben). Auch Wörter aus dem Duden oder der Umgebung des Passwortinhabers (sofern diese bekannt ist) auszuprobieren, ist eine häufig genutzte Möglichkeit, da viele Menschen Passwörter wählen, die für sie relativ einfach zu merken sind.

Gute Nacht

Johannes

P.S.: Unter http://aktuell.de.selfhtml.org/artikel/gedanken/passwort/index.htm findest du einen Feature-Artikel von Christian Kruse, der erläutert, was ein sicheres Passwort ausmacht.

[Andrew Msliller]

HI

(...) da viele Menschen Passwörter wählen, die für sie relativ einfach zu merken sind.

JA da gehöre ich sogar dazu: ich habe eine 6stellige zahlenkombination... eigentlich sicher: 62^6 = 56.800.235.584

mann muss bedenken es dauert nicht mal 56.800.235.584, da 56.800.235.584ste versuch der letzte Versuch 6-stelligen kombination wäre und der wäre doch 999999 oder?

MFG
Andrew Msliller

[Sven Rautenberg]

Moin!

JA da gehöre ich sogar dazu: ich habe eine 6stellige zahlenkombination... eigentlich sicher: 62^6 = 56.800.235.584

6stellige Passwörter sind grundsätzlich als UNSICHER anzusehen.

Insbesondere, wenn du die Zusatzinformation mitgibst, dass es sich nur um Zahlen handelt. Denn dann sind lediglich eine Million Kombinationen zu prüfen.

Mal eine kurze Überschlagsrechnung:
Angenommen, das Prüfen eines Passwortes dauert 0,01 Sekunden (oder 10 Millisekunden). Dann wird das Prüfen von einer Million Passwörtern genau 10.000 Sekunden dauern, oder 166,6 Minuten, oder 2,7 Stunden.

Nun arbeitet ein Webserver aber nicht linear, sondern er wird viele Requests gleichzeitig verarbeiten. Damit kann man also zehn oder hundert Prozesse gleichzeitig laufen lassen und die Wartezeit damit von 10.000 auf nur noch 1000 oder gar 100 Sekunden verkürzen.

100 Prozesse gleichzeitig wird aber möglicherweise nicht gehen, weil das die verfügbare Bandbreite zum Server etwas überlastet. Also mal kurz gerechten: Ein Passwort-Request benötigt grob 1 KB an Daten für HTTP. Es kommen in einer Sekunde bei einem Request parallel 100 Requests zusammen, also 100 KB/sec. Bei 10 Requests sind das schon 1 MB/sec, und bei 100 Requests sind es 10 MB/sec. Zehn Megabyte in der Sekunde sind aber mit heutigen Netzwerktechnologien gar kein Problem. 100 MBit/s Ethernet schafft das mit Sicherheit. Und an sowas ist eigentlich jeder Server in großen Rechenzentren angeschlossen.

Die Attacke funktioniert also, in 100 Sekunden ist dein Passwort, das nur aus Zahlen besteht, geknackt. SPÄTESTENS. Durchschnittlich ist das Passwort nach der Hälfte der Zeit geknackt.

Jetzt halten wir mal ein 10stelliges, wirklich zeichenreiches Passwort dagegen. 62 verschiedene Zeichen hoch 10 Möglichkeiten sind 839.299.365.868.340.224 Möglichkeiten. Oder kurz gesagt: 8,3 * 10^17 Möglichkeiten.

Wenn es, wie oben, 0,01 Sekunden dauert, um ein Passwort zu checken, und wir 100 Passwörter gleichzeitig prüfen können, schafft man pro Sekunde 10.000 (10^5) Passwörter. Das bedeutet, dass es immer noch 8,3*10^12 Sekunden dauert, alle Passwörter auszuspionieren. Das sind 269844 Jahre.

Aber selbst wenn man die Prüfzeiten nochmal wesentlich verbessert, wird es nicht wesentlich kürzer dauern: Nehmen wir an, dass ein einzelner Thread eine Million Passwörter pro Sekunden prüfen kann, und dass eine Million Prüfungen parallel stattfinden.

Dann dauert die Prüfung immer noch 8,3*10^17 / 10^6 * 10^6 = 8,3*10^5 Sekunden.

8,3*10^5 Sekunden sind 236 Stunden.

Aber bedenke, was der Server dann leisten muß: Er muß die Datenmenge von 10^6*10^6 = 10^12 Kilobyte pro Sekunde verkraften. Oder auch 10 Petabyte pro Sekunde. Das sind 10.000 Terabyte. Oder 10.000.000 Gigabyte. So dicke Leitungen gibts derzeit noch nicht!

Ein zehnstelliges Passwort ist also relativ sicher.

- Sven Rautenberg