Hogy lehet védekezni a jelszópróbálgatós támadás ellen?

Akkor kombináld a dolgokat.

Egy IP-ről max 3 hibás bejelentkezés, utána captcha.

Ha ugyanarra a user accountra (akár más IP-ről is) 3 hibás bejelentkezés jön, akkor az adott user acchoz minden további bejelentkezésnél (az első sikeresig) szintén captcha.

+1 a hash-re, a bcrypt tökéletes, a sózás és minden meg is van oldva vele. Használd azt.

A másik meg, hidd el ha próbálkoznak is, előbb kifogynak a proxyk-ból, mint hogy eltalálják a jelszót.

Pl még ha 5 próbálkozás/jelszó-nál is dobjuk a captcha-t, akkor is már 100 próbálkozáshoz 20 proxy-t végig kell járni.

Egy kisebb jelszó gyűjteményben is azért pár száz vagy ezer darab jelszó szokott lenni.

Amit te keresel az a token alapú védelem. A lényege, hogy minden formhoz hozzárendelsz egy tokent, amely az oldal betöltődésekor generálódik. A post vagy akár get eseménykor megvizsgálod, hogy a form tokenje létezik e, és ha igen, akkor megbízol benne jöhet. Ha nem létezik a token, akkor valószínűleg hamis vagy már lejárt (vagyis lehet lopott), így nem bízol meg benne és a feldolgozást elutasítod.

A token átlag user számára láthatatlan, csak te tudsz róla jó esetben. Viszont, ha a támadó kinézi a tokent a kódból, akkor sincs gond, mert azzal a tokennel csak 1 támadást tud indítani. Többet nem felhasználható a token.

Az ip cím alapú védelemmel az a baj, hogy már egy kezdő támadó is, akit komolyan lehet venni ismeri a vpn-t. Azon keresztül pedig akár több ezer ip címről is indíthat kérést az oldaladra. Komoly támadók esetén biztos, hogy nem közvetlenül egy ip címről fognak támadni.

A capcha-val pont az a baj, amit te magad is említettél. A felhasználói élményt csökkenti. Ezen kívül ha nem valamilyen komolyabb plugint használsz erre, akkor úgyis meg fogják kerülni. A komoly pluginokkal pedig az a baj, hogy egyrészről meg kell bíznod bennük, másrészről bármikor leállíthatják a fejlesztést, ami azt jelenti, idővel valaki talál ellenszert hozzá.

Az pedig nagyon ritka, és egyáltalán nem vall komoly támadóra, aki elkezdi egyesével beírni a jelszavakat és próbálgatni az által, hogy frissíti a weboldalt. Még bottal is az oldal frissítés miatt jelentősen megnő a feltörési idő. Ezen kívül ha alkalmazol olyat, hogy esetleg 3 próbálkozás után 1, 5 próbálkozás után 3, 10 próbálkozás után 15 percre tiltod a form küldését (adott esetben a bejelentkezést), akkor ez tovább növeli a feltörési időt.

A token további előnye, hogy bármilyen form esemény esetén használhatod, akár ajax kérések esetén is. Csak az ajax esetén figyelni kell, hogy js-el cseréld a tokent a kérés küldése után, ha csak nem 1x használatos egy form. Például hozzászólásoknál érdemes frissíteni, de mondjuk egy e-mail feliratkozásnál már nem feltétlenül.

Ha jól sejtem a korábbi válaszoló a CSRF-re gondolt, amikor a tokent említette.

Ezek általában nem vagy-vagy megoldások a captcahval és az IP alapú rate limittel, hanem egyszerre szoktak lenni.

"Köszönöm a részletes választ ez jól hangzik de ha jól értem kikerülhető ez is . Mert ha valaki megírja a token visszafejtőt akkor írhat egy próbálgatót."

Nem tudom mire gondolsz, de a token az bármi lehet. Általában, ha én használom, akkor egy 10 karakter hosszú random hash szokott lenni.

Itt a lényeg, hogy az oldal betöltésekor generálsz egy random hash-t, amit tárolsz akár session-ben akár adatbázisban. Majd ezt belerakod egy hidden inputba. Ez elpostolódik a formmal együtt és mielőtt feldolgoznád az információt ellenőrzöd, hogy a token létezik e a sessionben vagy az adatbázisodban.

Itt nincs semmi visszafejteni való. Még akár ki is írhatod az oldaladra, hogy mivel generálod a token hash-t az sem számít. Mert a támadó akkor sem tud a session-be belecsempészni, vagy akár adatbázisba beleírni saját tokent.

A token felhasználásakor pedig, amikor azonosítottad és jöhet a post, akkor megszünteted a session tokent (vagy törlöd a rekordot a db-ből). Így újra kell generálni az oldalt, hogy valaki a formhoz új tokent kapjon. Illetve minden tokennek adasz lejárati időt. Mondjuk egy login esetén 5 percet. Ha pedig valahol nem tudod mennyi idő lenne elég akkor adsz 1 órát. Általában ennyi elég szokott lenni. És ha valaki 1 óra után akarja magát azonosítani a tokennel, akkor is elutasítod. De ez persze plussz bonyolítás.

---

"Ha jól sejtem a korábbi válaszoló a CSRF-re gondolt, amikor a tokent említette. "

CSRF - cross-site request forgery

Ez a támadási típus neve és nem a védelemé :) persze sok helyen CSRF védelemnek hívják, de ez a CSRF elleni védelem valójában. A kérdező problémája egyébként pontosan ez. Általánosságban megfogalmazva az ő gondja az, hogy a felhasználóban nem bízik meg, pontosabban a felhasználó által küldött információkban.

Erre való a token :)