User (Wieder)erkennung

[[ChAoZ]]

Hallo Leute,

einfache Aufgabe; User nach X Login Versuche für Y Stunden sperren.
Frage: wie erkenne ich den User wieder?

IP Adresse alleine ist ja wohl nicht genug.
Habt ihr ein paar Ideen oder best practices?

Mit steht PHP als Sprache zur Verfügung.
Danke euch.

 

[AwesomSTUFF]

Frage: wie erkenne ich den User wieder?

...am Benutzernamen?

 

[kachiri]

...am Benutzernamen?

Oder an der User-ID. Je nachdem wie die Datenbank aufgebaut ist. Ich würde aber immer eine nicht veränderbare feste ID vergeben, die quasi auch "frei" bleibt, wenn der User gelöscht wird.

Wenn ich allerdings alle Logins blockieren möchte, also auch Versuche mit anderen Namen, bleibt eigentlich nichts anderes als die IP und/oder Session-IDs.

 

[SpamBot]

...am Benutzernamen

Wenn ich dich dann ärgern will gebe ich X Mal xdave78 ein und du kannst dich für X Stunden nicht mehr anmelden....

Je mach Anwendungsgebiet sollte das nicht auftreten.

 

[KitKat::new()]

bleibt eigentlich nichts anderes als die IP und/oder Session-IDs.

spezielle Cookies und Fingerprinting

 

[Raijin]

Da hat @SpamBot nicht ganz Unrecht. In diesem Fall muss man abwägen ob man die Loginversuche von User X zusätzlich an die IP-Adresse oder andere Parameter bindet (zB Browser-Agent). Zwar kann der User die "3 Versuche"-Sperre dann umgehen, indem er die IP-Adresse (oder den Browser) wechselt, hat dann aber erneut nur 3 Versuche. Ein Bruteforce-Angriff wird dadurch schon mal extrem ineffizient.

 

[razzy]

IP / SessionID / Cookie?

 

[Maviapril2]

Ein Bruteforce-Angriff wird dadurch schon mal extrem ineffizient

Außer man hat ein Botnetz

Fingerprinting

Fingerprinting und Loggen um wiederholte Versuche zu identifizieren - da kann es dann schnell problematisch werden bzgl. DSGVO/GDPR

 

[[ChAoZ]]

...am Benutzernamen?

Meine Frage war nicht deutlich genug, gebe ich zu.

Klar, Benutzername = E-Mail bei uns, klar geht das und klar funktioniert das, aber eben auf dieser einen E-Mail-Ebene. Wenn der User eine andere E-Mail Adresse benutzt, ist der Schutz aufgehoben. Daher war der IP-Ansatz schon etwas besser. Brutforce steht auch im Vordergrund des Ganzen.

Ich möchte den User komplett davon abhalten bei uns weitere Login-Versuche zu unternehmen wenn er eine voreingestellte Fail-Anzahl überschritten hat. Dafür reicht der Benutzername nicht aus.

 

[KitKat::new()]

Dafür reicht der Benutzername nicht aus.

Dafür reicht nichts

 

[Iqra]

Was hängt denn da dahinter?

So pauschal funktioniert das leider nicht mehr. "gar nicht" würde irgendeine Form von browserübergreifendem "permanent cookie" erfordern, aber sowas ist wegen "security" nicht mehr möglich, sprich mit etwas Aufwand kann man über simples username+pw und etwas Scripting mehr oder weniger "alles" umgehen.

Wenn(!) ihr genug Kontrolle habt über die Benutzer, dann wäre erweiterte Authentifizierung eine Option. Sagen wir über ein Hardwaretoken, das ein Benutzer in die Hand kriegen muß. Oder via Clientzertifikat. Irgendwas, wo du weißt, ein Benutzer X hat exakt ein Zugangstoken Y und nur das. Hat er es nicht, darf er nicht rein.

Aber das geht natürlich nur in einer eher geschlossenen Umgebung. Je offener das wird, desto schwieriger. CB hätte z.B. viel Spaß, jeden potentiellen Nutzer erst noch zu authentifizieren und ihm dann irgendeine Form von Token in die Hand zu drücken, nur damit derjenige keinen Doppelaccount erstellen kann (oder einen auf Impersonation machen kann).

PS, die Geschichte mit Impersonation ist immer noch überall ein Problem, wobei das teils mit MFA abgefedert wird. Auch heute noch kann fast jeder einen unbekannten Dritten einfach kaltstellen. Wird nur sehr wenig gemacht.

 

[[ChAoZ]]

Dafür reicht nichts

Ja stimmt schon, aber irgendwo muss ich ansetzen...
Auf E-Mail Ebene sperrt es 90% aller unserer Kunden aus (sind nicht technisch versiert).
Auf IP Ebene wohl 99%.

Gegen Bot-Netze und großangelegte Angriffe usw. sind meine Unternehmungen natürlich machtlos.

 

[KitKat::new()]

Gegen Bot-Netze und großangelegte Angriffe usw. sind meine Unternehmungen natürlich machtlos.

Captcha

 

[[ChAoZ]]

Was hängt denn da dahinter?

So pauschal funktioniert das leider nicht mehr. "gar nicht" würde irgendeine Form von browserübergreifendem "permanent cookie" erfordern, aber sowas ist wegen "security" nicht mehr möglich, sprich mit etwas Aufwand kann man über simples username+pw und etwas Scripting mehr oder weniger "alles" umgehen.

Wenn(!) ihr genug Kontrolle habt über die Benutzer, dann wäre erweiterte Authentifizierung eine Option. Sagen wir über ein Hardwaretoken, das ein Benutzer in die Hand kriegen muß. Oder via Clientzertifikat. Irgendwas, wo du weißt, ein Benutzer X hat exakt ein Zugangstoken Y und nur das. Hat er es nicht, darf er nicht rein.

Aber das geht natürlich nur in einer eher geschlossenen Umgebung. Je offener das wird, desto schwieriger. CB hätte z.B. viel Spaß, jeden potentiellen Nutzer erst noch zu authentifizieren und ihm dann irgendeine Form von Token in die Hand zu drücken, nur damit derjenige keinen Doppelaccount erstellen kann (oder einen auf Impersonation machen kann).

PS, die Geschichte mit Impersonation ist immer noch überall ein Problem, wobei das teils mit MFA abgefedert wird. Auch heute noch kann fast jeder einen unbekannten Dritten einfach kaltstellen. Wird nur sehr wenig gemacht.

Zu kompliziert.
Ein OIDC Server stand zur Debatte, wurde aber abgelehnt daher sind wir wieder auf klassischem Login-Verfahren. Email + PW sind die Zugangsdaten.

Ich möchte einfach bei zu vielen Fehlversuchen den User für paar Stunden sperren, mehr nicht.
Keep it simple

 

[sandreas]

Ich möchte einfach bei zu vielen Fehlversuchen den User für paar Stunden sperren, mehr nicht.

Mach das nicht. Bau nach 10 Fehlversuchen ein Captcha ein und sende dem Benutzer eine E-Mail, dass es "verdächtige Aktivität" gab, wenn er dann per Link bestätigt, dass er das war, dann verschwindet das Captcha wieder.

Falls du eine "Sperre" machen willst, um den Server zu entlasten, sperre den Benutzernamen / E-Mail immer nur maximal 30 Sekunden, besser nur 10. Das ist als Wartezeit verschmerzbar.

Es reicht kein Verzögern des Requests (z.B. in PHP sleep(10);), weil man die Requests ja einfach parallel ausführen kann... damit legst du dir dann sogar eher den Server lahm.

Vorteile:

• Normale Nutzer werden nicht mit Captcha genervt
• "Dumme" oder von Botnetzen angegriffene Nutzer können sich selbst per Klick wieder aus der Captcha-Hölle befreien
• Du kannst feststellen, welche Nutzer besonders betroffen sind und manuell weitere Maßnahmen ergreifen
• Es ist recht einfach umzusetzen

 

[NPC]

"Anonyme User bei wiederholter falscher Eingabe von Zugangsdaten sperren"

Möglichkeiten:

• Identifizierung via Brower-Fingerprint (https://amiunique.org/)
• Rate limitation: pro Zeiteinheit werden sind nur X Loginversuche möglich.
• Benutzerkonto sperren: nicht von OWASP empfohlen, da ich so einen User gezielt aus dem System aussperren kann. Daher: Nach X falschen Eingabeversuchen wird das Benutzerkonto gesperrt und ein Entsperrlink an die hinterlegte Emailadresse versendet (ggf. Sperrung mit TTL).
• Analytics und Feature-Flags: jeder erfolgreiche und fehlgeschlagene Login wird geloggt. Nach ein paar Tagen kennst du die Durchschnittswerte von erfolgreichen/fehlgeschlagenen Logins pro Zeiteinheit (Fallbacks schätzen). Wird dieser Wert um Faktor X überschritten, wird zusätzlich ein Captcha eingeblendet. Sollte der Wert ein Maximum überschreiten, findet offensichtlich ein Angriff statt. Dann wird die Loginseite/API für X Stunden deaktiviert.

 

[BeBur]

Existiert das Problem denn schon real? Ich würde dazu neigen nur auf die IP zu schauen und jetzt nicht viel mehr Arbeit rein zu stecken als andere Seiten mit ähnlich vielen/wenigen Besucherzahlen.
Was noch relativ wenig Arbeit sein könnte: Je nach IP (lässt sich ja einem Land / einer Region zuordnen) ein Captcha anzeigen das gelöst werden muss.

 

[[ChAoZ]]

Danke euch für die zahlreichen Antworten.
Die Idee mit der E-Mail und eine leichte Verzögerung zwischen den Logins klingt wirklich gut, aber in aktuellen Stadium des Projektes noch zu viel. Ich arbeite rein am Backend, das Frontend existiert noch nicht dazu, ergo ist Captcha erstmal raus, kein MVP und Mails kommen später.

Ich behalte eure Vorschläge im Hinterkopf.
Sobald das Projekt wesentlich weiter fortgeschritten ist, werde ich es umsetzen.

 

[DubZ]

die fachlichen Anforderungen des Projektes wären interessant, um hier bessere best practices aufzeigen zu können.

Bei Brutforce / Botnetz kann man auch pauschal schon das sagen, was hier bereits erwähnt wurde: captcha. Bei allem anderen wäre interessant zu wissen, was genau da hinter steht, wie wichtig Security ist. Intranet oder Internet Applikation usw.

Das Projekt scheint aber klein und bzgl. Security nicht allzu wichtig zu sein, da hier schon früh in die Implementierungsphase übergegangen ist, obwohl grundlegende Architekturfragen noch ungeklärt sind. In diesem Sinne, keep it simple wie von dir bereits erwähnt @[ChAoZ]