it-swarm-eu.dev

Ověřování založené na certifikátu vs uživatelské jméno a heslo

Jaké jsou výhody a nevýhody autentizace založené na certifikátu oproti autentizaci pomocí uživatelského jména a hesla? Něco znám, ale ocenil bych strukturovanou a podrobnou odpověď.

AKTUALIZACE

Také mě zajímá, jaké útoky jsou náchylné, např. jako dosud zmíněná hrubá síla, zatímco pro certifikáty se nic nezmiňuje ... co XSRF? Očekává se, že certifikát bude mít kratší životnost a bude možné jej odvolat, zatímco heslo bude žít déle, než administrátorská politika požádá o jeho změnu ...

95
Stefany

1. Uživatelé jsou hloupí

Heslo je něco, co se vejde do paměti uživatele a uživatel si ho vybere. Protože autentizace je o ověření fyzické totožnosti uživatele na dálku (z pohledu ověřovatele), je do procesu nutně zapojeno chování uživatele - hesla se však spoléhají na část uživatele, která je nejvíce notoricky průměrná v zacházení s bezpečností, jmenovitě jeho mozek. Uživatelé prostě nechápou, o čem je entropie hesla. Nejsem za to za to vinný : jedná se o technický předmět, specializaci, která se v brzké době nemůže realisticky stát „zdravým rozumem“. Na druhou stranu je bezpečnost fyzického tokenu mnohem „hmatatelnější“ a průměrní uživatelé se tím mohou stát docela dobře. Evolucionisté by říkali, že lidé byli za poslední milion let pozitivně vybráni, protože ti, kteří se nedokázali držet svých nástrojů na pazourek, nepřežili natolik, aby měli potomstvo.

Hollywoodské filmy lze použít jako model toho, jak si uživatelé myslí o heslech - i když pouze proto, že tito uživatelé chodí také do filmů. Arch Enemy má vždy krátké heslo a rád se o to chlubí a rozdělí stopy, kdykoli je to možné. A britský tajný agent vždy včas uhodne heslo, aby deaktivoval fúzní bombu, která byla vysazena pod královnou oblíbeným květinovým záhonem. Filmy promítají zkreslenou, přehnanou realitu, stále však představují mentální základní linii, na které běžní uživatelé pracují: představí si hesla jako poskytnutí bezpečnosti díky tomu, že jsou „vtipnější“ než útočník. A vždy na tom většina selže.

„Síla hesla“ může být poněkud vylepšena povinnými pravidly (nejméně osm znaků, alespoň dvě číslice, alespoň jedno velké a jedno malé písmeno ...), ale tato pravidla jsou uživateli vnímána jako břemeno a někdy jako nepřekonatelná omezení jejich vrozené svobody - takže uživatelé začnou bojovat s pravidly s velkou kreativitou, počínaje tradičním zápisem hesla na lepicí poznámku. Častěji než ne, pravidla pro posilování hesel tak zpochybňují.

Na druhé straně uživatelské certifikáty znamenají úložný systém, a pokud je tento systém fyzickým zařízením, které uživatel nosí se svým domem nebo klíče od auta, pak se bezpečnost (zčásti) spoléhá na to, jak dobře průměrný uživatel spravuje zabezpečení fyzický objekt a obvykle na něm vykonávají dobrou práci. Alespoň lepší, než pokud jde o výběr dobrého hesla. To je velká výhoda certifikátů.

2. Certifikáty používají asymetrickou kryptografii

„Asymetrie“ je o oddělení rolí. S heslem kdokoli ověřuje heslo, zná v určitém okamžiku heslo nebo data ekvivalentní heslu (dobře, to neplatí v případě PAKE protokolů ). U uživatelských certifikátů je certifikát vydán certifikační autoritou, která zaručuje spojení mezi fyzickou identitou a kryptografickým veřejným klíčem. Ověřovatelem může být odlišná entita a může takový odkaz ověřit a použít jej k ověření uživatele bez získání schopnosti vydávat se za uživatele.

Stručně řečeno, jde o bod certifikátů: oddělit ty, kteří definují digitální identitu uživatele (tj. Entitu, která provádí mapování z fyzické identity do počítačového světa) od ti, kteří autentizují uživatele.

Tím se otevře cesta k digitálním podpisům , které přinášejí nevypovídání. To se týká zejména bank, které přijímají finanční příkazy od online zákazníků: potřebují ověřovat zákazníky (to jsou peníze, o kterých mluvíme, velmi vážná věc), ale rádi by měli přesvědčivé stopy příkazů - ve smyslu: soudce by byl přesvědčen. Pouhou autentizací banka získá jistotu, že mluví se správným zákazníkem, ale nemůže to dokázat třetím stranám; banka by mohla vytvořit přepis falešného připojení, takže je bez zbraní proti zákazníkovi, který tvrdí, že je zarámován samotnou bankou. Digitální podpisy nejsou okamžitě k dispozici, i když má uživatel certifikát; ale pokud uživatel může použít certifikát pro autentizaci, byla většina tvrdé práce hotová.

Hesla jsou také ze své podstaty ohrožena phishingovými útoky, zatímco uživatelské certifikáty nejsou. Přesně z důvodu asymetrie: použití certifikátu nikdy nezahrnuje odhalení tajných dat partnerovi, takže útočník předstírající identitu serveru se nemůže tímto způsobem naučit nic hodnotného.

3. Certifikáty jsou složité

Nasazení uživatelských certifikátů je složité, tedy drahé:

  • Vydávání a správa certifikátů je plná plechovka červa, jak vám může říct kterýkoli prodejce PKI (a opravdu vám to říkám). Zejména řízení odvolání. PKI je asi 5% kryptografie a 95% procedur. To lze provést, ale ne levně.

  • Uživatelské certifikáty znamenají, že uživatelé nějakým způsobem ukládají svůj soukromý klíč pod svým „exkluzivním přístupem“. To se provádí buď v softwaru (stávající operační systémy a/nebo webové prohlížeče to dokážou) nebo pomocí vyhrazeného hardwaru, ale obě řešení mají svou vlastní sadu problémů s použitelností. Dva hlavní problémy, které se objeví, jsou 1) uživatel ztratí svůj klíč a 2) útočník získá kopii klíče. Úložiště softwaru způsobuje ztrátu klíče pravděpodobným problémem (na milost a selhání pevného disku) a sdílení klíče mezi několika systémy (např. Stolním počítačem a iPadem) předpokládá některé ruční operace, u nichž je nepravděpodobné, že budou dobře chráněny před útočníky. Hardwarové tokeny znamenají celou chaotickou činnost ovladačů zařízení, což může být ještě horší.

  • Uživatelský certifikát znamená relativně složité matematické operace na straně klienta; to není problém ani pro anemický Pentium II, ale nebudete moci používat certifikáty z nějakého Javascriptu fackovaného v rámci generického webu. Certifikát vyžaduje aktivní spolupráci ze softwaru na straně klienta a uvedený software má v tomto ohledu tendenci být ergonomicky suboptimální. Průměrní uživatelé se obvykle mohou naučit používat klientské certifikáty pro připojení HTTPS na web, ale za cenu učení, jak ignorovat občasné varovné okno, což je činí mnohem zranitelnější vůči některým útokům (např. Aktivní útoky, kdy se útočník pokouší krmit jim vlastní certifikát falešného serveru).

Na druhou stranu je autentizace založená na hesle opravdu snadná integrace téměř všude. Samozřejmě je také snadné se zkazit; ale přinejmenším nutně nevyvolává nějaké nestlačitelné dodatečné náklady.

Souhrn

Uživatelské certifikáty umožňují oddělení rolí, které hesla nemohou dělat. Dělají to na úkor přidávání hordy problémů s implementací a rozmístěním, což je činí drahé. Hesla však zůstávají levná, protože se hodí do lidské mysli, což ve své podstatě znamená nízkou bezpečnost. Bezpečnostní problémy s hesly mohou být poněkud zmírněny některými podvody (až do včetně protokolů PAKE) a především tím, že obviňují uživatele v případě problému (víme, že průměrný uživatel si nemůže vybrat bezpečné heslo, ale jakákoli nehoda bude stále je to jeho chyba - tak to banky dělají).

94
Thomas Pornin

živatelské jméno/Heslo

  • Pro: Snadné nasazení - vezme jen nějaký kód a bezpečné úložiště dat. V závislosti na zásadách zabezpečení můžete automaticky generovat hesla nebo nutit nové uživatele, aby je vytvářeli.

  • Pro: Snadná správa - obnovení hesla lze (u některých bezpečnostních zásad) provést pomocí automatických nástrojů

  • Con: Pro dobrou bezpečnost by měla být hesla resetována brzy a často. Zapomenutí nebo nezměnění hesla ze strany uživatele představuje buď bezpečnostní riziko, nebo problém s použitelností.

  • Con: Dobrá hesla si lze jen těžko zapamatovat, což vede k problémům uživatelů, kteří znovu používají hesla nebo si je zapisují.

  • Con: Úložiště údajů o heslech je slabou stránkou - pokud vetřelec získá úložiště hesel, dostane zátěž.

  • Con: Všechny části přenosu hesel mohou vést k expozici - webové stránky, které ukládají hesla lokálně pro snadné použití, interní komponenty serveru, které přenášejí v čistém, log soubory v produktech COTS, které ukládají hesla v čistotě. Vzhledem k tomu, že tajemství je součástí přenosu, jste jen tak silní jako vaše nejslabší článek - zabrání se expozici a vyžaduje to jak uživatele, tak vývojáře systému.

Certifikáty:

  • Pro: Nevyžaduje přenos tajemství. Důkaz soukromého klíče neobsahuje žádné tajné informace - zmírňuje nejrůznější slabiny uložení/přenosu.

  • Pro: Vydáno důvěryhodnou stranou (CA), která umožňuje centralizovaný systém správy stavu mezi více aplikacemi. Pokud se certifikát pokazí, může být odvolán. Oprava zlomení hesla musí být provedena samostatně pro každý systém, pokud není použit sdílený ID.

  • Pro: Případ non-repudiation je silnější - ve většině systémů hesel je způsob, jakým je uživatel původně ověřen před vytvořením účtu, velmi slabý a mechanismy resetování hesla mohou nabídnout další faktor věrohodné odmítnutí. U mnoha forem vydávání certifikátů je pro uživatele mnohem těžší říci, že to nebyly oni. Upozornění - jste stále stejně dobří jako zásady vydávání CA.

  • Pro: Slouží více účelům než pouze autentizaci - může také zajistit integritu a důvěrnost.

  • Con: Stále vyžaduje heslo/pin - téměř jakýkoli mechanismus ukládání párů soukromých klíčů je poté odemčen pomocí PIN. Karty SmartCards mohou mít ochranu proti neoprávněné manipulaci a blokování, aby se zabránilo brutální síle, ale to neopravňuje skutečnost, že uživatel napsal poznámku PIN) na poznámku vedle počítače, kde je karta vložena. Někdy problémy s heslem se znovu objeví v menším měřítku s PKI.

  • Con: Složitost infrastruktury - nastavení PKI není snadný úkol a obecně tak nákladné jak při nasazení, tak při údržbě, takže jej lze použít pouze pro velké/drahé systémy.

  • Con: Hlášení a aktualizace stavu certifikátů není snadné - odvolání pověření uživatele, které bylo poškozeno, je obtížné kvůli velikosti a složitosti infrastruktury. Certifikační úřad obvykle generuje seznam CRL, který může nebo nemusí být poskytnut v rámci serveru OCSP. Každá aplikace by pak měla zkontrolovat při každém přihlášení stav CRL nebo OCSP. To zavádí do systému různá časová zpoždění mezi okamžikem, kdy je pověření PKI hlášeno jako ohrožené, a okamžikem, kdy systémy, které se spoléhají na toto pověření, skutečně začnou odepřít přístup. Rychlost aktualizace stavu může být urychlena - ale s vyššími náklady na složitost systému.

Několik dalších poznámek:

Očekává se, že certifikát bude mít kratší životnost a bude možné jej odvolat, zatímco heslo bude žít déle, než administrátorská politika požádá o jeho změnu ...

Nesouhlasím s předpokladem. V systémech, na kterých jsem pracoval, které podporují jak heslo, tak PKI, je politika požadavků na aktualizaci hesla MUCH kratší než politika vydávání certifikátů. Odvolání je jiná plechovka červů - je to pro méně pravděpodobnou událost ohrožení soukromým klíčem. Protože data soukromého klíče se nepřenášejí přes systém, riziko vystavení těmto datům se obecně předpokládá, že je mnohem nižší než riziko vystavení heslu. Z praktických důvodů jsou hesla považována za kratší životnost.

Mám také zájem vědět, jaké útoky jsou náchylné, např. jako dosud zmiňovaná hrubá síla, zatímco u certifikátů není uvedeno nic ... co XSRF?

Tady mícháš jablka a pomeranče. Brutální síla může být životaschopným útokem na oba typy ověřovacích údajů - ale XSRF je útok na základní typ aplikace, který by byl možný bez ohledu na mechanismus ověřování. Pokud to neznamená, že protože by uživatelské jméno/heslo bylo zadáváno s nějakým druhem textového rozhraní, mohlo by být náchylné ke skriptování napříč webem na tomto rozhraní.

Obecně (omlouvám se za nedostatek oficiální terminologie - obvykle se podívám na typické útoky, ale nemám čas):

  • Brutální síla - protože klíčový prostor vašeho průměrného hesla je menší než klíčový prostor asymetrického klíče, je snazší brutální síla hesla. Nicméně, dostatečně malá velikost klíče na certifikátu je také schopná hrubou silou a schopnost brutální síly napadnout klíče roste s CPU schopnostmi nutit krysí závod s velikostí klíče.

  • Vzdělávání hádání - zúžení prostoru klíčů na rozumnou sadu odhadů je u hesel snazší a pro většinu asymetrických algoritmů klíčů to není tak zřejmé, i když v algoritmu RSA existují slabé klíče, takže existuje určitá závislost na tom, jak velký krypto nerd útočník je.

  • Sociální inženýrství - proveditelné v obou směrech, i když s certifikátem uloženým v hardwaru musíte nejen získat kontrolu nad uživatelem PIN), ale také s hardwarem, který ukládá jejich klíč.

  • Útok uvnitř - získání pověření zevnitř systému a jejich použití k emulaci legitimního uživatele - záleží. Pokud jsou hesla uložena nejistě, je to výhodnější pro systém založený na heslech. Ale pokud můžete získat kontrolu nad CA, můžete si vydat legitimní certifikát a pak to záleží na tom, jak je přístup kontrolován.

  • Muž uprostřed - záleží - muž uprostřed může zachytit heslo, pokud heslo není šifrováno při přenosu šifrovacím mechanismem, který jej obchází. To je proveditelné pomocí SSL/TLS. Muž uprostřed však může také zachytit části přenosu PKI, v závislosti na tom, jak se PKI používá. Podpisy PKI bez nonce nebo timestamp jsou otevřeny replikačním útokům člověka uprostřed - může znovu odeslat zachycenou zprávu, pokud neexistuje způsob, jak zjistit, zda je zpráva aktuální nebo jedinečná.

32
bethlakshmi
  1. Uživatelská jména a hesla
    • Je to všechno o tom, co víte. Dáváte tajný kód Word k ověření pomocí služby.
    • To znamená, že pokud je zachyceno v proudu, může být použito. Díky použití šifrování je to nepravděpodobné, ale stále možné. Někdo může udělat člověka uprostřed, aby získal vaše heslo nebo převzal počítač, který obdrží ověření.
    • Uživatelské jméno a heslo lze kdykoli použít na jakémkoli počítači. To je špatná věc, pokud jde o bezpečnost, a dobrá věc, pokud je důležitá dostupnost. Pro banku ... je to špatné. Na facebooku by to opravdu nemělo záležet.
  2. Certifikáty
    • Certifikáty jsou trochu sofistikovanější. Server odešle data klientovi a klient je podepíše a odešle zpět. To znamená, že server nezná soukromý klíč kdykoli, takže zatímco muž uprostřed nebo převzetí serveru povede k tomu, že získají přístup, nemají váš klíč.
    • Certifikáty jsou bolest, kterou je třeba používat. Nemůžete si je pamatovat a mohou být ukradeni.

Nejlepší systém je kombinace. Na klíč vložíte heslo, abyste měli dvoufaktorové ověření. Něco, co znáte (heslo), a něco, co máte (klíč). Čím více vrstev bezpečnosti, tím více bolesti to je. To je skvělý kompromis v celé bezpečnosti.

8
Stephen

Souhlasím s Stephenovými body. Výzkumu kladete těžkou otázku, protože problém obvykle není srovnání jednoho s druhým. Dobrým způsobem, jak pochopit, proč oba existují a nejsou obvykle hodnoceny proti sobě, je soustředit se na používání. Certifikáty jsou vázány na úložiště klíčů na úrovni strojů, a proto jsou skvělé pro ověřování mezi stroji mezi konkrétními stroji, které jsou plánovány předem. Hesla se lidem velmi dobře hodí, protože jsme mobilní a mají tendenci se autentizovat z mnoha systémů způsobem, který je těžké předvídat předem. Certifikáty jsou tedy typické v předem navrženém hardwarovém ověřování a hesla jsou dobrá pro ověřování založené na mobilním wetware. Inteligentní karta je skvělý způsob, jak přidat mobilnímu člověku autentizaci založenou na certifikátech a dalším faktorem procesu.

8
zedman9991

Heslo může být často vynuceno hrubou chybou a může být sociálně upravené, protože, jak si jeho majitel musí zapamatovat, je často mnohem jednodušší než tajný klíč.

Soukromý klíč (dostatečné síly - pro RSA, 2048 nebo 4096 bitů) nemůže být vynucen hrubou silou. Jediným způsobem, jak se autentizovat do systému, který vyžaduje autentizaci založenou na veřejném klíči, je nejprve získat přístup k jinému počítači a získat soukromý klíč. To představuje další úroveň složitosti jakéhokoli útoku. Sociální inženýrství, aby člověk odhalil své heslo, nepomůže, protože heslo pouze dešifruje jeho soukromý klíč, místo aby mu udělil přístup přímo do cílového systému. Sociální inženýrství, aby člověk odhalil svůj soukromý klíč spolu se svým heslem, bude pravděpodobně mnohem obtížnější.

Kromě toho jsou hesla přenášena po síti ze zařízení uživatele do systému, který chce uživatel použít. Soukromé klíče nejsou přenášeny po síti, ani v jasném ani šifrovaném formátu; přenáší se pouze veřejný klíč.

3
yfeldblum

Zdá se, že zapomínáte, že webová stránka může používat certifikáty i hesla. Pokud přijde uživatel s certifikátem, dveře se otevřou. A pokud nemá certifikát, musí se jako vždy přihlásit pomocí jména a hesla.

Tímto způsobem získají uživatelé, kteří o to mají zájem, své osvědčení, všichni ostatní to dělají starým způsobem.

1
Martin

Chtěl bych přidat možnost - Jednorázová hesla. Souhlasím s tím, co ostatní říkali o výhodách a nevýhodách certifikátů a hesel - zařízení OTP vyžadují, aby fungovaly některé součásti typu back-end, ale lze je podle mého názoru integrovat bez větších potíží (Active Directory je trochu jiná, ale jiná systémy nejsou příliš tvrdé).

Kombinace hesla a jednorázového hesla funguje velmi dobře. Můžete jít s jednodušším řešením, jako je Yubikey, s heslem (USB nebo NFC připojení) nebo zobrazeným kódovým fobem.

Obě možnosti lze snadno přidat k operacím založeným na Linuxu. Pokud to chcete udělat ve službě Active Directory, budete si muset zakoupit software pro zpracování kódu a nainstalovat jej na každý AD server. Uživatel poté zadá OTP na začátku pole hesla a poté své obvyklé heslo. Je možné si pro něj vytvořit svůj vlastní modul, ale z toho, co jsem viděl, je nákladově nepřijatelný.

1
Mat Carlson