Sicherheit beim Login
0 0 
Take
0 0 0 0
Sicherheit beim Login
Hi Forum,
ich habe passwortgeschützten Bereich in einem Projekt. Nun überlege ich, die Anzahl der Login-Versuche zu begrenzen.
Aber inwiefern ist das überhaupt sinnvoll? Und falls sinnvoll, wie vermeide ich, über die Begrenzung hinweg wertvolle Informationen an den vermeintlichen Eindringling zu geben?
Mache ich z.b. einen Unterschied bei Benutzung eines korrekten Usernamens im Gegensatz zu einem nicht korrekten Usernamen, gebe ich eine wertvolle Info raus. Andererseits sind die Usernamen ohnehin weitestgehend bekannt.
Gibt es Ansätze und/oder Ideen, die sich in der Praxis als günstig herausgestellt haben? Wie vermeidet man, dass Eindringlinge einfach unzählig viele Kombinationen aus User/Passwort ausprobieren, um in den geschützten Bereich zu kommen?
Schöne Woche, Ferdi
-
Hallo,
Gibt es Ansätze und/oder Ideen, die sich in der Praxis als günstig herausgestellt haben? Wie vermeidet man, dass Eindringlinge einfach unzählig viele Kombinationen aus User/Passwort ausprobieren, um in den geschützten Bereich zu kommen?
du könntest zweigleisig fahren:
- Zugriffe ein und derselben IP begrenzen (Anzahl, Zeitfenster)
- Zugriffe auf einen bestimmten Usernamen begrenzen (Anzahl, Zeitfenster)
Allerdings hält das immer noch kein Botnetz ab...
-
Hi,
- Zugriffe ein und derselben IP begrenzen (Anzahl, Zeitfenster)
Könnten sich dann nicht aber Mitarbeiter einer Firma, die sich z.b. nicht mögen, gegenseitig torpedieren?
Gruß, Ferdi
-
Mahlzeit Ferdi,
Könnten sich dann nicht aber Mitarbeiter einer Firma, die sich z.b. nicht mögen, gegenseitig torpedieren?
Eventuell schon - aber wie heißt es so schön: es gibt keine technischen Lösungen für soziale Probleme.
Da muss dann halt der Vorgesetzte mal ordentlich auf den Tisch hauen ...
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:& n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
-
Moin,
ich habe passwortgeschützten Bereich in einem Projekt. Nun überlege ich, die Anzahl der Login-Versuche zu begrenzen.
Aber inwiefern ist das überhaupt sinnvoll?
Nicht besonders. Nimm mal an, jemand findet (wodurch auch immer) einen korrekten Usernamen und versucht sich 10mal damit einzuloggen, dann kann derjenige, dem der Name wirklich gehört sich auch nicht mehr einloggen.
Mache ich z.b. einen Unterschied bei Benutzung eines korrekten Usernamens im Gegensatz zu einem nicht korrekten Usernamen, gebe ich eine wertvolle Info raus. Andererseits sind die Usernamen ohnehin weitestgehend bekannt.
Einfach eine Meldung wie z.B. "Benutzername nicht vorhanden oder Passwort falsch" für beide Fälle. Dann weiß der Eindringling schonmal nicht, ob der Username falsch ist, oder das Passwort.
Gibt es Ansätze und/oder Ideen, die sich in der Praxis als günstig herausgestellt haben? Wie vermeidet man, dass Eindringlinge einfach unzählig viele Kombinationen aus User/Passwort ausprobieren, um in den geschützten Bereich zu kommen?
Bin jetzt nicht so der Experte auf dem Gebiet, aber: Das Begrenzen auf IPs anwenden, nicht auf Nutzernamen. D.h. z.B. IP 123.345.456.235 versucht 10mal hintereinander sich mit Fehlerhaften Daten einzuloggen, dann wird sie für ne Stunde oder so gesperrt.
Gruß,
Take-
Einfach eine Meldung wie z.B. "Benutzername nicht vorhanden oder Passwort falsch" für beide Fälle. Dann weiß der Eindringling schonmal nicht, ob der Username falsch ist, oder das Passwort.
Der normale User wüsste es aber dann auch nicht, wenn er sich auf regulärem Weg versucht ein zu loggen!
Gruß
regulärer
T-Rex
-
-
Hello,
ich habe passwortgeschützten Bereich in einem Projekt. Nun überlege ich, die Anzahl der Login-Versuche zu begrenzen.
siehe auch http://www.zdziarski.com/blog/?page_id=442
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Moin!
Gibt es Ansätze und/oder Ideen, die sich in der Praxis als günstig herausgestellt haben?
Ja. Je nach dem wie Dein Login funktioniert:
- temporäre Sperrung des Benutzers (z.B. 30 min nach 6 falschen Versuchen)
oder:
- Wenn Du die Mailadresse des Benutzers hast: Freischaltcode an Benutzer, der muss dann gleich neues Passwort anlegen.
und/oder
- Sperrung der IP bei besonders bösartigen (automatisiertem/parallelen) Angriff (z.B. 2. Login-Versuch innerhalb von 2 Sekunden)
Abzuwägen gilt die Gefahr des Eindringens gegenüber der Gefahr einen Benutzer zu blocken und den der Arbeit fernzuhalten.
Eventuell ist es besser, "sichere" Passwörter zu erzwingen.
Darüber kann man Bücher im Umfang eines "schlanken Tausendseiters" schreiben. Das geht hier nicht, Du musst mehr verraten wenn Du mehr wissen willst.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hello,
Eventuell ist es besser, "sichere" Passwörter zu erzwingen.
Darüber kann man Bücher im Umfang eines "schlanken Tausendseiters" schreiben. Das geht hier nicht, Du musst mehr verraten wenn Du mehr wissen willst.
Das übliche Verfahren mit HTTP-Auth ist doch sowieso unsicher, weil sowohl Accountname, als auch Passwort bei jedem Request im Klartext übertragen werden. Jeder, der in oder an der Leitung sitzt, kann das mitlesen.
Also müsste mMn zumindest erstmal der Kanal abgesichert werden, z.B. durch ssh/tls, bevor man sich über weitere Maßnahmen Gedanken macht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Moin!
Also müsste mMn zumindest erstmal der Kanal abgesichert werden, z.B. durch ssh/tls, bevor man sich über weitere Maßnahmen Gedanken macht.
Wir wissen ja nichtmal, ob schon daran gedacht wurde....
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Hello,
Also müsste mMn zumindest erstmal der Kanal abgesichert werden, z.B. durch ssh/tls, bevor man sich über weitere Maßnahmen Gedanken macht.
Wir wissen ja nichtmal, ob schon daran gedacht wurde....
Was wissen wir schon?
Und wenn die OPs die Fragen dann auch noch "mal eben so hinrotzen" und sich dann nicht weiter drum kümmern, weil dasselbe nämlich in 27 Foren tun ...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
Ich glaube du siehst das aus dem falschen Blickwinkel.
Du hast zwar recht, theoretisch könnte man durch try & error die Zugangsdaten zu einem Benutzer herausfinden. Doch wie lange dauert dass?
Nehmen wir mal an der Benutzername ist bekannt, dann gilt es nur noch das Passwort zu erraten. Das Passwort ist sagen wir mal 8 Zeichen lang und könnte theoretisch aus 26 + 10 Zeichen bestehen (a-z 0-9). Groß und Kleinbuchstaben betrachten wir mal als gleich.
Es gibt also 36 * 36 * 36 * 36 * 36 * 36 * 36 * 36 Möglichkeiten. Das sind 2821109907456 Möglichkeiten -> 2.821.109.907.456 -> 2.8 Billionen (also Deutscher Schuldenstand 2013 :D)
Sagen wir mal der Angreifer schafft 1000 Anfrage pro Sekunde, dann braucht er immer noch 2.8 Milliarden Sekunden. Wenn ich mich nicht verrechnet habe wären das 5441 Jahre.
Und das nur für 1 Passwort. Für ein zweites Passwort bräuchte er nochmal so lange.
Je mehr Anfragen in der Sekunde an den Server verschickt werden, desto schneller kann man das Passwort natürlich knacken. Irgendwann geht jedoch der Server in die Knie.Das war jetzt rein Theoretisch. Bei einer Unterscheidung zwischen Groß und Kleinbuchstaben wären es schon 26 + 26 + 10 Hoch 8 Möglichkeiten. Nimmt man Sonderzeichen hinzu sind es nochmals deutlich mehr. Und mit jeder Stelle des Passwortes erhöht sich die Wahrscheinlichkeit.
Deshalb erlaube ich mir die Aussage, dass ein Passwort übers Internet nicht per try & error erraten werden kann, wenn es genug Stellen aufweißt!!
jetzt könnt ihr meinen Post korrigieren :D
Gruß
Taschenrechneranbetender
T-Rex-
Hi,
Deshalb erlaube ich mir die Aussage, dass ein Passwort übers Internet nicht per try & error erraten werden kann, wenn es genug Stellen aufweißt!!
Social-Engineering und/oder unsichere Passwörter.
Deine Berechnung stimmt wenn man wirklich alle Kombinationen einfach durchgeht.
Ich behaupte jetzt das die wenigstens Benutzer Passwörter wie "d9fa0S!" haben, sondern normale Wörter verwenden.
Geht man jetzt ein Wörterbuch durch ist man wesentlich schneller.Allerdings sind die Benutzer dann ja selber schuld ;-)
~dave
-
Guter Aspekt!
Dann eine andere Rechnung. Nehmen wir mal an die Deutsche Sprache verfügt über ca. 1,5 Millionen Wörter.
Wieder 1000 Abfragen pro Sekunde = 25 Minuten pro Passwort.
Hmpf dann sieht es schon anders aus.Ich als Hacker würde mir aber so einen Aufwand nicht für ein "unwichtiges" System machen. Wenn es sich bei dem System um das Playstation Network handeln würde, dann sähe es schon anders aus.
Außerdem würde ich die User eher zwingen min. eine Zahl zum Passwort hinzuzufügen (Blutwurst1 *rofl*). Ist auf jeden Fall besser als die User Temporär aus dem System zu sperren.Gruß
im Duden stehender
T-Rex-
Yerf!
Ist auf jeden Fall besser als die User Temporär aus dem System zu sperren.
Kommt drauf an wie lange die Sperre ist... wenige Sekunden werden einen User nicht stören, aber bereits bei einer Sekunde bedeutet das für deine Rechnung Faktor 1000, also statt 25 Minuten gut 17 Tage.
Das ist auch genügend Zeit um das über Logfiles zu bemerken...
Gruß,
Harlequin
--
RIP --- XHTML 2
nur die Besten sterben jung-
Hello,
Kommt drauf an wie lange die Sperre ist... wenige Sekunden werden einen User nicht stören, aber bereits bei einer Sekunde bedeutet das für deine Rechnung Faktor 1000, also statt 25 Minuten gut 17 Tage.
Wie realisierst Du denn diese Verzögerung? Da bin ich jetzt ein bisschen gespannt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Yerf!
Wie realisierst Du denn diese Verzögerung? Da bin ich jetzt ein bisschen gespannt.
Ich würd den letzten Loginversuch beim Account in der DB speichern (ist eh ne sinnvolle Sache, das dem User zu zeigen, dann kann er auch selber sehen, wenn jemand ersucht seinen Account zu "hacken") und das mit dem Zeitpunkt des nächsten Versuchs vergleichen (Differenz <5sek. und ich lehn ab). Für Versuche auf nicht vorhandene Accounts würd ich mir eine Art temporäre Tabelle anlegen und das dort speichern, damit es sich identisch verhält.
Gruß,
Harlequin
--
RIP --- XHTML 2
nur die Besten sterben jung-
Hello Harlequin,
Wie realisierst Du denn diese Verzögerung? Da bin ich jetzt ein bisschen gespannt.
Ich würd den letzten Loginversuch beim Account in der DB speichern (ist eh ne sinnvolle Sache, das dem User zu zeigen, dann kann er auch selber sehen, wenn jemand ersucht seinen Account zu "hacken") und das mit dem Zeitpunkt des nächsten Versuchs vergleichen (Differenz <5sek. und ich lehn ab). Für Versuche auf nicht vorhandene Accounts würd ich mir eine Art temporäre Tabelle anlegen und das dort speichern, damit es sich identisch verhält.
Gut, gut. Das hört sich gut an.
Ich hatte nur die Befürchtung, dass Du ein "sleep()" ins Script schreiben wolltest ;-)
Denn das würde ja für jede Instanz (für jeden Request) einzeln gelten und daher überhaupt keine Wirkung haben...Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Yerf!
Ich hatte nur die Befürchtung, dass Du ein "sleep()" ins Script schreiben wolltest ;-)
Nene... für sowas bin ich schon zu lang im Webumfeld unterwegs ;-)
Gruß,
Harlequin
--
RIP --- XHTML 2
nur die Besten sterben jung
-
-
-
-
-
-
-
-
Hi Ferdi,
... Login-Versuche zu begrenzen. Aber inwiefern ist das überhaupt sinnvoll?
Du müsstest also mitzählen. Für was wäre der Zähler einzurichten? Für die IP, das Kennwort, ...? Wie lange soll der Zähler vorgehalten werden?
Ich behelfe mich mit einr Zwangspause von 10 sec bei falschem Login.
Bei Hochsicherheitszugängen (habe ich nicht) dürfte das Passwort gar nicht über die Leitung gehen. Da müsste man per Zufallsprinzip immer neue Kombinationen anfordern so in der Art:
Bitte gib das fünfte, dritte, achte und erste Zeichen deines Passwortes ein. Wobei die Stellenzahlen vielleicht in einer Grafik gezeigt werden. Die muss dann natürlich lesbar sein.
captcha