it-swarm-eu.dev

Proč weby implementují zamykání po třech neúspěšných pokusech o heslo?

Znám důvody, proč nenechat nekonečné pokusy o hesla - pokusy o hrubou sílu nejsou meatpace slabost, ale problém s počítačovou bezpečností - ale odkud získali číslo tři?

Není odmítnutí služby problémem při implementaci zásady blokování, která se snadno aktivuje?

Existuje nějaký tvrdý průzkum, který ukazuje optimální číslo nebo rozsah, který byste si měli zvolit, než zamknete účet, který vyvažuje skutečné bezpečnostní riziko s použitelností?

Když to promyslím, nevidím žádný měřitelný bezpečnostní rozdíl mezi třemi pokusy a 20 pokusy se složitostí hesla, která se dnes běžně používá.

(Znám tuto subjektivitu sukní, ale hledám názory založené na měření)

107
Bradley Kreider

Nedávno na konferenci OWASP AppSec 2010 v Orange County Bill Cheswick z AT&T hovořil o tomto problému podrobně.

Stručně řečeno, neexistuje dostatečný výzkum.

Dlouho jsou zde některé z jeho nápadů na méně bolestivé uzamčení účtu:

  • Nepočítat duplicitní pokusy o heslo (pravděpodobně si mysleli, že to špatně zadali)
  • Vytvořte nápovědu k heslu o primárním hesle a nemějte (slabé) sekundární heslo
  • Umožněte důvěryhodné straně ručit za uživatele, aby mohl změnit své heslo.
  • Zamkněte účet ve zvyšujících se časových krocích
  • Připomeňte uživateli pravidla pro heslo.
75
Zian Choy

Každý web, který splňuje požadavky PCI Data Security Standards, musí dodržovat oddíly

  • 8.5.13 (Omezit opakované pokusy o přístup zamknutím uživatelského ID po ne více než šesti pokusech)
  • 8.5.14 (Nastavte dobu uzamčení na třicet minut nebo dokud administrátor nepovolí ID uživatele).

To je bohužel důvod, proč mnoho webů přijímajících kreditní karty má drakonické zásady blokování, i když jejich návrháři nemusí nutně souhlasit s tím, co implementovali.

Úpravy: - Upozorňujeme, že tyto požadavky se vztahují pouze na systémy pro „uživatele, kteří nejsou spotřebiteli“, takže by neměli mít vliv na stránky zákazníků přijímající karty.

37
realworldcoder

Moje zkušenost je, že uzamčení mechanismů klesá v popularitě (alespoň u webových aplikací). Namísto uzamčení účtů po řadě neúspěšných pokusů začnete požadovat další informace pro úspěšnou autentizaci.

22
Tate Hansen

Nebylo by divu, kdyby to přišlo z pravidla baseballu "Tři údery", spíše než cokoli technického.

Jedno zdůvodnění (pro alfanumerická hesla stejně) je

Obvyklým neúspěšným pokusem je problém typu nesprávný typ nebo CAPS on/off. Takže se pokusíte přihlásit a nechat se odmítnout (1), zkuste to znovu, protože si myslíte, že jste špatně zadali (2), a poté si uvědomíte, že klíč CAPS je zapnutý, takže se dostanete na třetí pokus.

Opravdu to neplatí pro odblokování mobilních telefonů ze sítě, když se obvykle zadává číselný kód.

Lepšími návrhy jsou stále se zvyšující zpoždění mezi opakovanými neúspěšnými pokusy o přihlášení. Nejprve povolíte okamžité opakování, pak 1 sekundu, 2, čtyři, osm ... Rychle čekáte minutu mezi pokusy, které stačí k vyjádření jakéhokoli útoku hrubou silou.

18
Gary

Souhlasím s OP. Pokud přemýšlíte o tom, co vás blokování chrání před, není rozdíl mezi 3 nebo 20 pokusy (nebo 100, v tomto ohledu). Vše, čeho dosáhnete pomocí těchto blokování, kromě potrestání zapomenutých uživatelů, je zabránit útoku brutální silou. Můžete jej také použít k vyvolání varování, že útok probíhá, ale to není primárním účelem (pokud by to znamenalo, znamená to, že úmyslně DoSing svým uživatelům jen usnadňujete svou vlastní monitorovací práci. To není velmi dobrá praxe).

Pokud má někdo vaši databázi hesel a může na ni off-line hacknout, má neomezené pokusy. Váš limit 20 odhadů tam není dobrý.

Pokud se někdo pokouší on-line hrubou silou, vše, co potřebujete, je heslo, které vydrží „dost dlouho“: dost dlouho na to, aby vaše IRT odpovědělo, nebo dost dlouho na to, aby se útočník vzdal.

Databáze hesel Conficker je mírně pod 200 hesly, IIRC a je plná některých nejhloupějších hesel na planetě. Nyní předpokládejme, že vaše heslo není na tomto seznamu. Pokud povolíte 20 pokusů o heslo, řekněme za 15 minut, bez uzamčení, útočníkovi potrvá více než dvě hodiny, než se seznamem dostane.

Ve skutečnosti, i když zúžíte svůj hádající seznam na hesla vytvořená z relevantních informací o tomto uživateli, jako je kidsname02, birthday99 atd., Stále skončí alespoň několik desítek hesel, čímž se slovníkový útok prodlouží na hodinu nebo více. Toto neustálé, chybné hádání v průběhu času je to, co by mělo spustit vaše poplachy, ne hrstka chybných hesel za pár minut.

Pokud tedy můžete uživatelům zabránit v tom, aby se vyhýbali nejzákladnějším úskalím hesla, můžete šťastně přijmout mnoho chybných pokusů o heslo.

Osobně nakreslím čáru na 15. Úplně libovolně a většinou praktickou věcí: Zjistil jsem, že se jakýkoli skutečný uživatel vzdal dlouho předtím. Obvykle, pokud existuje tolik pokusů, je to proces nebo relace, která visí někde se starými pověřeními. A pokud tomu tak není, můžeme mluvit o hledání útoků.

15
itinsecurity

Je to hloupé svévolné pravidlo, které přichází s rizikem podivného druhu útoku DDOS. Řekněme, že Marv nenávidí web X a web X má Y počet pokusů o uzamčení. Marv by mohl zvýšit nějaké vážné peklo tím, že skript automaticky zkusí náhodná jména Y krát s falešnými hesly. I kdyby heslo fungovalo, Marvovi by to pravděpodobně nezáleželo a ignorovalo by ho. To by účinně uzamklo mnoho uživatelů pro web X a způsobilo by mnoho frustrace uživatelů a bůh jim pomohl, pokud jsou bankou, kterou musíte zavolat, aby obnovili své heslo. Překvapuje mě, že to nikdo nezkusil.

11
AmaDaden

Věřím, že na tuto debatu přijdu pozdě, ale doufám, že sem přidám něco užitečného.

Zásady blokování účtů (s počtem po sobě jdoucích neplatných pokusů obvykle v rozsahu jednotlivých číslic pro většinu organizací) nebyly navrženy pouze proti automatickým útokům brutální síly.

Jedná se spíše o ochranu před hádáním hesel lidskými útočníky, zejména jednotlivci, kteří již znají část hesla. Útočníci by mohli získat fragmenty hesel

  • surfování po rameni
  • uhodnutím vzorců používaných jednotlivcem pro výběr jejich hesel. Koneckonců, kolikrát jeden použil hesla s prvky v sekvenci, jako je heslo # 01 , heslo # 02 atd.

Nevýhodou je samozřejmě to, že s nízkou prahovou hodnotou musí podnik odmítnout službu a související náklady. Doporučená hodnota je Bílá kniha o doporučených postupech blokování účtů , vydaná společností Microsoft. Rovněž vysvětluje, jak odhadnout pravděpodobnost úspěšného útoku pomocí parametrů v zásadách blokování účtů systému Windows:

Předpokládejme například, že správce resetuje heslo, když je účet uzamčen s hodnotou registru LockoutDuration 0. Pokud je hodnota registru LockoutDuration nastavena na 0 a hodnota registru LockoutThreshold nastavena na 20, má uživatel se zlými úmysly 20 odhadů použití proti Heslo. Pokud je doba uzamčení 30 minut, má uživatel se zlými úmysly 20 odhadů každých 30 minut proti tomuto heslu, dokud se nezmění. Jedná se o velmi významný rozdíl v celkovém počtu odhadů, které má uživatel se zlými úmysly k dispozici.

Oproti tomu, pokud správce nastaví maximální věk hesla na 42 dní, první škodlivý uživatel má pouze 20 odhadů proti danému heslu, zatímco druhý škodlivý uživatel má 40 320 odhadů (20 pokusů o vždy uzamčení, vynásobených 48 uzamčení každý den, vynásobeno 42 dny před tím, než uživatel změní heslo). Při výchozím nastavení hesla existuje přibližně 10 ^ 12 možných hesel. To znamená, že uživatel se zlými úmysly má přibližně 0,000004% (%) šanci uhodnout heslo. S optimalizovaným odhadem by toto procento pravděpodobně bylo větší procento.

Pro žádného laika samozřejmě není snadné vybrat vhodné číslo a taková rozhodnutí by měla být pečlivě zvážena. Lze tedy bezpečně předpokládat, že některé organizace se nepokusily vypočítat peněžní dopady své politiky blokování účtů a související výhody uvolnění své politiky při zachování výhody zabezpečení, kterou poskytuje.

10
Vineet Reynolds

K tomu existují dva aspekty; první, jak jste zmínil, je zabránit útokům hrubou silou.

Za tímto účelem by opravdu měl udělat jakýkoli počet pokusů - 3, 5, 20, 2000 ... s náležitou politikou hesel (délka + složitost + ...), která poskytne dostatečně velký klíčový prostor, libovolný druh škrcení (X počet pokusů za hodinu) zajistí, že hrubá síla nutící celý prostor bude trvat docela několik desetiletí. (Vypočítat).

I když - a to by měl být požadavek - je uzamčení pouze dočasné a po krátké době se automaticky odemkne.

Počet pokusů před uzamčením je tedy libovolný.

Hraje se zde však další, jemnější, nematematický problém:

Pro jednoho uživatele nemá smysl dávat opakovaně nesprávné heslo opakovaně 2000krát za sebou.

To znamená, že pokud si zvolíte libovolně 2000, víte dlouho předtím, že to NENÍ legitimní uživatel. Skutečně tedy jde o to, co dává podniku smysl, a kompromisy v oblasti analýzy rizik zaměřené na podnikání.

Myslím, že historicky byl kompromis nakloněn směrem k rizikové straně - protože hesla byla kratší a méně složitá, rozdíl 3 nebo 10 byl větší. Lidé měli také méně hesel, takže si je lépe zapamatovali ... A uživatelé byli obecně technicky důvtipnější.

V současné době tři skutečně nedávají smysl, vzhledem k dopadu na podnikání. Je to opravdu otázka, co má smysl pro vaše aplikaci, jaké typy uživatelů, jak často se přihlašují atd. Obvykle doporučuji zjistit, kolik neúspěšných, legitimních pokusů je pravděpodobné, pak zdvojnásobit to.

( Jak @realworldcoder zmínil , PCI si vybral libovolně šest, a pokud jste předmětem PCI, nemáte zde moc rozhodnutí. Jinak zvolte číslo, které vám dává smysl.)

8
AviD

Pokud jde o návrhy časových inkrementací „blokování“, které zpožďují opakované neúspěšné pokusy a tím zabraňují násilnému násilí, nezapomeňte, že to funguje pouze na cílených uživatelských útocích.

Pokud útočníkovi záleží pouze na získání vstupu do systému, mohl by provést první první útok (Cyklujte všechna známá/uhádnutá uživatelská jména před přechodem na další heslo). Dodejme, že pokud by to bylo provedeno správně, mohlo by to pocházet z distribuované sítě strojů, je docela snadné vidět, že systém zpoždění také nefunguje.

Jak již uvedli ostatní, je důležité sledovat neúspěšné pokusy o včasné odhalení útoků.

Ano, 3 pokusy jsou zcela svévolné a představují riziko DoS. Opravdu si přeji, aby lidé přestali používat pro veřejné systémy ... Prosím!

Další řešení: identifikace 2 faktorů. Žetony RSA. Kdybychom měli způsob, jak osobně vlastnit jediný token RSA s 'id číslem'. Mohli bychom pak zaregistrovat toto „id number“ u jakéhokoli systému, který by pak vyžadoval aktuální hodnotu z tokenu spolu s heslem k přihlášení.

Ale to představuje celou řadu problémů pro implementaci a důvěru ...

7
Dan McGrath

Společnosti, které jsou veřejné (prodávají akcie na burzách), jsou regulovány zákonem Sarbanes-Oxley Act a jsou několikrát ročně podrobovány auditu shody. Kritické softwarové aplikace musí splňovat určité bezpečnostní funkce, které byly jednou z nich pro uzamčení účtů po neúspěšných pokusech o heslo.

Většina těchto aplikací dělá integraci do společnosti Active Directory, která již tyto funkce povolila.

3
Jose

Zde je opravdu pěkné čtení, které jde přes to, co věřím, že hledáte. Vzali data od vysokoškoláků pomocí politiky tří stávek, deset stávek a nekonečné stávky, aby navrhli, abychom zvýšili počet ze tří na deset (protože přibližně trojnásobí úspěch přihlášení).

Návrat do subjektivního pohledu zde ...

Proč většina míst používá politiku tří úderů? Je to určitě jen heuristika, která se postupem času vyvinula. Tři pokusy jsou více či méně prostředím pro administrátory a uživatele, protože tři šance jsou více než dost.

Myšlenka za heslem je , měli byste znát. Opravdu byste neměli potřebovat více než jeden pokus. Chápu, že došlo k chybám, ale ve válce ... máte opravdu jen jednu šanci, abyste dokázali, že jste spojenec, že?.

3
user124863

Museli vybrat náhodně 3. To je extrémně nízké. Možná měli v minulosti bezpečnostní problémy a vybrali spíše nízké číslo uzamčení, než aby problém vyřešili nebo opravili správně.

Upřednostňuji způsob uzamčení uživatele ve zvyšujících se časových intervalech. I když bych to neudělal z uživatelského jména, místo toho používám IP adresu dané osoby, protože osoba mohla zkoušet více uživatelských jmen. Nastavil jsem blokovací čas na (počet neplatných pokusů o přihlášení) ^ 2 sekundy, jakmile uživatel dosáhl 5 neplatných pokusů. Pokud uživatel nezná své heslo při relativně nízkém počtu pokusů, použije nástroj pro obnovení hesla většinou, pokud jej web poskytuje. Pokud je to skutečný pokus o hack, bude to pro hackera tak frustrující, že se nakonec vzdají. Boti se budou snažit tolikrát, že se téměř nikdy nebudou moci přihlásit ... například, pokud vyzkoušeli 1000 hesel (což by vlastně trvalo dlouho, stejně by to dělali), museli by počkat 11 1/2 dne, než by mohli zkuste 1001. heslo. Dalo by se snadno zvýšit odrazující schopnost zvýšením multiplikátoru na ^ 3. Cokoli výše, co by mohlo být příliš vysoké pro platné lidské uživatele.

2
Rush Frisby

Není to tak dávno, co jsem implementoval schéma zabezpečení přihlášení, které dodržovalo tato základní pravidla:

  1. První neúspěšný pokus dává okamžitou zpětnou vazbu. Pravděpodobně tlustý prstoklad to.
  2. Druhý až pátý neúspěšný pokus způsobil zpoždění reakce o jednu sekundu za neúspěšný pokus. např. 2 sekundy, 3 sekundy, 4 sekundy ...
  3. Pokud by pátý pokus selhal, byla relace ukončena a byla jim předložena zpráva, že bude muset zavřít prohlížeč a zkusit to znovu.

Pro mě to bylo více než dostačující, aby se zabránilo útokům brutální síly; by bylo pro koncového uživatele nanejvýš nepříjemné a nevytvořilo by pro podporu žádnou další práci.

2
Josh