Sicherheit von Passwörtern gegen Cracker

[opi]

Hallo zusammen,

ich habe soeben einen super interessanten Thread im Archiv gelesen:

http://forum.de.selfhtml.org/archiv/2000/10/t23286/#m119358

Ganz besonders hat mir dieser Punkt hier gefallen:

<Zitat>
c) Scheitern beide Methoden, dann wäre der nächst größere Suchraum derjenige, der aus Permutationen bestimmter Zeichen besteht. Jetzt also sind wir bei 26 hoch 8 Zeichen, wenn nur um Kleinbuchstaben verwendet wurden - immerhin schon 209 Milliarden Möglichkeiten, da kommt kein Lexikon mehr mit. Trotzdem: bei 1 Mio Versuche pro Sekunde nur 58 Stunden für alle Kombinationen, im Schnitt also die Hälfte bis zum Erfolg.
Dieser letzte Schritt wird aber massiv schwerer, wenn man das Alphabet erhöht: Schon mit Ziffern und Kleinbuchstaben kommt man auf 36 hoch 8, also 2821 Milliarden, d. h. zehnmal so viel wie ohne Ziffern. Mit Großbuchstaben sind es 62 hoch 8 gleich 2183420 Milliarden oder erneut 77 mal so viel wie zuvor - langsam wird es mehr als die Lebensdauer eines Passworts.
Und selbst dieses Verfahren scheitert definitiv, wenn Du mindestens ein einziges Zeichen verwendest, was weder Buchstabe noch Ziffer ist.
</Zitat>

Ich bin gerade dabei, mir ein Handling für Passwörter einfallen zu lassen, wobei Benutzer die Möglichkeit haben, ihr Passwort selbst du wählen - also kein vorgegebenes Zufallspasswort. Die einzigen Vorgaben, die dem Benutzer von mir vermutlich "aufgezwungen" werden, sind zum Beispiel, dass das Passwort mindestens einen Buchstaben, eine Zahl und eine Mindestlänge von acht Zeichen haben muss.

Nach Betrachung des Zitats kommen dabei schonmal einige Milliarden Möglichkeiten heraus, allerdings sind auch solche Passwörter schnell "geknackt", abhängig von der Schnelligkeit der "Tries", die ein Cracker drauf hat.

Wie schaut das ganze nun aber aus, wenn ich in meinem Skript ein sleep von einer Sekunde einbaue? Eine Sekunde Wartezeit wird einem Benutzer für sein einmaliges Login nicht wehtun und auf diese Weise wären dann nämlich keine ... sagen wir mal ... 1 Million Versuche pro Sekunde möglich, sondern tatsächlich nur ein Versuch pro Sekunde!

Wenn dann zusätzlich noch alle drei Monate das Passwort gewechselt werden muss, wieviel Zeit bleibt dann noch einem Cracker, ein Passwort zu knacken?

Ok, vielleicht war das jetzt ein vollkommen falscher Denkweg, denn wenn der Angreifer 1 Million parallele Jobs startet, holt er die eine Sekunde schnell wieder ein :) aber denkbar unsinnig.

Kann mir jemand mit etwas mehr Erfahrung gedanklich weiterhelfen?

Könnte das ein zusätzliches Sicherheitsfeature sein?

Greez,
opi

[Christoph Zurnieden]

Hi,

ich habe soeben einen super interessanten Thread im Archiv gelesen:
http://forum.de.selfhtml.org/archiv/2000/10/t23286/#m119358

Ja, davon gibt's so einige.

Sogar ich hab mal 'was verbrochen: http://www.selflinux.org/selflinux-devel/html/passwoerter.html ;-)

Aber die Güte des Paßwortes ist nicht das eigentliche Problem sondern der Anwender ist es. Paßworte werden heutzutage nicht mehr geknackt (gut, ein Versuch mit einem Lexikon wird gerne mal gestartet, aber so gut wie gar kein Bruteforce Angriff mehr) sondern geklaut oder gegen etwas Bakschisch erworben oder sogar einfach nur abgeschwätzt.

Gegen die Lexikonangriffe hilft ein gutes Paßwort und gegen Brute Force hilft die Reglementierung des Logins in der Zeit, da hast Du schon ganz Recht. Vor- und Nachteile wurden hier vor einigen Wochen schon einmal diskutiert, einfach mal das Archiv befragen, ich bin im Augenblick zu faul dazu ;-)

Aber ein gutes Paßwort mit Buchstaben, groß und klein, Zahlen und Sonderzeichen, 20-Stellen lang, kann sich doch, mit Verlaub, kein Schwein merken.
Das ist aber auch nicht schlimm, sollen sich die Leute das Paßwort doch ruhig aufschreiben! Nur dann sollte es in die Brieftasche wandern! Darauf wird normalerweise gut geachtet und wenn die verschwindet ist das Paßwort eh das geringste Problem ;-)

so short

Christoph Zurnieden

[opi]

Hallo,

Sogar ich hab mal 'was verbrochen: http://www.selflinux.org/selflinux-devel/html/passwoerter.html ;-)

das werde ich mir jetzt umgehend reinziehen!

Aber die Güte des Paßwortes ist nicht das eigentliche Problem sondern der Anwender ist es ... sondern geklaut oder gegen etwas Bakschisch erworben oder sogar einfach nur abgeschwätzt.

dagegen kann man leider als Administrator nicht viel machen, wenn der Anwender geschwätzig ist! Was interessant bleibt, sind die Möglichkeiten, die ich vor Angriffen habe.

Gegen die Lexikonangriffe hilft ein gutes Paßwort und gegen Brute Force hilft die Reglementierung des Logins in der Zeit, da hast Du schon ganz Recht.

Aber ein gutes Paßwort mit Buchstaben, groß und klein, Zahlen und Sonderzeichen, 20-Stellen lang, kann sich doch, mit Verlaub, kein Schwein merken.

und genau auf diese zwei Punkte wollte ich hinaus! Es ist unzumutbar, einem Benutzer, der sich sowieso schon im Durchschnitt drei Passwörter merken muss - mal jetzt so dahingeschrieben -, solche Passwortanforderungen aufzudrängen, Beispiel: te92;M{Ny3

Es sei, man benutzt soetwas wie Single Sign On, aber wer benutzt das schon zu Hause?!

Deshalb halte ich einen Delay von einer Sekunde garnicht so schlecht! In wenigen Jahren vielleicht sogar zwei Sekunden, wenn die Rechner wieder etwas schneller sind :)

Greez,
opi

[Marc Reichelt]

Hallo opi,

Deshalb halte ich einen Delay von einer Sekunde garnicht so schlecht! In wenigen Jahren vielleicht sogar zwei Sekunden, wenn die Rechner wieder etwas schneller sind :)

Um noch sicherer zu gehen könntest du in PHP eine zusätzliche Sicherheit einprogrammieren. Wenn der Passwortversuch startet, erstellst du eine bestimmte Datei stellvertretend für diesen Benutzer, am Besten [optional] mit dem aktuellen Timestamp als Inhalt. Nach einer Wartezeit von 1-2 Sekunden und der eigentlichen Überprüfung löschst du diese wieder.
Zu Beginn dieses Skripts wird am Anfang abgefragt, ob die Datei existiert, und wenn sie existiert, so wird ein Fehler ausgegeben - schließlich kann der gleiche Benutzer nicht zur selben Zeit das Passwort zweimal eingeben, oder es ist ein Roboter... ;-)

Ich denke dass man so doch einen ganz wirksamen Schutz erstellen kann.
Zur Sicherheit sollte man hier mit flock() arbeiten, und die Sache mit dem Timestamp ist insofern sinnvoll, da es seltene Fälle geben kann (!) in der die Datei anschließend nicht gelöscht wird (auf Grund von irgendwelchen Fehlern etc.).

Bis dann!

Marc Reichelt || http://www.marcreichelt.de/

[opi]

Hallo,

Um noch sicherer zu gehen könntest du in PHP eine zusätzliche Sicherheit einprogrammieren. Wenn der Passwortversuch startet, erstellst du eine bestimmte Datei stellvertretend für diesen Benutzer, am Besten [optional] mit dem aktuellen Timestamp als Inhalt. Nach einer Wartezeit von 1-2 Sekunden und der eigentlichen Überprüfung löschst du diese wieder.
Zu Beginn dieses Skripts wird am Anfang abgefragt, ob die Datei existiert, und wenn sie existiert, so wird ein Fehler ausgegeben - schließlich kann der gleiche Benutzer nicht zur selben Zeit das Passwort zweimal eingeben, oder es ist ein Roboter... ;-)

Das ist ein sehr guter Tipp! Dankeschön! Das ist allerdings nicht nur mit php zu realisieren! In meinem Fall Perl!

Zur Sicherheit sollte man hier mit flock() arbeiten, und die Sache mit dem Timestamp ist insofern sinnvoll, da es seltene Fälle geben kann (!) in der die Datei anschließend nicht gelöscht wird (auf Grund von irgendwelchen Fehlern etc.).

Flock wird hier nicht unbedingt benötigt, denn der Timestamp reicht erstmal zum auslesen...

Gute Idee!

Greez,
opi

[Marc Reichelt]

Hallo opi,

Zur Sicherheit sollte man hier mit flock() arbeiten, und die Sache mit dem Timestamp ist insofern sinnvoll, da es seltene Fälle geben kann (!) in der die Datei anschließend nicht gelöscht wird (auf Grund von irgendwelchen Fehlern etc.).

Flock wird hier nicht unbedingt benötigt, denn der Timestamp reicht erstmal zum auslesen...

Nun ja, so etwas wie einen flock wirst du brauchen falls das gleiche Skript mehrfach aufgerufen wird und einige (wenige) Instanzen versuchen gleichzeitig auf die gleiche Datei zu schreiben, weil ein paar Zeilen vorher ja "versichert" wurde, dass die Datei nicht existiert...

Stichwort Murphys Gesetz: Alles was schief gehen kann, wird schief gehen. Es ist nur eine Frage der Zeit, bis dieser Fall eintritt.
Und der kann bei gezielter Manipulation sehr schnell eintreten.

Gute Idee!

Danke, ist ja auch nicht von mir! *lol*
Haben tausend Leute vor mir auch schon gehabt, die Idee...

Bis dann!

Marc Reichelt || http://www.marcreichelt.de/

[opi]

Hallo,

Nun ja, so etwas wie einen flock wirst du brauchen falls das gleiche Skript mehrfach aufgerufen wird und einige (wenige) Instanzen versuchen gleichzeitig auf die gleiche Datei zu schreiben, weil ein paar Zeilen vorher ja "versichert" wurde, dass die Datei nicht existiert...

Stimmt schon! Es werden solange alle Requests abgewiesen, bis der Timestamp veraltet ist und der erste Prozess kommt und den Stempel aktualisieren möchte!

Danke, ist ja auch nicht von mir! *lol*
Haben tausend Leute vor mir auch schon gehabt, die Idee...

Na dann danke für das Weiterreichen des Tipps :)

Greez,
opi

[Christoph Zurnieden]

Hi,

dagegen kann man leider als Administrator nicht viel machen, wenn der Anwender geschwätzig ist! Was interessant bleibt, sind die Möglichkeiten, die ich vor Angriffen habe.

Ich verstehe nicht ganz, warum möchtest Du das nicht als Angriff ansehen?

Vielleciht solltest Du Dir mal den Sinn und Zweck und vor allem die Begrenzung eines Logins zu Gemüte führen:

Ein Login hat den Sinn und Zweck nur die Leute reinzulassen, die die beiden magischen Worte wissen: Username und Paßwort. Die natürliche Begrenzung ist dann halt auch die Tatsache, das Du nachher nur weißt, das Usernaem und Paßwort korrekt sind und zusammengehören. Mehr nicht.

Somit kannst Du überhaupt nicht unterscheiden, wer das Login getätigt hat. Wenn ein Haufen Fehlversuche in kurzer Zeit anbranden ist das ein Angreifer? Ist das _jedesmal_ ein Angreifer oder ist der eigentliche User auch darunter?

Wenn Du nun, wie Du das vorhast und wie das auch durchaus üblich ist, nach jedem Fehlversuch drei Sekunden Pause einlegst und nach drei Fehlversuchen 5 Minuten und vielleicht sogar nach 3x3 Fehlversuchen den Account blockierst dann setzt Du den User der Möglichkeit eines Angriffes aus, der den Zugriff des Users über längere Zeit blockiert. Sowas nennt man dann (D)DoS. Und wenn besagter User ein _zahlender_ Kunde ist, vielleicht sogar einer mit Regressansprüchen ...
Einzige Lösung bei solchem massivem Befall ist übrigens die Installation eines neuen Accounts. (und ein "DROP" in der L7-FW natürlich usw)

Wie Du siehst reicht alleine schon die Kenntnis des Usernamens aus erheblichen Schaden zuzufügen, man muß das Paßwort gar nicht erst kennen. Und so ein Usernamen erhält nie die nötige Beachtung, wie das Paßwort obwohl beide in diesem Fall gleichwertig sind.

Es ist ein recht gefährlicher Trugschluß ähnlich dem, das die leicht austauschbaren Programme und Scripte einer OS-Installation wichtiger seien als das /home-Verzeichnis. Alles außer dem Homeverzeichnis ist fix und kannst Du bequem vom Image aufziehen; beim kleinstem Verdacht oder meinetwegen auch schon ohne irgendeinen Verdacht rein nach dem Zufallsprinzip. Die Daten des Home-Verzeichnisses sind es jedoch, die wertvoll sind!

und genau auf diese zwei Punkte wollte ich hinaus! Es ist unzumutbar, einem Benutzer, der sich sowieso schon im Durchschnitt drei Passwörter merken muss - mal jetzt so dahingeschrieben -, solche Passwortanforderungen aufzudrängen, Beispiel: te92;M{Ny3

Nein ist es überhaupt nicht, wenn Du ihn wie von mir beschrieben über den Umgang damit aufklärst. Warum hast Du das aus dem Zitat gestrichen, wo es doch meine Kernaussage war?

Sich ein Paßwort nicht merken zu können ist kein technisches Problem, daher gibt es auch keine technische Lösung. Einfach aufschreiben und sorgfältig wie den eig'nen Augapfel hüten.

Es sei, man benutzt soetwas wie Single Sign On, aber wer benutzt das schon zu Hause?!

"Single Sign On" ist sicherheitstechnisch diskutabel. Hat seine Vor- aber auch seine Nachteile.

Deshalb halte ich einen Delay von einer Sekunde garnicht so schlecht! In wenigen Jahren vielleicht sogar zwei Sekunden, wenn die Rechner wieder etwas schneller sind :)

Das das _alleine_ keine Lösung ist habe ich Dir ja oben nahegelegt, das Problem läßt sich leider nicht ganz aus der Welt schaffen. Marc Reichelt war so nett Dir Tipps zur Implementation der Pause (üblich sind, wie o.a. meist drei Sekunden) zu geben, das ist die einzige technische Möglichkeit, die Dir gegeben ist und trotz o.a. Nachteile auch von mir empfohlen wird, da die Wahrscheinlichkeit eines (D)DoS doch _sehr_ gering ist.

so short

Christoph Zurnieden

[opi]

Hallo,

entschuldige bitte, aber du bist ein bißchen zu voreilig.

dagegen kann man leider als Administrator nicht viel machen, wenn der Anwender geschwätzig ist! Was interessant bleibt, sind die Möglichkeiten, die ich vor Angriffen habe.

Ich verstehe nicht ganz, warum möchtest Du das nicht als Angriff ansehen?

Vielleicht habe ich mich zugegebenermaßen nicht richtig ausgedrückt, es ist aber genauso gut möglich, dass du mich nicht verstanden hast.

Wenn ein Benutzer "auf eigene Verantworung" seinen Benutzernamen und sein Passwort preis gibt und seine Daten von einer dritten Person gelöscht werden, dann war das kein Angriff auf mein System, es sei, die Person versucht Daten zu löschen, die nicht mehr dem Loginuser gehören.

Wenn aber ein Benutzer gewisse Sicherheitsrichtilien aktzeptieren musste und er seinen Benutzernamen und sein Passwort trotzallem preis gibt UND ich auf meiner Loginseite den Hinweis gebe, dass der Zugriff/Zutritt nur für berechtigte Personen gilt, dann ist es ein Angriff auf mein System!

Aber in beiden Fällen bleibt es unbestreitbar, dass ich als Administrator zunächst _nichts_ dagegen unternehmen kann, aller aller höchstens danach!

Dann verbleiben nur noch Angriffe von Crackern - diverse Angriffe von Intern jetzt mal ausgeschlossen -, die durch BruteForce oder anderen Methoden versuchen, in mein System zu einzudringen!

Vielleciht solltest Du Dir mal den Sinn und Zweck und vor allem die Begrenzung eines Logins zu Gemüte führen:

Weshalb? Weil du der Ansicht bist, dass ich das nicht weiß? Diese Ausführung war wirklich nicht notwendig! Ich versuche trotzdem Mal darauf einzugehen.

Somit kannst Du überhaupt nicht unterscheiden, wer das Login getätigt hat. Wenn ein Haufen Fehlversuche in kurzer Zeit anbranden ist das ein Angreifer? Ist das _jedesmal_ ein Angreifer oder ist der eigentliche User auch darunter?

Wenn der eigentliche User 1000 Loginversuche pro Sekunde durchführt, dann mag er zwar ein User mit einem berechtigtem Zugriff sein, aber er greift dennoch mein System an, durch die Last, die er erzeugt.

Wenn Du nun, wie Du das vorhast und wie das auch durchaus üblich ist, nach jedem Fehlversuch drei Sekunden Pause einlegst und nach drei Fehlversuchen 5 Minuten und vielleicht sogar nach 3x3 Fehlversuchen den Account blockierst dann setzt Du den User der Möglichkeit eines Angriffes aus, der den Zugriff des Users über längere Zeit blockiert. Sowas nennt man dann (D)DoS.

Ich habe niemals behauptet, den User zu sperren!! (s.o. voreilig)

NT-Zeiten mögen vorrüber sein, in denen man einen Kollegen ärgern konnte, indem man sich drei Mal mit seinem Account und falschem Passwort versuchte einzuloggen. ;-)

Das mag es zwar noch geben, ist aber völlig unzumutbar!

Und wenn besagter User ein _zahlender_ Kunde ist, vielleicht sogar einer mit Regressansprüchen ...

Damit habe ich nicht so viel zu tun, _aber_ der Kunde wird sicherlich froh sein, wenn er weiß, dass ich es einem Cracker 3x2mio Mal schwerer gemacht habe - obwohl ihm die besagte Technik egal sein mag -, auf seine Daten zugreifen zu können! Falls er einer dieser grausam unzufriedenen Kunden sein sollte, dann hat er sich doch ganz bestimmt die AGBs/Nutzungsbediengungen oder was auch immer vorher durchgelesen :-)

Spaß beiseite! Natürlich muss darauf Rücksicht genommen werden, aber nicht zu Kosten des Risikos. Wie weit nun das Risiko eingeschränkt wird und welche Maßnahmen hierzu ergriffen werden... da mag es etliche Lösungsansätze geben. Meine Zeitverzögerung sollte eines dieser Möglichkeiten sein und ich wollte nur wissen, ob diese Möglichkeit eine gute Möglichkeit ist.

Du hast ja auch geschrieben ... üblich sind 3 Sekunden ... also ist diese Methode nicht neu.

Wie Du siehst reicht alleine schon die Kenntnis des Usernamens aus erheblichen Schaden zuzufügen, man muß das Paßwort gar nicht erst kennen. Und so ein Usernamen erhält nie die nötige Beachtung, wie das Paßwort obwohl beide in diesem Fall gleichwertig sind.

Natürlich ist schon der Username kritisch. Aber genau deshalb mache ich mir Gedanken um dieses Thema. Falls sich ein User nicht anmelden kann, weil sein Username gerade attakiert wird, dann hat er die Möglichkeit, den Support anzurufen. Die Möglichkeit zu ignorieren, höhere Sicherheit erzielen zu können, nur damit sich der User problemlos einloggen kann, steht _meiner_Ansicht_ nach nicht zur Debatte. Wie schon geschrieben, sollten gegebene Nutzerrichtlinien das rechtliche abdecken.

Aber mit dieser Aussage lege ich mir natürlich selbst ein Ei, denn dann muss ich den Benutzer auch dazu auffordern, ein Passwort mit Zahlen, Klein- und Großbuchstaben sowie Sonderzeichen zu verwenden.

Es ist ein recht gefährlicher Trugschluß ähnlich dem, das die leicht austauschbaren Programme und Scripte einer OS-Installation wichtiger seien als das /home-Verzeichnis. Alles außer dem Homeverzeichnis ist fix und kannst Du bequem vom Image aufziehen; beim kleinstem Verdacht oder meinetwegen auch schon ohne irgendeinen Verdacht rein nach dem Zufallsprinzip. Die Daten des Home-Verzeichnisses sind es jedoch, die wertvoll sind!

Das weicht mir jetzt zu stark vom Thema ab.

und genau auf diese zwei Punkte wollte ich hinaus! Es ist unzumutbar, einem Benutzer, der sich sowieso schon im Durchschnitt drei Passwörter merken muss - mal jetzt so dahingeschrieben -, solche Passwortanforderungen aufzudrängen, Beispiel: te92;M{Ny3

Nein ist es überhaupt nicht, wenn Du ihn wie von mir beschrieben über den Umgang damit aufklärst.

da isses ja, mein gelegtes Ei :-)

(üblich sind, wie o.a. meist drei Sekunden) zu geben, das ist die einzige technische Möglichkeit, die Dir gegeben ist und trotz o.a. Nachteile auch von mir empfohlen wird, da die Wahrscheinlichkeit eines (D)DoS doch _sehr_ gering ist.

Dankeschön! Die Diskussion hat mir weitergeholfen!

Jetzt muss ich mich aber sputen, wollte noch einen anderen Thread aufmachen. Bis dann ... :)

Greez,
opi

[Christoph Zurnieden]

Hi,

entschuldige bitte, aber du bist ein bißchen zu voreilig.

Das ist im Sicherheitsbereich immer besser als zu spät! ;-)

Wenn ein Benutzer "auf eigene Verantworung" seinen Benutzernamen und sein Passwort preis gibt und seine Daten von einer dritten Person gelöscht werden, dann war das kein Angriff auf mein System, es sei, die Person versucht Daten zu löschen, die nicht mehr dem Loginuser gehören.

In diesem Fall ist ein Login zwar bequem aber ziemlich nutzlos. Dafür wären dann mehrschichtige Verschlüsselungsmethoden deutlich besser.

Aber in beiden Fällen bleibt es unbestreitbar, dass ich als Administrator zunächst _nichts_ dagegen unternehmen kann, aller aller höchstens danach!

Naja, wofür gibt's denn Verträge? ;-)

Dann verbleiben nur noch Angriffe von Crackern - diverse Angriffe von Intern jetzt mal ausgeschlossen -

Äh, nein. Du darfst erstmal _nichts_ ausschließen. Vor allem aber keinen Angriffe von innen, denn das sind statistisch die häufigsten Fälle!

die durch BruteForce oder anderen Methoden versuchen, in mein System zu einzudringen!

Wie gesagt, BruteForce ist nicht mehr en vogue, da es mittlerweile bessere Methoden gibt und beim Login auch durch die hier im Thread beschriebene Methode entgegengearbeitet werden kann.

Vielleciht solltest Du Dir mal den Sinn und Zweck und vor allem die Begrenzung eines Logins zu Gemüte führen:

Weshalb?

Weil das eine schöne rethorische Frage ist, die meinen Absatz über Sinn und Unsinn eines Logins hübsch einleitete.

Weil du der Ansicht bist, dass ich das nicht weiß?

Da ich Deinen Wissensstand nicht kenne muß ich davonausgehen, ja.

Diese Ausführung war wirklich nicht notwendig!

Nochmal: woher soll ich das wissen?

Somit kannst Du überhaupt nicht unterscheiden, wer das Login getätigt hat. Wenn ein Haufen Fehlversuche in kurzer Zeit anbranden ist das ein Angreifer? Ist das _jedesmal_ ein Angreifer oder ist der eigentliche User auch darunter?

Wenn der eigentliche User 1000 Loginversuche pro Sekunde durchführt, dann mag er zwar ein User mit einem berechtigtem Zugriff sein, aber er greift dennoch mein System an, durch die Last, die er erzeugt.

Ah, ich sehe, ich habe das nicht sauber erklärt, sorry.
Wenn so ein Angriff getätigt wird, erfolgt das in fast allen Fällen als verteilter Angriff, also von einem Wust verschiedener IPs. Das können bei ernsthaften Angriffen, z.B. wenn Du erpreßt wirst, durchaus einige zehntausend sein. Wenn Du jetzt zur Identifikation nichts anderes als ein Standard-Login hast, kannst Du den regulären Benutzer nicht identifizieren, er ist ausgesperrt und somit hat das DDoS Erfolg.

Ja, sowas ist extrem unwahrscheinlich und kann auch meist mit einem Telephonat und einem neuem Account geregelt werden. Blöd natürlich wenn es eine zeitkritische Anwendung war.

Ich habe niemals behauptet, den User zu sperren!! (s.o. voreilig)

Du magst es nicht direkt tun, effektiv ist der Benutzer aber ausgesperrt, denn er kann sich durch das (D)DoS nicht einloggen.

NT-Zeiten mögen vorrüber sein, in denen man einen Kollegen ärgern konnte, indem man sich drei Mal mit seinem Account und falschem Passwort versuchte einzuloggen. ;-)

Das ist nicht vergleichbar, da Du hier nicht bloß einen hast, der Dich ärgert, sondern einen Riesenhaufen gleichzeitiger Zugriffe. Da reicht schon alleine die Pause zwischen zwei Fehllogins den regulären Benutzer auszusperren.

Da die Wahrscheinlichkeit dafür sehr gering ist reicht zwar das Vorgehen mit der Pause, der oben beschriebene Nachteil verschwindet damit jedoch nicht.

Das mag für Dich heute völlig egal sein, aber ist es das morgen auch?

Damit habe ich nicht so viel zu tun, _aber_ der Kunde wird sicherlich froh sein, wenn er weiß, dass ich es einem Cracker 3x2mio Mal schwerer gemacht habe - obwohl ihm die besagte Technik egal sein mag -, auf seine Daten zugreifen zu können!

Nein, das ist ihm völlig egal, glaub's mir, dsa interessiert ihn nicht die Bohne. Er will seine Leistung haben und wie Du das anstellst geht ihm, mit Verlaub, am Arsch vorbei.

Falls er einer dieser grausam unzufriedenen Kunden sein sollte, dann hat er sich doch ganz bestimmt die AGBs/Nutzungsbediengungen oder was auch immer vorher durchgelesen :-)

Man merkt wirklich, das Du nicht auf zahlende Kunden angewiesen bist ;-)

Spaß beiseite!

Nö, wieso denn?
Auch wenn wir beide wohl deutsch sein mögen, so zwingt uns das doch nicht automatisch gleich zur Humorlosigkeit, oder?

Natürlich muss darauf Rücksicht genommen werden, aber nicht zu Kosten des Risikos. Wie weit nun das Risiko eingeschränkt wird und welche Maßnahmen hierzu ergriffen werden... da mag es etliche Lösungsansätze geben.

Naja, im Bereich wirklicher _Lösungen_ sieht's eher mau aus.
Die Möglichkeit beim reinem Login ist nur das Päuschen, wenn Du das sicherere machen willst müßtest Du etwas anderes als das Standardlogin einsetzen. Dafür gibt es dann wieder einige, teilweise sogar ganz gute Lösungsansätze.

Meine Zeitverzögerung sollte eines dieser Möglichkeiten sein und ich wollte nur wissen, ob diese Möglichkeit eine gute Möglichkeit ist.

Und um dies entscheiden zu können bekamst Du Vor- und Nachteile der Methode serviert. Warum Du darauf unwirsch reagierst kann ich nicht so ganz nachvollziehen.
Sollte es an meinem Stil liegen bitte ich höflichst um Entschuldigung es lag nicht in meiner Absicht.

Natürlich ist schon der Username kritisch. Aber genau deshalb mache ich mir Gedanken um dieses Thema. Falls sich ein User nicht anmelden kann, weil sein Username gerade attakiert wird, dann hat er die Möglichkeit, den Support anzurufen. Die Möglichkeit zu ignorieren, höhere Sicherheit erzielen zu können, nur damit sich der User problemlos einloggen kann, steht _meiner_Ansicht_ nach nicht zur Debatte.

Natürlich nicht, habe ich ja auch nie behauptet.
Allerdings ist die Kurve nicht linear, die die Sicherheit in Abhängigkeit zu den Methoden mißt. Das Maxima (wenn es denn überhaupt nur eines gibt) liegt irgendwo in der Mitte. Der Nutzen eines Systems liegt ja nicht einfach darin, nicht angreifbar zu sein, denn das derart beste System ist eines, das im Tresor steht und sonst nirgendwo angeschlossen ist. Dieses System ist extrem sicher, vor allem gegen Angriffe aus dem Netz, aber der Nutzen geht doch schwer gegen Null, oder?
Auf der anderen Seite steht der Nutzer, dem es am liebsten wäre, wenn überhaupt nix zu tun wäre, kein Login, kein Chipkarte, nix. Einfach einschalten und loslegen.
Und jetzt bist Du dran und mußt Dich ganz vorsichtig dazwischen lavieren, damit einerseits dem User nichts zuviel wird (anrufen zu müssen kann im Einzelfall schon zuviel sein!) und andererseits dem Angreifer nichts zu leicht gemacht wird.
Es ist eine Schaden/Nutzen Berechnung, wobei noch zusätzlich zu bedenken ist, das bei möglichem hohem Schaden auch die Wahrscheinlichkeit eines massiven Angriffs steigt. Die Zahl der Erpressungen von auf ungestörtem Zugang auf und vom  Internet angewiesenen Firmen steigt stark. Das sind auch keine Scriptkiddies mehr, die dsa tun, sondern professionelle Banden.

Wie schon geschrieben, sollten gegebene Nutzerrichtlinien das rechtliche abdecken.

Bitte denk' bei AGBs usw daran, das einige Formulierungen nicht unbedingt rechtlich bindend sind. Bist Du nicht selber Vertragsanwalt würde ich unbedingt einen konsultieren. Ist zwar nicht billig aber sehr nützlich.
Und nimm das nicht wieder als Vorwurf, es ist keiner. Du bist schließlich nicht der einzige, der hier mitliest.

Aber mit dieser Aussage lege ich mir natürlich selbst ein Ei, denn dann muss ich den Benutzer auch dazu auffordern, ein Passwort mit Zahlen, Klein- und Großbuchstaben sowie Sonderzeichen zu verwenden.

Und wie von mir beschrieben ist das absolut kein Problem. Und wenn Du eine andere Meinung wünscht: Bruce Schneier schlug das auch mal vor. Er ist auch ein Anhänger des SingleSignOn:http://www.schneier.com/passsafe.html.

Die Daten des Home-Verzeichnisses sind es jedoch, die wertvoll sind!

Das weicht mir jetzt zu stark vom Thema ab.

Tut mir leid, aber das ist in diesem Forum nicht unüblich ;-)

(üblich sind, wie o.a. meist drei Sekunden) zu geben, das ist die einzige technische Möglichkeit, die Dir gegeben ist und trotz o.a. Nachteile auch von mir empfohlen wird, da die Wahrscheinlichkeit eines (D)DoS doch _sehr_ gering ist.

Dankeschön! Die Diskussion hat mir weitergeholfen!

Nu, wer war hier jetzt voreilig? ;-)

Jetzt muss ich mich aber sputen, wollte noch einen anderen Thread aufmachen. Bis dann ... :)

Wie, kein multithreading? ;-)

so short

Christoph Zurnieden

[opi]

Hallo,

Äh, nein. Du darfst erstmal _nichts_ ausschließen. Vor allem aber keinen Angriffe von innen, denn das sind statistisch die häufigsten Fälle!

Aber Angriffe von Innen kann ich besser analysieren. Angriffe von Aussen eher schlechter, aber darauf komme ich noch später. [1]

Weil du der Ansicht bist, dass ich das nicht weiß?

Da ich Deinen Wissensstand nicht kenne muß ich davonausgehen, ja.

ok!

Ah, ich sehe, ich habe das nicht sauber erklärt, sorry.
Wenn so ein Angriff getätigt wird, erfolgt das in fast allen Fällen als verteilter Angriff, also von einem Wust verschiedener IPs.

[1] Das sehe ich leider nicht im erstem Moment, wenn ein Proxy dazwischen hängt und das wird sicherlich in den häufigsten Fällen so sein.

Das ist nicht vergleichbar, da Du hier nicht bloß einen hast, der Dich ärgert, sondern einen Riesenhaufen gleichzeitiger Zugriffe. Da reicht schon alleine die Pause zwischen zwei Fehllogins den regulären Benutzer auszusperren.

Um nochmal auf den Usernamen zurückzukommen. Der Angreifer muss diesen erstmal herausbekommen und ich https anfordere, ist das auch nicht so einfach.

Man merkt wirklich, das Du nicht auf zahlende Kunden angewiesen bist ;-)

Nein wirklich nicht. Ich entwickel - und da mag ich mir einen Pluspunkt geben - ein OpenSource Produkt.

Spaß beiseite!

Nö, wieso denn?
Auch wenn wir beide wohl deutsch sein mögen, so zwingt uns das doch nicht automatisch gleich zur Humorlosigkeit, oder?

Jupp :)

Natürlich muss darauf Rücksicht genommen werden, aber nicht zu Kosten des Risikos. Wie weit nun das Risiko eingeschränkt wird und welche Maßnahmen hierzu ergriffen werden... da mag es etliche Lösungsansätze geben.

Naja, im Bereich wirklicher _Lösungen_ sieht's eher mau aus.

Da hast du auch wieder Recht. Von Lösungen kann man hier nicht sprechen, eher von Vorsichtsmaßnahmen!

Wie schon geschrieben, sollten gegebene Nutzerrichtlinien das rechtliche abdecken.

Bitte denk' bei AGBs usw daran, das einige Formulierungen nicht unbedingt rechtlich bindend sind.

Da ich ein OpenSource Produkt entwickel, wird dieser Part recht einfach werden, da die Klausel "Nutzung auf eigene Verantwortung! Der Entwickler übernimmt keine Haftung!" :) schon _fast_ alles abdeckt.

Die Daten des Home-Verzeichnisses sind es jedoch, die wertvoll sind!

Das weicht mir jetzt zu stark vom Thema ab.

Tut mir leid, aber das ist in diesem Forum nicht unüblich ;-)

Daran habe ich mich schon gewöhnt und es ist ok. Ich komme damit zurecht.

Dankeschön! Die Diskussion hat mir weitergeholfen!

Nu, wer war hier jetzt voreilig? ;-)

Das war mein ernst!

Jetzt muss ich mich aber sputen, wollte noch einen anderen Thread aufmachen. Bis dann ... :)

Wie, kein multithreading? ;-)

Ich habe schon gesehen, dass du auch dort deinen Senf ;-) abgegeben hast, ich bin mal gespannt!

Schönen Abend noch.

Greez,
opi

[Christoph Zurnieden]

Hi,

Aber Angriffe von Innen kann ich besser analysieren.

Wenn wirklich einer stinkig ist, dann nützt Dir die schönste Analyse nix, dann bist Du "tot". Du weißt dann zwar ganz genau wer Dich umngebracht hat und wie, aber es ist um ein Kleines zu spät. Angriffen von innen kann man durch Software nicht begegnen, da müssen gute Schlösser an die Türen und eine räumlich weit verteilte Backuphaltung.

Angriffe von Aussen eher schlechter,

Bei denen weißt Du aber zumindest vorher was zu erwarten ist. Bei genügend dicker Leitung könntest Du sogar mit einem DDoS mittlerer Güte zurechtkommen. Allerdings ist das natürlich mit nicht unerheblichem finanziellem Aufwand verbunden.

[1] Das sehe ich leider nicht im erstem Moment, wenn ein Proxy dazwischen hängt und das wird sicherlich in den häufigsten Fällen so sein.

Ich wollte nur eine möglichem Einwand vorkommen. Das Dein Webserver nicht direkt an's Netz angeschlossen ist hatte ich angenommen. Allerdings dachte ich da eher an eine vollständige Firewall und nicht an einen einsamen Proxy?
Oder bin ich da einfach schon zu paranoid? ;-)

Um nochmal auf den Usernamen zurückzukommen. Der Angreifer muss diesen erstmal herausbekommen

Deshalb ja auch mein Hinweis darauf, das die Güte der Usernamen eine große Rolle spielt, da es die Hälfte des Logins ist. Das wird meist unterschätzt.

Denn so schwer ist ein Username nicht herauszubekommen, meinen Usernamen bei GMX kennst Du ja auch schon.

und ich https anfordere, ist das auch nicht so einfach.

HTTPS nützt hier nix.

Man merkt wirklich, das Du nicht auf zahlende Kunden angewiesen bist ;-)

Nein wirklich nicht. Ich entwickel - und da mag ich mir einen Pluspunkt geben - ein OpenSource Produkt.

Das kommt hier nicht so ganz raus: Du postest hier anonym (Dein gutes Recht, wie ich finde, auch wenn mancher hier das anders sieht. Aber auch nur dann, wenn der Nickname des anonym postenden auch "Anonymous" ist. Isses nich' lustich? *sigh* ;-) und ohne Link. Falls Du Dich einfach nicht traust: soviel Werbung sollte hier noch erlaubt sein.

Da ich ein OpenSource Produkt entwickel, wird dieser Part recht einfach werden

Das glaubst auch nur Du. Die Anwälte, ich korrigiere, die Spitzenanwälte der FSF versuchen seit nunmehr, na, 3(?) Jahren die GPL in's europäische Recht zu übesetzen.

da die Klausel "Nutzung auf eigene Verantwortung! Der Entwickler übernimmt keine Haftung!" :) schon _fast_ alles abdeckt.

Derartige Klauseln sind in Deutschland nicht möglich. Du kannst hier Deine Haftung nicht völlig abgeben, denn das würde unter anderem bedeuten Deine Urheberschaft abzugeben und das geht nunmal logischerweise nicht.
Aber setz' Dich wieder hin, das gilt alles nur bei Vorsatz. Im Falle Software wäre das also ein Trojaner, Virus, Wurm oder ähnlicher Schädling. Alles andere fällt weg, da Du ja jederzeit eine Wandlung anbieten kannst: Ware gegen Kaufpreis.
Rein theoretisch würde das sogar bedeuten, das Du gefahrlos eine Eigenschaft zusichern kannst. Denn kann die Software das nicht gibt's halt das Geld zurück. Allerdings würde ich mich aufgrund dieser Meinung vor kein deutsches Gericht wagen, ja, noch nicht einmal näher als die 5km jetzt! ;-)

Dankeschön! Die Diskussion hat mir weitergeholfen!

Nu, wer war hier jetzt voreilig? ;-)

Das war mein ernst!

Tempus fugit.

Ich habe schon gesehen, dass du auch dort deinen Senf ;-) abgegeben hast, ich bin mal gespannt!

Naja, was hast Du erwartet, bei dem Hinweis? ;-)

Aber mein Kommentar dort ging auch nicht auf Dich. Mich nervt es halt nur, das sich die Leute kaum mehr die Mühe machen Fehler richtig abzufangen sondern immer gleich die Klappe vollständig zumachen müssen. Würde ja sonst Mühe machen? *grummel*
(obwohl: bei fehlgeschlagener Speicherallocation, malloc() o.e., ist heutzutage wahrscheinlich mehr kaputt, das kann dann ein einfaches Programm eh nicht mehr reparieren, da kann man sich dann höchstens noch höflich verabschieden.)

so short

Christoph Zurnieden

[Elderan]

Hallo,

Wie schaut das ganze nun aber aus, wenn ich in meinem Skript ein sleep von einer Sekunde einbaue? Eine Sekunde Wartezeit wird einem Benutzer für sein einmaliges Login nicht wehtun und auf diese Weise wären dann nämlich keine ... sagen wir mal ... 1 Million Versuche pro Sekunde möglich, sondern tatsächlich nur ein Versuch pro Sekunde!

Gehen wir davon aus, man könnte 1 Mio PW's por Sekunde testen. Sagen wir der Benutzername hat 8 Zeichen/Byte, das PW hat nochmal 8 Byte.
Zusammen 16 Byte.
Also müsste er pro Sekunde 1 000 000 * 16 Byte senden, das wären schon 16 MB/s.
Dazu kommt noch der HTTP Header.

Dieser ist ~750 Byte und ~500 Byte groß (Empfangs und Senderichtung), also 1250 * 1 000 000 Byte/s, bzw. 1,25 GB/s.

Dies wäre in einem schnellen Netzwerk durchaus möglich, aber im Web? Und falls der Server diese Geschwindigkeit für 1 Person aufbringen könnte, dann würde es doch bestimmt auffallen.

Dann kommt noch das normale Formular + Ob das Passwort richtig oder falsch war.
Dort entstehen pro Aufruf wieder ein paar tausend Byte traffic.

Falls man über die Website versucht das PW zu knacken, hat man ca. 80 bis 240 Key/s, und mehr als ein Wörterbuch sollte man so nicht durchtesten.
Sonst wird das auch viel zu auffällig in der Log.

Also du siehst, diese 1 Mio/s ist, wenn man das verschlüsselte Passwort lokal auf dem PC hat.
Dort kann man ohne probleme mit einem normalen, neuem PC um die 15 bis 20 Mio/Keys pro Sek testen, je nach OS und Verschlüsselungsart.
Ein 8 stellen PW (a-z 0-9) knackt man so in ca. 20 Stunden.
Benutzt man noch groß Buchstaben, also 62^8 braucht man ca. 1500 Stunden.
Dies ist noch nicht otopisch, denn der Angreifer kann ja evt. mehrere und vorallem schnellere PC's zur Verfügung haben. Hätte er nur 10 Computer zur Verfügung, dann wären es 150 Stunden oder 6 Stunden. Und wenn man bedenkt man kann durch einen Wurm mehrere hundert/tausend PC's infizieren und damit die Rechenleistung bündeln...

Mit "Deep Crack", einem spezial PC zum Entschlüssel von DES, schaffte man so ca. 90 Mrd. Schlüssel _pro Sekunde_.
Hätte man soetwas zur Verfügung, dann könnte man damit in ca. 20 Minuten das Passwort knacken.

Also wie du siehst, dass jmd. über das Loginformular versucht das PC zu knacken ist eher unwahrscheinlich, und sofern man kein Wort aus dem Wörterbuch benutzt (fast) unmöglich.
Darum versucht ein Angreifer immer die verschlüsselte Version zu bekommen, was oft leichter ist als man denkt.
Darum sollte das Passwort auch noch dann sicher sein, wenn es ein Cracker in die finger bekommt.

Eine andere Möglichkeit sind "Passphrase". Hierzu werden Sätze (mit Groß- und Kleinschreibung) benutzt, die keinen Sinn ergeben:

Bsp:
Im SelfHTML Forum werden kostenlos atomare Vögel produziert.

Dies kann man sich gut merken, und es ist auch ausreichend sicher.

Allerdings ein Cracker wird sich meistens andere Wege als über das Passwort suchen. Falls im die verschlüsselte Version in die Hände fällt, schon und gut.
Aber meisten ist es leichter, den PC mit einem Keylogger o.Ä. zu infizieren, oder die Person auf eine gefälschte Website umleiten.

Was auch ganz wichtig, niemals bei 2 Diensten das gleiche PW benutzen. Denn wer sagt dir, dass Dienst zwei so liebt ist, und das PW verschlüsselt speichert? Vielleicht sammelt dieser Dienst die PW's um dann den Benutzern nachzuschnüffeln, und wenn die sich dann so bei der Bank einloggen können, um so schöner....

Elderan

[opi]

Hallo Elderan,

super Ausführung!

Also wie du siehst, dass jmd. über das Loginformular versucht das PC zu knacken ist eher unwahrscheinlich, und sofern man kein Wort aus dem Wörterbuch benutzt (fast) unmöglich.
Darum versucht ein Angreifer immer die verschlüsselte Version zu bekommen, was oft leichter ist als man denkt.
Darum sollte das Passwort auch noch dann sicher sein, wenn es ein Cracker in die finger bekommt.

Was dem Cracker dann natürlich auch noch bleibt, ist das Cookie des Benutzers! Dieses ist zwar nur solange gültig, bis der Browser geschlossen wird, aber immerhin... und welche Sicherheitsmaßnahmen der private Benutzer auf seinem PC einsetzt, darauf habe ich leider keinen Einfluß.

Um dem Cracker auch noch das "Lauschen" zu erschweren, wird bei mir grundsätzlich https angefordert. Es gibt es hierzu noch weitere Möglichkeiten oder ist https sicher genug hierfür?

Greez,
opi