Bruteforce verhindern (IP-Check)

[cortex]

Zitat von mgutt

Bots sind nicht so dumm. Die lesen grundsätzlich erstmal das Formular aus und füttern ihren POST-Datensatz entsprechend.

die sind bestimmt nicht dumm, aber auch nicht intelligent. irgendeiner muss denen das ja beigebracht haben. darüber hinaus möchte ich mich nicht aus dem fenster lehnen - ich hatte noch nicht das vergnügen, so ein teil zu benutzen .-

Zitat von mgutt

In phpBB beispielsweise werden die Fehlversuche in der Spalte der User-Tabelle des betreffenden Users zwischengespeichert [...]

ich mache das ähnlich. allerdings würde es mir nicht im traum einfallen, für sec-masznahmen in der user-tabelle herumzufuhrwerken.

Zitat von mgutt

Ich kenne die drei beliebtesten Passwörter, die im Netz eingesetzt werden

schatzi123 .-

Zitat von mgutt

zu heftige Vorgaben demotivieren

eben. und darum kannst du das für "einfache" apps wie onlineshops oder dergleichen knicken. jedenfalls dann, wenn es tatsächlich was bringen soll. die rechenpower wurde in den letzten jahren nicht geringer - mit einer handvoll zahlen und buchstaben schreckst du niemanden ab.

Zitat von mgutt

Prüfung von IP-Adressen

dazu gab's bereits kritische töne.

Zitat von mgutt

Viel mehr wird versucht FTP-, .htaccess-oder MySQL-Logins zu bruteforcen.

das geht über meinen wissenshorizont hinaus. da bestimmt wenige entwickler daran denken, ist es scher ein lohnendes ziel.

cx

[mgutt]

Zitat von cortex

2. logge ich nur falsche passworte, kann der angreifer darauf schliessen, ob ein pwd vergeben ist oder nicht - ich verrate etwas über die daten meiner anwendung.

Woher soll der Angreifer das überhaupt herausfinden? Ob Du nur falsche oder beides loggst, weiß der Angreifer so oder so nicht. Wenn doch, wäre es bereits ein grundlegender Fehler im Script. Aber korrekte Passwörter loggt man nicht. Das wäre mir zu risikoreich und stellt gleichzeitig ein Vertrauensmissbrauch dar.

Zitat von cortex

3. mit den user-names verhält es sich genauso. ich persönlich mache keinen grossen unterschiede zwischen user-names und passworten. ich frage mich auch, warum i.a. das gehashte speichern von passworten, aber nicht von user-names empfohlen wird. wahrscheinlich nur, um mir bei der anmeldung ein hallo user x entgegenzuwerfen.

Nun, woher sollte das "cortex" neben jedem Beitrag kommen, wenn der Username gehasht wäre. ;)

Ein Angreifer möchte hauptsächlich das Passwort und die Emailadresse haben. Hackt er die DB, kommt er so in den Genuss alle Daten in Paypal, Amazon, Ebay und Co. auszuprobieren. Wer also mehr Sicherheit erreichen möchte, sollte die Emailadresse verschlüssen. Ich nutze dazu AES_ENCRYPT() mit einem Hash, den ich im FTP hinterlegt habe und einem Salt, der für jeden User unique ist. D.h. wenn jemand die Emailadressen aus der DB entschlüsseln möchte, muss er zusätzlich Zugriff auf den FTP besitzen, um den Hash und den Salt herausfinden zu können.

Das gleiche gilt für das Passwort. Eine einfache md5()- /sha()-Verschlüsselung ist unzureichend. Hier sollte man auch immer mit einem Unique Salt arbeiten. Falls man bekannte Softwares einsetzt, sollte man die Hash-Generation immer selber noch mal verändern. So muss der Angreifer Zugriff auf den FTP haben und kann nicht einfach den Code des Software-Herstellers kopieren.

[cortex]

Zitat von mgutt

Woher soll der Angreifer das überhaupt herausfinden?

ausgangslage:

- schatzi123 ist als pwd vorhanden
- kumpel ist nicht als pwd vorhanden

1. methode: nur "richtige" (vorhandene) pwd loggen:

3 x schatzi123 - account gesperrt
3 x kumpel - nichts passiert

-> angreifer denkt sich: "aha - schatzi123 ist vorhanden"
-> ein wert der user-/pwd-kombi ist geknackt
-> auf kumpel wird weiter herumgehämmert

2. methode: alle fehlgeschlagenen login-versuche (pwd) loggen:

3 x schatzi123 - account gesperrt
3 x kumpel - account gesperrt

-> angreifer denkt sich:

a) "aha - schatzi123 und kumpel sind vorhanden"
b) "hm... hab ich 'ne trefferquote"

Zitat von mgutt

Aber korrekte Passwörter loggt man nicht. Das wäre mir zu risikoreich und stellt gleichzeitig ein Vertrauensmissbrauch dar.

1. herrgott, die passworte sind gehashed. kein mensch kann etwas damit anfangen.
2. ich zitiere dich mal:

Ich habe das bereits mit eigenen Userdaten getestet. Prozentual gesehen, sind zwar nur wenige Accounts betroffen, aber möglich wäre es.

wie war das mit dem vertrauensmissbrauch ?

Zitat von mgutt

Ein Angreifer möchte hauptsächlich das Passwort und die Emailadresse haben. Hackt er die DB, kommt er so in den Genuss alle Daten in Paypal, Amazon, Ebay und Co. auszuprobieren.

wieder eine subjektive einschätzung? andere szenarien kannst du dir nicht vorstellen?

Zitat von mgutt

Das gleiche gilt für das Passwort. Eine einfache md5()- /sha()-Verschlüsselung ist unzureichend [...]

an den grundlagen sind wir schon vorbei.

cx

[mgutt]

Zitat von cortex

ausgangslage:

- schatzi123 ist als pwd vorhanden
- kumpel ist nicht als pwd vorhanden

1. methode: nur "richtige" (vorhandene) pwd loggen:

3 x schatzi123 - account gesperrt
3 x kumpel - nichts passiert

-> angreifer denkt sich: "aha - schatzi123 ist vorhanden"
-> ein wert der user-/pwd-kombi ist geknackt
-> auf kumpel wird weiter herumgehämmert

Verstehe ich nicht. Wenn er schatzi123 bereits ausprobiert hat, dann ist er doch erfolgreich gewesen. Vielleicht gehen wir ja von einer anderen Basis aus, aber bei mir kann man kein PW testen, wenn man nicht den User kennt (typisches Login-Formular) und ohne User wird die Anfrage einfach abgelehnt. Was Du erklärst hört sich so an, als ob jemand alle PW-Hashs einer DB durchprobiert. Wie kommt derjenige überhaupt an die Hashs? Meiner Ansicht nach kann er die nur kennen, wenn er Zugriff auf die DB hat und wenn er das hat, dann kann man Bruteforce nicht mehr verhindern. Er kann sich die Daten ja dann in eine lokale Ebene kopieren.

wie war das mit dem vertrauensmissbrauch ?

Keiner, weil ich einfach nur die zehn beliebtesten Passwörter gehashed habe und in der DB einen COUNT() ausgeführt habe. Ich habe also keine Angaben mitgeloggt. Sondern einfach nur die Häufigkeit gezählt.

wieder eine subjektive einschätzung? andere szenarien kannst du dir nicht vorstellen?

In der Szene kenne ich mich sehr gut aus. Es gibt sicher noch andere Verwendungen, aber diese sind die beliebtesten und sind für Angreifer schnell in Geld zu wandeln. Sind also keine subjektiven Einschätzungen, sondern das was in der Praxis mit den Daten gemacht wird. In manchen Fällen wird sogar mit solchen Daten ein Zugriff auf ein Online-Banking möglich (manche Banken bieten dem Kunden an seinen Usernamen und Login frei zu wählen :wall:). Aber der häufigste Fall sind die zuvor genannten Fälle. Eine weitere beliebte Art ist das Verbreiten von Trojanern an gespeicherte Emailadressen oder über die Website, die gehackt wurde. Beides fällt aber schnell auf.

[cortex]

möchte mich noch einmal (abschliessend) zu der diskussion äussern:

Zitat von mgutt

bei mir kann man kein PW testen, wenn man nicht den User kennt

genau darum gehts - wenn der angreifer das pwd nicht testen kann, weiss er, dass der user nicht in der db existiert. kennst du beim thema sicherheit den grundsatz, mit feedbacks an den user / angreifer sparsam zu sein?

Zitat von mgutt

weil ich einfach nur die zehn beliebtesten Passwörter gehashed habe [...]

soso... das hier hört sich anders an:

Zitat von mgutt

Ich kenne die drei beliebtesten Passwörter, die im Netz eingesetzt werden und genau die könnte man dann bei jedem User jeweils einmal probieren, bevor der Account weitere Fehlversuche ablehnt.

cx

[s1r10n]

mal ganz abgesehen davon...

wenn du einen vernünftigen hash verwendest (evtl auch mal was sichereres als md5) und wenn du tatsächlich dafür sorgst das ejder sein eigenes salz bekommt bist du wenn du die hashs ausließt erstmal ne ganze weile ebschäftigt... rainbowtables sind nutzlos gegen salz
und über http zu bruteforcen ist eklig da es dir das meißte der performance auffrisst

nichtsdestotrotz hilft dir das alles nur wenn du sichere passwörter hast... trotzdem ist es auf ip basis keine schöne idee verschiedene provider geben evrschiedenen usern gleiche ip adressen da der vorrat an ip adressen begrenzt ist... was wenn leute in ner firma oder an einer uni sitzen alle zusammen mit einer... ip? nat-router?

ip-spoofing?
wenn ich über nen script bruteforcen will kann ich auch genausogut per reconnect andre ips hohlen oder was auch sehr gut funktioniert sind proxies...

auf ip basis sicherheit zu gestalten ist seit langem nichtmehr aktuell und garantiert nicht sicher