it-swarm-eu.dev

Jaké je použití klientské nce?

Po přečtení části I knihy Rossa Andersona Bezpečnostní inženýrství a objasnění některých témat na Wikipedii jsem narazil na myšlenku Client Nonce (cnonce). Ross to ve své knize nikdy nezmíní a snažím se pochopit účel, který slouží při ověřování uživatelů.

Normální neteř se používá k tomu, aby se předešlo opakovaným útokům, které zahrnují získání vypršení platnosti pomocí vypršení odpovědi. Server poskytuje klientovi nonce (Number used ONCE), které je klient nucen použít k hašování své odpovědi, poté pak hashuje odpověď, kterou očekává, s poskytnutým nonce a pokud hash klienta odpovídá hashe hash server pak server může ověřit, zda je požadavek platný a čerstvý. To je vše, co ověřuje; platné a čerstvé .

Vysvětlení, která jsem pro klienta našel, jsou však méně přímočará a sporná. Zdá se, že stránka Wikipedia pro autentizaci digitálního přístupu a několik odpovědí zde na Stackoverflow naznačuje, že klientská esence je používána k zabránění útokům vybraným prostým textem. S touto myšlenkou mám několik problémů:

  • Pokud člověk umí čichat a vkládat pakety, největší zranitelností je útok typu člověk ve středu, který nedokáže překonat ani neteř, ani cnonce, takže oba nemají význam.
  • Jak za předpokladu, že útočník nechce zaútočit na útok typu člověk uprostřed, a chce obnovit podrobnosti autentizace, jak cnonce poskytuje další ochranu? Pokud útočník zachytí komunikaci a odpoví na požadavek svou vlastní neteří, pak odpověď klienta bude hašování neteky, dat a cnonce navíc k cnonce v nešifrované podobě. Útočník má nyní přístup k nonce, cnonce a hash. Útočník nyní může hashovat své tabulky Rainbow pomocí nonce a cnonce a najít shodu. Proto cnonce poskytuje nulovou dodatečnou ochranu.

Jaký je účel klanu?

Předpokládám, že existuje část rovnice, kterou nerozumím, ale ještě jsem nenašel vysvětlení toho, co je tato část.

EDITOVAT Některé odpovědi naznačují, že klient může poskytnout nonce a bude sloužit stejnému účelu. To však narušuje model výzva-odpověď, jaké jsou důsledky tohoto?

85
user2014

A nonce je jedinečná hodnota vybraná entitou v protokolu a používá se k ochraně této entity před útoky, které spadají pod velký deštník „opakování“.

Zvažte například ověřovací protokol založený na hesle, který vypadá takto:

  • server odešle klientovi „výzvu“ (údajně náhodná hodnota c )
  • klient odpoví zasláním h (c || p) , kde h je bezpečná hashovací funkce (např. SHA-256), p je heslo uživatele a ' || ' označuje zřetězení
  • server vyhledá heslo ve své vlastní databázi, zkompiluje očekávanou odpověď klienta a zjistí, zda odpovídá tomu, co klient odeslal

Hesla jsou tajné hodnoty, které se hodí do lidských mozků; nemohou být proto příliš složité a je možné vytvořit velký slovník, který bude obsahovat uživatelské heslo s vysokou pravděpodobností. Výraz „velký“ mám na mysli „lze sčítat pomocí clusteru střední velikosti za několik týdnů“. V současné diskusi akceptujeme, že útočník bude schopen rozbít jediné heslo tím, že stráví několik týdnů výpočtem; to je úroveň zabezpečení, kterého chceme dosáhnout.

Představte si pasivního útočníka: útočník odposlouchává, ale nemění zprávy. Vidí c a h (c || p) , takže může pomocí svého clusteru výčet potenciálních hesel, dokud není zápas nalezeno. To pro něj bude drahé. Pokud útočník chce zaútočit na dvě hesla, musí tuto práci provést dvakrát . Útočník by chtěl mít trochu sdílení nákladů mezi dvěma případy útoku pomocí předběžných tabulek („Duhové tabulky“ jsou pouze druh předkompilované tabulky s optimalizovaným úložištěm, ale vytvoření tabulky Rainbow stále vyžaduje výčet celého slovníku a hashování každého hesla). Náhodná výzva však porazí útočníka: protože každá instance zahrnuje novou výzvu, vstup hashové funkce se bude lišit pro každou relaci, i když se použije stejné heslo. Útočník tedy nemůže vytvářet užitečné předkompilované tabulky, zejména tabulky Rainbow.

Nyní předpokládejme, že se útočník stane aktivním. Místo toho, aby jednoduše sledoval zprávy, bude aktivně měnit zprávy, vynechávat některé, duplikovat jiné nebo vkládat vlastní zprávy. Útočník nyní může zachytit pokus o připojení od klienta. Útočník si vybere a odešle svou vlastní výzvu ( c ') a čeká na odpověď klienta ( h (c' || p) ). Všimněte si, že skutečný server není kontaktován; Útočník jednoduše zruší připojení náhle okamžitě po reakci klienta, aby simuloval benigní chybu sítě. V tomto modelu útoku útočník udělal velké zlepšení: stále má výzvu c ' a odpovídající odpověď, ale výzva je hodnota, kterou si útočník vybral, když si vybral viděl fit. Útočník vždy provede stejnou výzvu c '. Použití stejné výzvy pokaždé umožňuje útočníkovi provádět předběžné výpočty: může vytvářet předběžné tabulky (tj. Tabulky duhy), které používají tuto zvláštní „výzvu“. Útočník nyní může zaútočit na několik různých hesel, aniž by u každého z nich vznikl výčet slovníku.

Tento problém se vyhýbá klientovi nonce . Protokol se stává:

  • server odešle náhodnou výzvu c
  • klient vybere nonce n (mělo by být pokaždé odlišné)
  • klient odešle n || h (c || n || p)
  • server recomputes h (c || n || p) (pomocí p ze své databáze) a uvidí, zda se tato hodnota shoduje co klient poslal

Protože klient do vstupu hashovací funkce pro každou relaci zahrnuje novou náhodnou hodnotu („nonce“), bude vstup hashovací funkce zřetelný vždy, i když si útočník může vybrat výzvu. Tím se překonají předběžné tabulky (Rainbow) a obnoví se naše zamýšlená úroveň zabezpečení.

Hrubou emulací jedinečné nonce je uživatelské jméno. Dva rozdílní uživatelé ve stejném systému budou mít odlišné názvy. Uživatel si však při změně hesla uchová své jméno; a dva odlišní uživatelé mohou mít stejné jméno ve dvou odlišných systémech (např. každý unixový systém má „kořenového“ uživatele). Takže uživatelské jméno není dobrý nonce (ale je to stále lepší než mít vůbec žádné klientské nonce).

Souhrnně lze říci, že klientská nce je o ochraně klienta před útokem z opakovaného přehrávání („server“ je ve skutečnosti útočník, který pošle stejnou výzvu každému klientovi, kterého chce napadnout). To není nutné, pokud je výzva spuštěna prostřednictvím kanálu, který zahrnuje silné ověření serveru (například SSL). Password Authenticated Key Exchange jsou pokročilé protokoly, které zajišťují vzájemnou autentizaci založenou na hesle mezi klientem a serverem, aniž by bylo třeba a priori důvěřovat („kořenové certifikáty“, když klient SSL ověřuje certifikát serveru SSL) a chrání proti aktivním a pasivním útočníkům (včetně útoku typu „cluster-for-two-weeks“) na jedno heslo, takže je to přísně lepší než výše uvedený protokol, nonce nebo noce nonce).

138
Thomas Pornin

Dovolte mi, abych odpověděl na maso vaší otázky: „Za předpokladu, že se útočník na vteřinu nechce zapojit do útoku typu člověk-uprostřed, a chce získat zpět autentizační údaje, jak poskytuje cnonce další ochrana?"

Obvykle klient nejen zahrnuje nonce s požadavkem, ale podepisuje celá žádost včetně nonce. To znamená, že i když útočník zachytí zprávu mezi klientem a serverem:

  1. Útok opakování nebude fungovat (protože server sleduje klientské ncesy).
  2. Útočník nemůže pouze vygenerovat novou zprávu s novým klientem nonce, protože neví, jak podepsat novou zprávu vhodně (tj. postrádá tajný klíč klienta nebo soukromý klíč).
7
Bosh

Podle RFC 2617 parametry cnonce a nc chrání před vybranými útoky prostého textu. Jak to chrání před takovými útoky?

Pokud Eva změní to, co server pošle klientovi, co získala Eva? Eva nemůže vygenerovat h(password || nonce) from h(password || fake_nonce) a teoreticky to vypadá, že server by neměl akceptovat h(password || fake_nonce) stejně, protože server by měl vědět, co je nonce, je vydáno a co to není?.

1
paynes_bay

Myslím, že by bylo dobré přečíst si, jak se hodnota nonce používá v něčem jako Oauth . Stručně řečeno, když aplikace používající OAuth podá požadavek na server podporovaný OAuth), žádost musí obsahovat spoustu polí, z nichž dvě jsou časová značka a nonce. Účel formuláře je zřejmé: udává časový rámec, ve kterém byla zpráva odeslána, aby server mohl lépe odhadnout, zda je zpráva zastaralá, což je zjevně spousta náhodných znaků/bytů.

Když je celá záhlaví OAuth) hashováno se zákaznickým tajemstvím, jsou zahrnuta obě tato pole. Poté má podpis připojený k žádosti (ať už jde o parametry dotazu nebo HTTP hlavičky) a odeslán na Skutečné tělo požadavku není hash .

Server OAuth by měl sledovat předchozí sadu hodnot N nonce pro daného klienta, aby se ujistil, že nejsou znovu použity. Vzhledem k tomu, že se tělo zprávy může změnit (v podstatě nemá žádné vliv na hash) je důležité mít něco jiného, ​​co se změní (tj. nonce), aby se zajistilo, že požadavky jsou jedinečné. Vzhledem k povaze otevřeného/prostého textu HTTP je to velmi důležité.

Pomůže to vůbec objasnit jeho účel? (Doufám :)).

1
OJ.