Jo das stimmt soweit!

Was ich immer ganz gerne mach: Einfach doppelt hashen. Nach dem Motto: sha1(sha1($content)) - Da kommste mit Brute-Force nicht weit...

Gegen BruteForce hilft das überhaupt nichts. Genausowenig wie "Salten" dagegen hilft.
Gegen angriffe "von außen", also Leute, die nur die Loginmaske sehen und damit versuchen Passwörter zu knacken, sind beide Methoden unbrauchbar. Denn in dem Fall kennt der Angreifer die Hash-Werte eh nicht, also würde ihm es auch nichts nützen, wenn er die Hashverfahren umkehren könnte. Gegen solche Angreifer nützt hashen überhaupt nichts, da könnte man das Passwort auch im Klartext in die Datenbank schreiben, würde keinen Unterschied machen (und sogar die Gefahr der false-positives eliminieren).

Beim salten geht es darum Angreifern von "innen" zu behindern. Diese Angreifer haben aus irgend einem Grund schon zugriff auf die Datenbank (oder sonstige Systeme). Man will dann nurnoch verhindern, dass dieser, der die Hash-Werte kennt, nicht an die Klartext-Passwörter kommt. Und dazu müsste er eben die Hash-Funktion umkehren können und das geht (derzeit) nur mit BruteForce oder Rainbowtables. Gegen BruteForce hilft garnichts, der Angreifer probiert alle Möglichkeiten durch, und dabei spielt es überhaupt keine Rolle wie gehast wurde, da man davon ausgehen kann, dass er weiß wie gehasht wurde (denn er ist ja im System) und er kann das einfach nachmachen.
Nur gegen Rainbowtables kann man etwas tun und da ist salten nunmal Mittel der Wahl, da man damit alle Tables, die so im Internet herumschwirren unbrauchbar machen kann.
Doppelt Hashen bringt dagegen eher weniger gegen die Tables, man muss sie halt in dem Fall nur mehrmals anwenden, was es nur ein wenig aufwändiger macht. Allerdings macht es auch alle Skripte, die die Hashes im normalen Betrieb berechnen müssen langsamer.

Je nachdem, was mit Brute Force gemeint ist. Meiner Auffassung meinte er mit Bruteforce das Rückrechnen der Hashs in Klartext.

Doppelt Hashen bringt dagegen eher weniger gegen die Tables, man muss sie halt in dem Fall nur mehrmals anwenden

Das stimmt ja so nicht. Also ich kenn keine SHA1-Rainbow Table, die 40 Zeichen unterstützt. Mal davon abgesehen, dass diese riesig wäre, würde die Generierung auch Ewigkeiten dauern und würde nur mittles nem Cluster annehmbar schnell gehen.
Und den Geschindigkeitsnachteil, der beim doppelten Hashen entsteht kann man denke ich ausser acht lassen.

[...] Der natürlichste und einfachste Ansatz zu einer algorithmischen Lösung eines Problems besteht darin, einfach alle potenziellen Lösungen durchzuprobieren, bis die richtige gefunden ist. Diese Methode nennt man „Brute-Force-Suche“ (engl. „brute force search“).

Aber es gibt mehrere Möglichkeiten seinen Login vor BruteForce Attacken zu "schützen" um das Risiko einzudämmen.

- IP Sperre ab X versuchen
- Captcha Eingabe
- Weitere Felder zur Überprüfung hinzufügen (z.B PLZ)
- Bei Registrierung eine Mindestlänge für ein Passwort verlangen
- Bei Login eine Pause im Code setzen, so dass man die durchläufe pro Sekunde regulieren kann (in Kombination mit der IP Sperre)
etc.

Naja, den gleichen Effekt hat man, wenn man ein langes Salt nimmt, dass das Passwort+Salt auf über 40 Zeichen bringt. Ich bin einfach kein Fan vom doppelt-Hashen. Das ist, wie wenn man ne Pseudozufallszahl erzeugt und diese dann als Seed benutzt um ne weitere Zufallszahl zu erzeugen. Man könnte meinen, dass diese dann "mehr zufällig" ist, als die erste, was aber nicht der Fall ist.

So lange die Passwort-Eingabe im Klartext erfolgt, ist es meiner Ansicht nach und in Hinsicht auf eine äußerliche BruteFoce-Attacke irrelevant was danach damit veranstaltet und wie es später in der Datenbank abgelegt wird.
Äußerliche BruteForce-Attacken durchlaufen schließlich den exakt selben hash und salt Ablauf, wodurch sie sich auf Klartext-Passwörter verlassen müssen. Und dagegen hilft kein hashen und kein salten.
Hashen und Salten schützt die Passwörter lediglich vor direktem Zugriff, sollte ein Angreifer z.B. über eine SQL-Injection die Ausgabe der Nutzer-Tabelle erreichen. Oder sonst wie. Dann muss der BruteForcer die genannten Rainbow-Tabellen verwenden. Und in diesem Moment stellt diese Sicherheitsmaßnahme nur die letzte Reißleine dar. So weit sollte es gar nicht kommen.

Gegen äußerliche BruteForce-Attacken helfen die Dinge, die vince bereits aufgezählt hat.

Ich begrenz da einfach die Login versuche auf 10 mal. Danach gibst eine längere Pause.
Zusätzlich zur IP Sperre kann man auch noch die Session/cookie Sperre verwenden.
Und natürlich die üblichen Schutz verfahren gegen Spam können hier auch eingesetzt werden.
(Versteckte Felder,Zeitberechnungen unsw.)

Mfg Splasch