Rozhodně neposílejte zprávy koncovým uživatelům, kteří by jim říkali, proč se přihlášení nezdařilo. Poskytujete potenciálnímu útočníkovi kritické informace, které mu pomohou při útoku na vaši aplikaci.

Na druhou stranu neříkající uživateli, proč se jeho přihlášení nezdařilo, je potenciální katastrofou použitelnosti.

Pokud nevyjasníte, zda byla IP adresa uživatele zakázána, nebo zda uživatel místo toho použil nesprávné heslo, může panikařit, protože se mu zdá, že někdo přistoupil k jeho účtu a změnil heslo, aby jej uzamkl. Pokud moje přihlášení s předvyplněným heslem selže, první věc, na kterou myslím, je vloupání, spíše než blokování IP.

Také naivní mechanismus blokování IP může být neúčinný a zavést další problémy. Pro útočníka s dostatečnými prostředky je potenciálně triviální obejít a někdo, kdo sdílí IP adresu s jinými uživateli, by mohl zneužít zákaz IP k zablokování ostatních. Místo toho může být CAPTCHA po n neúspěšných pokusech na IP měkčí řešení a vhodnější pro vaši aplikaci.

Viz také:

• Je dobrým zvykem zakázat IP adresu, pokud se z ní provede příliš mnoho pokusů o přihlášení?
• Proč lidé používají zákazy IP adres, když se IP adresy často mění?

Poskytování obecných zpráv, které zde nebyly zmíněny, má bezpečnostní výhodu.

Alice se pokouší hrubě vynutit účet na Bobově serveru. Při prvních několika pokusech Alice dostane zpět zprávu „Neúspěšný pokus o přihlášení“. Při dalším pokusu se jí zobrazí „Příliš mnoho pokusů o přihlášení z této adresy IP“. Nyní si je vědoma toho, že (a) všechna pověření, která vyzkoušela, až do tohoto okamžiku, jsou neplatná, a (b) musí před několika pokusy udělat něco jiného.

Ale co když se Bob nezmění zpráva? Alice bude pokračovat s hrubou silou a bude i nadále dostávat obecný „Neúspěšný pokus o přihlášení“ při každém pokusu i když jsou pověření správná . Pokud náhodou vyzkouší správná pověření, Bob pokus odmítne, protože byl překročen limit IP, ale Alice nebude vědět, že to je důvod, a bude s ním muset zacházet jako s nesprávným pokusem (pokud nemá nějaké jiné způsob, jak zjistit, co je nad rámec této otázky). Její jedinou možností je pokračovat v hledání, aniž by věděla, zda již vyhledala a přesunula správná pověření.

Všimněte si, že touto výhodou je zabezpečení prostřednictvím neznáma, protože spoléhá na to, že Alice nezná Bobovu politiku blokování IP adres. V závislosti na nastavení může být získání těchto informací triviální. Například pokud má Alice přístup k jinému účtu v systému (snadný, pokud přijímá registraci veřejného účtu), může pomocí pokusu a omylu zjistit, zda bude po příliš mnoha nesprávných pokusech nakonec odmítnut správný pokus.

Další odpovědi vysvětlily kompromis zabezpečení a použitelnosti, takže se nebudu obtěžovat to opakovat.

Ano, technicky vracíte informace, které by mohl útočník použít k doladění botnetu hrubou silou. Kromě toho si nejsem jistý, jak užitečná bude pro standardní uživatele chybová zpráva „K mnoha pokusům o přihlášení z této adresy IP“. Je třeba také poznamenat, že každý ostřílený útočník si začne všímat buď měnícího se typu odpovědi, nebo časového rozdílu, a pravděpodobně stejně přijde na to, co se děje.

Možná budete chtít zvážit použití služby, jako je CloudFlare. Mají skriptovatelné API, které může dynamicky vložit intersticiální stránku nebo aktualizovat pravidlo WAF za určitých scénářů. Troy Hunt má dobrý výukový program, kde to dělá pro Windows Azure pomocí Azure Functions.

V tomto případě jsou bezpečnost a použitelnost v rozporu s cíli. I když nejbezpečnější implementace by neposkytovala žádnou zpětnou vazbu, byla by také nejméně uživatelsky přívětivá. Musíte se rozhodnout, nakolik je váš systém náchylný na brutální vynucování přihlášení, jaké další zmírnění jsou zavedeny a jak efektivní je konkrétní zmírnění, když je vyhodnoceno proti nepohodlí uživatele.

Například kdybych navrhoval přihlášení pro spotřebitelské zařízení Udělal bych to co nejpříjemnější pro uživatele tím, že budu mít podrobnou zpětnou vazbu a zavedl další zmírnění kompenzace. Pokud bych navrhoval přihlášení HSM, nenabízel bych žádnou zpětnou vazbu a obtížné časové limity pro celé zařízení.

Vše záleží na tom, co stavíte. Pokud se jedná o blog nebo jakýkoli jiný oblíbený web, kde není opravdu důležité odmítnout legitimní pokusy a kde opravdu nedůvěřujete robustnosti aplikace, měli byste ji opravdu chránit před čímkoli, co by mohlo být útokem, a nikdy neříkejte proč odmítnete přihlášení.

Pokud vytváříte profesionální aplikaci a očekáváte profesionální přístupy, neomezujte přístupy z jedné IP, pokud je vaše aplikace dostatečně robustní. Pokud tak učiníte, nezapomeňte informovat uživatele o důvodu a zřídit přiměřeně responzivní horkou linku (maximálně 1 pracovní den, abyste si přečetli zprávu a porozuměli jí, a případně zahájili nápravná opatření ). Protože pro velké organizace je běžné nastavit jeden odchozí proxy server pro všechny své přístupy HTTP a HTTPS. Můžete mít tisíce zaměstnanců na různých místech v zemi, všichni používají zdánlivě stejnou IP adresu. Stačí bílý seznam umožňující neomezené připojení od známých serverů proxy, ale musíte být připraveni jej rychle změnit, pokud některý z vašich zákazníků způsobí, že se jeho síť bude vyvíjet, a změní svou adresu proxy.