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
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.