kann man cookies editieren?

[Alexander Grefrath]

Ich plane per cookie die User_id zu speichern, wenn sich ein user erfolgreich in mein System eingeloggt hat (mysql DB über php gesteuert).
Nach Logout wird dieses cookie gelöscht.

Solange also das (bzw. besser formuliert: "ein") cookie mit gültiger gespeichert ist, wird die passwortabfrage nicht wiederholt.

Soweit so gut. Was aber, wenn jemand von Hand einen Eintrag generiert, der einem solchen cookie entspricht, dann kommt er ohne login rein. Oder noch schlimmer, er dort eine user-id einträgt von einem Admin-User.

Ist der Gedankengang korrekt? Kann man cookies editieren?
Wenn ja, wie kann man das verhindern?

[Philipp Hasenfratz]

Halihallo Alexander

Solange also das (bzw. besser formuliert: "ein") cookie mit gültiger gespeichert ist, wird die passwortabfrage nicht wiederholt.

Du sagst schon: _gültiger_. Du ignorierst deine eigene Aussage.

Ist der Gedankengang korrekt? Kann man cookies editieren?

Ja. Und man muss nicht mal editieren, man kann auch einfach senden...

Wenn ja, wie kann man das verhindern?

Indem man dem Cookie z.B. eine SessionID/-Key oder nur -Key mitsendet und überprüft,
ob diese irgendwo in der Datenbank registiert ist. Ein Angreifer könnte dann nicht
einfach einen Cookie senden, sondern müsste z.B. eine 128-bit Checksumme erraten und
_das_ ist etwas aufwendiger.

Umsetzung: Generiere für jeden neuen Cookie eine zufällige 128-bit Checksumme
(informiere dich über MD5, rand(-om), time, ...), welche du a) mit dem Cookie mit-
sendest, b) in der Datenbank speicherst und c) bei jedem Zugriff überprüfst, ob der
Wert im Cookie mit einem Wert in der Datenbank übereinstimmt; wenn die Session
abgelaufen ist, löschst du den Wert aus der Datenbank und der Benutzer kriegt ein
"Session ist abgelaufen" o.ä. Text zu sehen.

Viele Grüsse

Philipp

[Chris]

Hi Ihr zwei,

und um es dann auch wirklich "sicherer" zu machen und durch den zweiten nicht einfach nur den ersten Schlüssel zu verlängern, sollte man Fehlversuche auch registrieren und darauf reagieren. Das geht eben nur mit einem Zweischlüssel-Verfahren.

Man könnte feststellen, dass eine gültige Session mit einem ungültigen PIN behackt wird, und die Anzahl der Hackversuche als Inkrement der Antwortfunktion verwenden. Dann verlängert sich die Antwortzeit pro Hackversuch z.B. um eine Sekunde. Wenn dann der richtige Schlüssel verwendet wird, gibt es eine Warnung für den User. Der Hackzähler kann dann über einen anderen Weg oder über manuellen Service zurückgesetzt werden.

Bei verbindungslosen Protokollen ist die Zeit (bzw. totale Deaktivierung des Accounts) Dein einziger Freund, um "Sicherheit" herzustellen.

LG

Chris

[Philipp Hasenfratz]

Halihallo Chris

und um es dann auch wirklich "sicherer" zu machen und durch den zweiten nicht einfach nur den ersten Schlüssel zu verlängern, sollte man Fehlversuche auch registrieren und darauf reagieren. Das geht eben nur mit einem Zweischlüssel-Verfahren.

Was'n ein Zweischlüssel-Verfahren???

Man könnte feststellen, dass eine gültige Session mit einem ungültigen PIN behackt wird, und die Anzahl der Hackversuche als Inkrement der Antwortfunktion verwenden. Dann verlängert sich die Antwortzeit pro Hackversuch z.B. um eine Sekunde. Wenn dann der richtige Schlüssel verwendet wird, gibt es eine Warnung für den User. Der Hackzähler kann dann über einen anderen Weg oder über manuellen Service zurückgesetzt werden.

... oder beim erfolgreichen Login wieder zurückgesetzt werden (was besser wäre).
So macht das GMX, wenn ich nicht irre.

Dieses Szenario macht jedoch nur bei Hochleistungszentren mit Load-Balancing-Systemen
und sonstigem Schnick-Schnack wie Glasfaseranbindung zum nächsten Backbone Sinn,
denn: für eine Bruteforce-Attacke und diese versuchst du mit deinem System abzuwehren,
braucht es eine gigantische Anbindung um überhaupt effektiv zu sein... Hast du schonmal
versucht einen 128-bit Schlüssel mit 11Mbit Anbindung über HTTP zu knacken??? -
Good luck and wait forever.
Glaube mir: Das heuert man doch lieber einen Cracker an, der sich über andere Techniken
in den Server hackt. Deine Vorkehrungsmassnahme ist IMHO nur Zeitverschwendung auf deiner
Seite. Trotzdem, deine Vorgehensweise ist lobenswert. Und das mit der Warnung ausgeben
halte ich für sehr sinnvoll.

Bei verbindungslosen Protokollen ist die Zeit (bzw. totale Deaktivierung des Accounts) Dein einziger Freund, um "Sicherheit" herzustellen.

Das hat nichts mit verbindungslos zu tun. Selbes Prozedere wäre bei verbindungs-
etablierenden Services möglich.

Viele Grüsse

Philipp

[Chris]

Hallöle Phillip,

Was'n ein Zweischlüssel-Verfahren???

Na eben ein Verfahren mit zwei Schlüsseln. Über den einen identifiziert sich der User und der andere dient der Authentizitätsprüfung. Loginname und Passwort bilden z.B. ein solches Schlüsselpaar.

... oder beim erfolgreichen Login wieder zurückgesetzt werden (was besser wäre).
So macht das GMX, wenn ich nicht irre.

Das das Schlüsselpaar irgendwann passt könnte auch "zufällig" nach 7443 Versuchen stattfinden und die sind in wenigen Sekunden durchgehackt.

und sonstigem Schnick-Schnack wie Glasfaseranbindung zum nächsten Backbone Sinn,
denn: für eine Bruteforce-Attacke und diese versuchst du mit deinem System abzuwehren,
braucht es eine gigantische Anbindung um überhaupt effektiv zu sein... Hast du schonmal
versucht einen 128-bit Schlüssel mit 11Mbit Anbindung über HTTP zu knacken??? -

Das macht man zweckmäßigerweise natürlich mit 130 bis 150 parallelen Threads. Soviele verkraften die meisten Apachen. Jeder Thread bearbeitet einen Schlüsselkreis. Das verkürzt die Zeit schon mal um Faktor 150. Wenn auf der anderen Seite ein WebServer mit entsprechend hoher Leistung sitzt, kann man die Zahl der Threads ja beliebig erhöhen. Man muss dann noch nicht einmal die normale Response-Time abwarten. Der Versatz zwischen den Threads kann wenige Microsekunden betragen.

Good luck and wait forever.

So lange dauert das dann gar nicht.

Glaube mir: Das heuert man doch lieber einen Cracker an, der sich über andere Techniken

Glaube mir, mein Prof hat uns das mal vorgeführt. Wir waren entsetzt, was alles geht, wenn man nur _vorher_ richtig nachdenkt.

Bis denne

Chris

[Reiner]

Hi,

und sonstigem Schnick-Schnack wie Glasfaseranbindung zum nächsten Backbone Sinn,
denn: für eine Bruteforce-Attacke und diese versuchst du mit deinem System abzuwehren,
braucht es eine gigantische Anbindung um überhaupt effektiv zu sein... Hast du schonmal
versucht einen 128-bit Schlüssel mit 11Mbit Anbindung über HTTP zu knacken??? -

Das macht man zweckmäßigerweise natürlich mit 130 bis 150 parallelen Threads. Soviele verkraften die meisten Apachen. Jeder Thread bearbeitet einen Schlüsselkreis. Das verkürzt die Zeit schon mal um Faktor 150. Wenn auf der anderen Seite ein WebServer mit entsprechend hoher Leistung sitzt, kann man die Zahl der Threads ja beliebig erhöhen. Man muss dann noch nicht einmal die normale Response-Time abwarten. Der Versatz zwischen den Threads kann wenige Microsekunden betragen.

Good luck and wait forever.

So lange dauert das dann gar nicht.

Glaube mir: Das heuert man doch lieber einen Cracker an, der sich über andere Techniken

Glaube mir, mein Prof hat uns das mal vorgeführt. Wir waren entsetzt, was alles geht, wenn man nur _vorher_ richtig nachdenkt.

bei welcher Bandbreite?
Ansonsten ist es Blödsinn! Auch wenn Du das über Threads aufbaust, mußt Du auf den response warten. Zudem ist mit Deiner Vorgehensweise ein Auffallen fast unumgänglich und das ist -denke ich- das schlimmste, was einem "Einbrecher" passieren kann!

Gruß
Reiner

[Philipp Hasenfratz]

Halihallo Chris

Was'n ein Zweischlüssel-Verfahren???
Na eben ein Verfahren mit zwei Schlüsseln. Über den einen identifiziert sich der User und der andere dient der Authentizitätsprüfung. Loginname und Passwort bilden z.B. ein solches Schlüsselpaar.

OK :-)

... oder beim erfolgreichen Login wieder zurückgesetzt werden (was besser wäre).
So macht das GMX, wenn ich nicht irre.
Das das Schlüsselpaar irgendwann passt könnte auch "zufällig" nach 7443 Versuchen stattfinden und die sind in wenigen Sekunden durchgehackt.

Das ist richtig.

und sonstigem Schnick-Schnack wie Glasfaseranbindung zum nächsten Backbone Sinn,
denn: für eine Bruteforce-Attacke und diese versuchst du mit deinem System abzuwehren,
braucht es eine gigantische Anbindung um überhaupt effektiv zu sein... Hast du schonmal
versucht einen 128-bit Schlüssel mit 11Mbit Anbindung über HTTP zu knacken??? -

Das macht man zweckmäßigerweise natürlich mit 130 bis 150 parallelen Threads. Soviele verkraften die meisten Apachen. Jeder Thread bearbeitet einen Schlüsselkreis. Das verkürzt die Zeit schon mal um Faktor 150. Wenn auf der anderen Seite ein WebServer mit entsprechend hoher Leistung sitzt, kann man die Zahl der Threads ja beliebig erhöhen. Man muss dann noch nicht einmal die normale Response-Time abwarten. Der Versatz zwischen den Threads kann wenige Microsekunden betragen.

Nun, das ist natürlich richtig. Nur könnte man ein bit an die 128 anhängen und das ganze
ist um den Faktor (2^128-1)/150 wieder verbessert.

Good luck and wait forever.
So lange dauert das dann gar nicht.

Durchschnittlich wird der Schlüssel mit 2^127 Versuchen gefunden. Selbst bei 2000
Requestverarbeitungen pro Sekunde würde dies (2^127/(2^11) Sekunden = 2^116 Sekunden
dauern... Äm, normalerweise überlebt ein Internetprojekt nicht so lange...

Und: 2000 Requests/s sind schon ziemlich viel für ein Apache mit Perl als CGI-Script-
Programmiersprache... Du dafst das ganze auch gerne mal mit 20000 Requests/s
durchrechnen, das Ergebnis wird nicht sonderlich anders...

Nun, du hast mich noch nicht überzeugt... Deine Argumentation ist zwar richtig, aber
bei kleineren Services erreicht durch einen derartigen Angriff wirklich nur eine
DoS. Natürlich, die Wahrscheinlichkeit wäre durch ein Unterlassen deiner Technik
grösser ein Passwort zu cracken; aber empirisch ist es höchst ineffizient.

Ich weiss jetzt ehrlich gesagt nicht, was ich für die bessere Lösung halte:
a) den Kunden wegen eines falschen Passwortes eine Sekunde extra warten zu lassen und
   wegen der Verzögerung eine Prozessüberlagerung zu riskieren, die eine DoS-Attacke
   wesentlich einfacher macht, nur um die empirisch sehr geringe Wahrscheinlichkeit
   einer erfolgreichen Bruteforce-Attacke zu unterbinden oder
b) die genannte Bruteforce-Attacke zu unterbinden.

Hm... Ich tendiere stark zu a, bin jedoch mit dem Argument von b völlig einverstanden.
Was meinst du?

Viele Grüsse

Philipp

[Chris]

ReHi

versucht einen 128-bit Schlüssel mit 11Mbit Anbindung über HTTP zu knacken??? -

Nun, das ist natürlich richtig. Nur könnte man ein bit an die 128 anhängen und das ganze
ist um den Faktor (2^128-1)/150 wieder verbessert.

Ein Bit ist bei mir immer noch = Faktor/Divisor 2 und nicht 2^128 *???*

Kommt natürlich auf das Formular an, über das die Anfrage stattfinden muss. Gehen wir mal von Method=Post aus und dass nur die Cookies und zwei Nutzfelder im Request übertragen werden müssen, dann dürfte man da mit ca. 120-200 Bytes auskommen. Und wenn die Antwort entsprechend spartanisch mit ca. 600 Bytes auskommt, dann schafft man über eine 10MBit-Leitung locker 2000 Requests/s.

Hier geht es aber nicht um den mathematischen Grenzwert, sondern um den begünstigten Zufall. Die Wahrscheinlichkeit, dass das Hackergebnis bei halbem Schlüsselvorrat postitiv ausfällt ist genauso kritisch zu betrachten, wie diejenige, dass es keine explodierenden Atomkraftwerke gibt, keine Flugzeuge in der Luft zusammenstoßen, keine Eisanbahnen entgleisen etc. "Sicherheit" kann man nur durch Einbau von Unstetigkeiten (Sprünge), Wechsel des Definitions bereiches und den dazugehörigen Methoden sowie drastische Abschaltung (Ende des Definitionsbereiches) beim geringsten Zweifel an der Authenizität erreichen.

Bis denne

Chris

[Philipp Hasenfratz]

Halihallo Chris

Nun, das ist natürlich richtig. Nur könnte man ein bit an die 128 anhängen und das ganze
ist um den Faktor (2^128-1)/150 wieder verbessert.
Ein Bit ist bei mir immer noch = Faktor/Divisor 2 und nicht 2^128 *???*

Wenn man aus einem 128bit einen 129bit Schlüssel generiert, steigt die Anzahl Elemente
im Wertebereich (also die Möglichkeiten) um 2^128-1 bit (Es kommen nochmals genauso
viele Elemente dazu, wie bereits vorhanden => Verdoppelung des Wertebereichs).
Nun gehtst du von einer staatischen Angriffperformance von 150 Angriffen/s aus, also
wird mit einem Bit mehr der Angriffsfaktor um (2^128-1)/150 verbessert.
Oder habe ich einen Denkfehler?

Kommt natürlich auf das Formular an, über das die Anfrage stattfinden muss. Gehen wir mal von Method=Post aus und dass nur die Cookies und zwei Nutzfelder im Request übertragen werden müssen, dann dürfte man da mit ca. 120-200 Bytes auskommen. Und wenn die Antwort entsprechend spartanisch mit ca. 600 Bytes auskommt, dann schafft man über eine 10MBit-Leitung locker 2000 Requests/s.

Ja, die Rechnung klingt logisch. Nur sind 2000 Requests/s auf den meisten Systemen
schon sehr hoch, aber möglich...

Hier geht es aber nicht um den mathematischen Grenzwert, sondern um den begünstigten Zufall. Die Wahrscheinlichkeit, dass das Hackergebnis bei halbem Schlüsselvorrat postitiv ausfällt ist genauso kritisch zu betrachten, wie diejenige, dass es keine explodierenden Atomkraftwerke gibt, keine Flugzeuge in der Luft zusammenstoßen, keine Eisanbahnen entgleisen etc. "Sicherheit" kann man nur durch Einbau von Unstetigkeiten (Sprünge), Wechsel des Definitions bereiches und den dazugehörigen Methoden sowie drastische Abschaltung (Ende des Definitionsbereiches) beim geringsten Zweifel an der Authenizität erreichen.

Ja, aber was ich im letzten Posting bereits zu suggerieren versuchte: Um welchen Preis?
Von der logischen Argumentation aus gesehen hast du recht, nur darf der praktische
Aspekt nicht aussen vor gelassen werden. Natürlich versuchen cracker an die Dokumente
zu gelangen, aber es gibt auch Gründe, dass einfach ein DoS (Denial of Service) erreicht
werden möchte. Durch die Verzögerung verminderst du zwar die Möglichkeit einer
erfolgreichen Bruteforce-Attacke stark, aber du öffnest sozusagen die Türe für eine
DoS. Deinen Rechner könnte man mit dieser Verzögerung selbst mit einem ISDN-Anschluss
mit 64kbit abschiessen.

Ich würde es wie folgt umsetzen:
Nach drei-fünf missglückten Loginversuchen wird der Account temporär für ca.
5 Minuten gesperrt. Somit sind die von dir vorgeschlagenen Verzögerungen ausgeglichen,
um Bruteforce-Attacken zu unterbinden. Aber gleichermassen werden auch
Prozessüberlagerungen stärker unterbunden, was eine DoS auch erschwert.

Wäre dies ein akzeptabler Kompromiss? :-)

Viele Grüsse

Philipp