Authorisierung

Hallo,

Ich finde den default Membership-Provider von ASP eigentlich ganz gut. Allerdings möchte ich, dass es bei einem falschen Login ein Delay gibt. Dafür muss ich höchstwahrscheinlich einen Membership-Provider selbst programmieren.

Ich möchte allerdings die Basis-Funktionen des SqlMembershipProviders beibehalten. Wie kann ich das machen?

Folgendes geht ja nicht:

using System.Collections.Generic;
using System.Linq;
using System.Web;


namespace Seva.App_Code
{
    public class Test : MembershipProvider
    {
        public Test()
        {
            SqlMembershipProvider test = new SqlMembershipProvider();
        }

        public override bool ValidateUser(string strName, string strPassword)
        {
            return test.ValidateUser(strName, strPassword);
        }

        
    }
}

Der Membershipprovider ist der falsche Ort, um eine Verzögerung einzubauen.

LaTino

Wieso?

Der Membershipprovider stellt die Methoden zur Verfügung für die Verwaltung der Mitglieder. Eine Verzögerung bei fehlgeschlagenem Login? Der Provider kann ja gern mitteilen, dass das Login fehlgeschlagen ist, aber die Verzögerung sollte dann bitte die Anwendung einbauen. Ansonsten kannst du den Provider für genau diese eine Anwendung gebrauchen - für mehr aber auch nicht.

(mit anderen Worten - die Verzögerung bei inkorrektem Login geht schon mehr in Richtung View, als dem MembershipProvider gut tun kann)

LaTino

Ok. Ich habe jetzt ein Thread.Sleep(3000) unter Login_Failed des Login Controls... und es funktioniert.

Hab zwar nicht so den Durchblick in ASP, aber liegt da nicht so ziemlich alles Flach wenn man Thread.Sleep() benutzt?

Ich denke, eben nur der Thread, der den Logout wegen fehlgeschlagenem Login machen möchte. Sind ja nicht alle Nutzer davon betroffen. Vielleicht verstehe auch ich nur was falsch...

Ich wundere mich auch etwas, dass du den Server anhalten willst, damit der Client wartet...wieso sagst du nicht einfach dem Client, dass er zu warten hat?

LaTino

Weil es einfacher ist, zu programmieren 😉

Meine Idee war auch die:
Irgendwie bin ich noch nicht ganz in die Authorisierung durchgestiegen, aber ich kann mir vorstellen, dass jemand ein Programm schreiben "könnte", mit welchem er einen Login simulieren kann und einfach tausende von Möglichkeiten durchmacht, bis er das richtige Passwort gefunden hat. Wenn allerdings der Server bei jedem falschen Login ein Delay von 3 Sekunden rein macht, braucht dieses Programm eben "tausende mal 3 Sekunden", um das richtige Passwort auszumachen. Bin ich da richtig in der Annahme?

Nein, bist du nicht. Auf so vielen Ebenen nicht, dass ich gar nicht weiss, wo ich anfangen soll.

Kurz gefasst: als Gegenmittel gegen brute force Passwort-Ausprobieren bremst du nicht etwa den Angreifer aus, sondern deinen Server. Irgendwo ist da ein Denkfehler 😉.

Denkfehler eins zum Beispiel ist, dass der Angreifer brav wartet, bis er eine Antwort hat, bevor er die nächste Möglichkeit ausprobiert.

Oder dass sein Tool durch den IIS ein und derselben Session zugeordnet werden kann.

Aber er hats dann natürlich viel einfacher, deinen IIS abartig viele Threads gleichzeitig öffnen zu lassen.

Toll!

LaTino 😉

Wie kann man bruto force dann am besten verhindern?

Gut, kann sein, dass ich immer noch einen Denkfehler habe:
Aber wenn der Angreifer nicht auf die Antwort wartet, wie soll er dann mitbekommen, ob das Passwort gültig war? Auf irgendwas muss er doch warten. Gut, er kann natürlich eine andere Anfrage starten, während er auf die Antwort wartet, doch diese Anfrage kostet dem Angreifer auch einen neuen Thread.

Was ich auch nicht verstehe ist, warum ein Thread.Sleep() den Server ausbremsen soll. Ich habe schon sehr komplexe Software mit vielen Threads geschrieben und musste oft ein Thread.Sleep(1) einbauen, damit ein stark arbeitender Thread auch anderen Threads eine Chance geben kann.

Ein Angreifer brauch aus meiner Sicht genau so viel Resourcen wie der Server...

Ich habe schon sehr komplexe Software mit vielen Threads geschrieben und musste oft ein Thread.Sleep(1) einbauen, damit ein stark arbeitender Thread auch anderen Threads eine Chance geben kann.

Äääähm. Ist grundsätzlich ein anderes Thema, aber Synchronisation zwischen Threads läuft eigentlich nicht so, dass man einen Thread warten laesst und hofft, dass die Wartezeit ausreicht.

Ein Angreifer braucht aus meiner Sicht genau so viel Resourcen wie der Server...

Ja. Deshalb wurden DDOS erfunden. Geh einfach davon aus, dass der Angreifer ein Vielfaches deiner Ressourcen hat.

LaTino

http://www.codeguru.com/csharp/csharp/cs_webservices/security/article.php/c7907

Stichwort im Artikel ist account lockout. Er gibt auch Hinweise, woran man eine Attacke erkennen kann (um die entsprechende IP zu sperren oder andere Gegenmaßnahmen zu ergreifen).

Schließlich erwähnt er auch deine Sleep()-Methode und nennt auch gleich das KO-Kriterium für diese Methode:

Note: Although adding a delay could slow a single-threaded attack, it is less effective if the attacker sends multiple simultaneous authentication requests.

Less effective heist in diesem Fall - je mehr simultane Zugriffe, desto weniger effizient, ab einer gewissen Zahl so gut wie sinnlos.

Hoffe, der Artikel hilft vielleicht ein bisschen.
Gruß,

LaTino

Ok! Vielen Dank! Ich les mir das mal genauer durch.

Das Problem wird ja sein: Auch wenn ich die IP Softwaretechnisch sperre, auf irgend einer Ebene wird der Angriff trotzdem noch ankommen. Man muss eben sehen, dass man die Sperrung so früh wir möglich ansetzt, um nicht unnötig viel Code auszuführen.

Da spielt wieder der Lebenszyklus einer ASP-Seite eine Rolle.

Naja, aus meiner Sicht am am simpelsten implementiert ist ein account lock mit Freigabe nach xy Minuten (drei vergebliche Login-Versuche: account wird (db-technisch) gesperrt und ist für gewisse Zeit überhaupt nicht mehr zugreifbar).

Wie im Artikel beschrieben, ist das bei einer bestimmten Frequentierung der Seite aber auch keine vernünftige Lösung mehr. Dann hilft schon eher Hardware, die den unerwünschten Verkehr direkt abblockt. Interessant auch der Vorschlag, Accounts mit bestimmten IPs, von denen aus die Anmeldung erlaubt ist, zu verbinden (kann man ja auch mit IP-Ranges machen).

LaTino