Login-Sicherung mit Grafik
-
Korbinian schrieb:
wenns nur um brute force geht, macht doch ein 5-10 minuten timeout wenn 3x falsch oder sowas, das schreckt jeden bruteforce hacker ab
Aber nur die doofen! Welche Chance hast Du da gegen Proxies?
-
Manfred Schmidtke schrieb:
Korbinian schrieb:
wenns nur um brute force geht, macht doch ein 5-10 minuten timeout wenn 3x falsch oder sowas, das schreckt jeden bruteforce hacker ab
Aber nur die doofen! Welche Chance hast Du da gegen Proxies?
sehr gute, denn selbst dann ist der account für 10min gesperrt den man hacken wollte.
und ja, cih bin mir über die konsequenzen für den inhaber des accounts im klaren. aber gegen DOS ist es nunmal nicht einfach anzugehen.
rapso->greets();
-
rapso schrieb:
selbst dann ist der account für 10min gesperrt den man hacken wollte.
und dann geht das programm fröhlich zum nächsten account.
-
betrug schrieb:
rapso schrieb:
selbst dann ist der account für 10min gesperrt den man hacken wollte.
und dann geht das programm fröhlich zum nächsten account.
ok, dann ist der Account aber trotzdem für 10 min gesperrt und das ändert nichts an der Tatsache, dass der Angreifer sich über diesen einen account Zugang verschaffen wollte. Ein kleines Beispiel: Ziel wird es wohl sein, den Hauptaccount zu bekommen. Was bringt es dir dann, wenn man dann innerhalb der 10 min versucht die anderen Benutzeraccounts zu bruteforcen....
Ok, don't feed the trolls, aber das musste ich einfach los werden
Aber jetzt zum Thema:
In diesem Artikel werden ein paar Methoden beschrieben, die zur Abwehr von Bruteforce-Angriffen verwendet werden können. Eine Methode wäre z.B. nach der Passworteingabe eine Verzögerung von 3 Sekunden einzubauen. Dies erhöht die Wartezeit für einen Bruteforceangreifer erheblich.
http://www.owasp.org/columns/mburnett/brutegeneral.html
-
Das mit der Grafik wird doch aber benutzt, damit eine Funktion nicht durch automatische Scripts abgerufen werden kann. z.b. Anlegen von EMail Accounts oder sowas.
Bye, TGGC (Wähle deine Helden)
-
Das stimmt, aber es könnte doch auch gute Dienste leisten, wenn man es als Loginsicherung einsetzt. Bruteforce ist ja im Grunde auch nur ein script oder Programm das automatisch abläuft.
-
Bin begeistert! Da kommen ja einige gute Vorschläge zusammen.
Eine Verzögerung von 3 oder 5 Sekunden ist für den Anwender bei manueller Eingabe denke ich noch akzeptabel und werde ich auch auf jeden Fall einbauen. Das hilft jedoch nur bedingt gegen Programme wie AccessDiver, die mit bis zu 100 Proxies gleichzeitig abfragen. Aber in dem Falle kommt das System ohnehin wegen des Starts von 100 EXE-Programmen ( = 2 GB RAM für die Sessions) zum Erliegen.
Eine Prüfung der IP wäre mit Erweiterung der Datenbank und entsprechender Speicherung durchaus (wenn auch wegen Java/C++ recht aufwendig) zu realisieren. "Merken" kann ich mir sonst nix, da pro Sitzung eine eigenständige EXE gestartet wird.
Dritte Möglichkeit ist statt der Grafik ein zweites Login (z. B. Kundennummer) neben dem Benutzernamen. Da die mir bekannten Cracker-Programme zunächst nur Username@pwd-Combos unterstützen, sind die Script-Kiddys erstmal außen vor. Ob das wiederum noch kundenfreundlich ist, steht jedoch auf einem anderen Blatt. Mich persönlich nervt das, wenn ich auf irgendwelche Anbieterseiten gehe und erst mal meine Kundennummer suchen muss.
Die Grafik als zusätzliche Eingabe ist zwar auch nicht viel kundenfreundlicher, hätte jedoch den Vorteil, dass ich diese vollständig JAVA-seitig einbinden und auswerten könnte, bevor der Applikationsserver angesprochen wird. Allerdings ist eine solche Lösung noch zu suchen.
-
Wenn wir hier vom Web reden, zB dem login einer Internetseite. Folgendes ist lustiges stoppt alle automatischen standard versuche:
die felder Name und Passwort bekommen immer andere namen, in einem hidden Feld steht dann eine ID die angibt welche namen Name und Passwort haben.
Damit zwingt man den angreifer extra die login seite zu parsen. und alle automatischen bots sind ausgesperrt.
diese Grafiken sind eine usability katastrophe - ausserdem auch knackbar, wenn auch nur mit einem ordentlichen netzwerk. denn man kann diese bilder auf Porno/Warez werbe seiten darstellen und die Porno/Warez sucher dazu verkeiten die bilder zu identifizieren weil sie dann die mega geilen downloadzz bekommen... mit einem guten netzwerk ist das kein problem...
im prinzip geht das darum kein leichtes ziel zu sein. denn wenn jemand wirklich will, hat man als admin die schlechteren karten in der hand
man kann lediglich so viele steine in den weg legen, bis der angreifer keine lust mehr hat...
-
PhilippSt schrieb:
ok, dann ist der Account aber trotzdem für 10 min gesperrt und das ändert nichts an der Tatsache, dass der Angreifer sich über diesen einen account Zugang verschaffen wollte. Ein kleines Beispiel: Ziel wird es wohl sein, den Hauptaccount zu bekommen. Was bringt es dir dann, wenn man dann innerhalb der 10 min versucht die anderen Benutzeraccounts zu bruteforcen....
Schicker Gedanke. Wenn man versucht einen bestimmten Acc zu hacken.
Aber zäum das Pferd mal von hinten auf. Was wenn jemand ne list unsicherer Passwörter nimmt und den UserAcc dazu sucht?
Hat die c't mal bei Ebay gemacht. Funktionierte viel zu gut
-
the_alien schrieb:
Schicker Gedanke. Wenn man versucht einen bestimmten Acc zu hacken.
Aber zäum das Pferd mal von hinten auf. Was wenn jemand ne list unsicherer Passwörter nimmt und den UserAcc dazu sucht?
Hat die c't mal bei Ebay gemacht. Funktionierte viel zu gutUnd was willst du dagegen machen? Jeden Account kurz sperren, uU auch etwas länger...
Aber solange der Username bekannt ist, wird es das immer geben. Lösung: mach den Usernamen unbekannt. Nimm zB die email und nicht den nickname als Zugangsname und schon kommt man nicht mehr so leicht an eine Liste der Namen...
Das effektivste hier ist aber selber so eine Liste an Passwörtern zu besitzen und den User darauf hinzuweisen dass er ein unsicheres verwendet (gibt ja auch Algos und Libraries zum feststellen eines sicheren Passworts).
Hier hat man wieder (wie so oft) die Konfrontation Usability <-> Security
Die beiden beissen sich oft
-
Shade Of Mine schrieb:
Und was willst du dagegen machen? Jeden Account kurz sperren, uU auch etwas länger...
Account sperren ist auch irgendwie Mist. Damit schafft es ja ein Bösewicht zumindest den Betrieb von ehrlichen Nutzern zu stören. Das ist auch nicht wirklich schön. Damit kann dann jemand einfach das System lahm legen indem er regelmäßig durchgeht und die Accounts durch Falscheingabe sperrt.
-
Jester schrieb:
Account sperren ist auch irgendwie Mist.
Natürlich ist es Mist. Aber ich wege immer ab: User wird kurz gesperrt (kann aber beim Support anrufen und ihn wieder freischalten lassen) oder account wird übernommen.
Damit schafft es ja ein Bösewicht zumindest den Betrieb von ehrlichen Nutzern zu stören.
Deshalb: Loginname nicht öffentlich zugänglich.
Gut ist nichts davon, keine Frage, es hängt hier ja auch davon ab was für eine Anwendung das ist. Wenn ich zB 15 Minuten lang nicht ins C++ Forum kann, stört das wenig, wenn ich aber 15 Minuten lang nicht in das Intranet komme, ist das schlimm.
Das Problem ist, wenn jemand einen distributed brute force angriff macht, ist man als Admin ziemlich wehrlos. Mass-IP-Sperrung löst das Problem auch nicht
Ist halt einfach teuflisch.Also lieber viele Steine legen, so dass sich das kein Angreifer antut. zB keine öffentlichen Loginnamen sind genial - weil man auf einmal keine Massen Angriffe machen kann, weil man nur einzelne Namen ausspionieren kann, aber keine komplette Liste der ganzen Usernamen bekommt.
Auch kann bei einem distributed angriff folgendes machen: mehr als X mal eingeloggte User (also jene, wo ein Angriff erfolgreich war) werden automatisch gesperrt. User muss sich beim Support melden. Ist aber deswegen doof, weil hier uU schon schaden entstanden sein kann. Naja, jedenfalls eine gute Massnahme um den Schaden zu begrenzten...
Eine interessante Variante, die ich selber noch nicht testen konnte: sobald eine IP als angreifer IP identifiziert wurde, eine sinnlose Maske erstellen wo jeder Login automatisch fehlschlägt, der Angreifer aber den Unterschied nicht erkennen kann. So läuft viel Rechenpower des Angreifers ins Nirvana. Das Problem ist halt nur die IP Sperre -> wenn er wirklich dauernd die IPs wechselt, lohnt es nicht. Wenn das IP wechseln aber nur stattfindet, nachdem der angreifer erkannt hat, dass die IP gesperrt wurde, kann es sinnvoll sein.
Leider habe ich zuwenig Erfahrung wie Angreifer hier vorgehen...
Ich bleibe deshalb vorerst bei meinem: Usernamen sind privat und uU werde ich demnächst auch die wechselne Login Maske implementieren. Ich denke, dass schützt ziemlich gut.
-
Wobei die sich ändernde Login-Seite sich nach einiger Überlegung doch als eine ziemlich unbrauchbare Lösung zeigt. Wie soll der Server unterscheiden, ob er die Seite jetzt zum x-ten Male bekommt, wenn die tatsächlichen Feldnamen im Formular stehen.
Es bringt also nix, die Login-Seite ständig zu verändern, wenn man generell das Login-Formular als HTML benutzt. Der Hacker muss nur eine Login-Seite analysieren (kann ein AccessDiver halbautomatisch) und kann schon loslegen.
Ich sehe jedoch noch zwei Möglichkeiten:
1. "Zeitstempel" mit einer verschlüsselten Uhrzeit, die beim Senden der Seite und beim Empfang der Login-Daten verglichen wird. Nach 10 Minuten wird das Login abgelehnt.
2. "Gültigkeitsstempel" mit einer GUID. Der Server merkt sich, welche Stempel verwendet wurden und trägt diese nach Empfang der Logindaten wieder aus.
-
Manfred Schmidtke schrieb:
Es bringt also nix, die Login-Seite ständig zu verändern, wenn man generell das Login-Formular als HTML benutzt. Der Hacker muss nur eine Login-Seite analysieren (kann ein AccessDiver halbautomatisch) und kann schon loslegen.
Ja, aber dazu muss er erstmal einen Parser schreiben. Indem man die Struktur ein bisschen umdreht, kann man regex ziemlich effektiv verhindern, so muss der Angreifer echt einen Parser schreiben. Das ist Aufwand. Mich kostet es vielleicht 10 Minuten arbeit dieses Feature zu implementieren, aber der Angreifer hat jetzt 2 Probleme:
- er muss erstmal jedesmal die Loginmaske runterladen, das kostet zeit.
- er muss sie analysieren, das kostet arbeit
und man sperrt alle automatischen tools aus - es muss etwas zugeschnittenes sein damit es klappt. Und genau das verhindert die meisten angriffe - weil jemand der mich wirklich lahmlegen will, der schafft es auch. Er hat ja mehr zeit als ich.
Aber ich habe effektiv alle Script Kiddies ausgesperrt, die nur ihren neuen Brute-Force-X-AttackerZZ verwenden wollen...
1. "Zeitstempel" mit einer verschlüsselten Uhrzeit, die beim Senden der Seite und beim Empfang der Login-Daten verglichen wird. Nach 10 Minuten wird das Login abgelehnt.
2. "Gültigkeitsstempel" mit einer GUID. Der Server merkt sich, welche Stempel verwendet wurden und trägt diese nach Empfang der Logindaten wieder aus.
Verstehe ich nicht. Die Uhrzeit - was bringt sie? Alle 10 Minuten eine neue Loginmaske laden ist nicht so problematisch für den angreifer wie mein ansatz. Zumal man die Uhrzeit ja auch selber verschlüsseln kann.
Das mit GUID ist ja ähnlich wie mein Ansatz mit der sich ändernden loginmaske - weil der User eben jedesmal vorher sich ne Loginmaske holen muss bevor er einen login versuch starten kann. Nur dass bei einer GUID ein simples regex reicht, während man bei mir einen (primitiven) parser braucht.
