Wachtwoord beveiliging

Dat is volgens mij wat ze (OWASP) bedoelen met "threshold governor which is in turn linked to the intrusion logging mechanism". Lijkt me nuttig, maar niet alle aanvallen gaan via de login:
1. iemand die de user table al heeft bemachtigd kan dan natuurlijk nog steeds proberen om de hashing te hacken door de uitkomsten van een vermoed of bekend algoritme met de database te vergelijken zonder verdere inlogpogingen te doen.
2. iemand die ook een low security account heeft, zelf zijn wachtwoord kan wijzigen EN de resulterende hask kan achterhalen kan zijn attack via de "wijzigen" functie doen (Die moet je dus ook tegen brute force beveiligen).

Eigenlijk lopen er drie discussies door elkaar:
A. beveiliging tegen rechtstreekse brute force aanvallen die gebruik maken van de (noodzakelijke) implementatie van het algoritme op de server
B. hoe zwak of sterk de verschillede algoritmes zijn (inclusief gecombineerde algoritmes als pbkdf2 en het gebruikte hash_hmac algoritme)
C. de keuze van eventueel salt.

Om nog even op C terug te komen: Ik begrijp niet wat er tegen het gebruik van salt is. Hashing algoritmes kunnen zwak zijn of in de toekomst verzwakt raken doordat iemand een manier bedenkt om het aantal mogelijkheden dat moet worden afgezocht te beperken, om de hash sneller te berekenen of gewoon door snellere computers. Salt kan dan helpen. De bij punt 2 bedoelde hacker zal vermoedelijk last hebben van variabel salt (of heet dat pepper?), ook omdat het dan geen zin heeft om zijn eigen hash bij een gebruiker met meer rechten op te slaan. Dus gooi dat er in zou ik zeggen. En beide zullen last hebben van voor hen onbekend salt, maar hoe hou je variabel salt geheim als je user table op straat kan belanden? Dus gooi er ook fixed salt in. Hoe willekeuriger dat is hoe beter. Rest de vraag hoe lang het moet zijn.