Jako obvykle vezměte cokoli, co souvisí se Stevem Gibsonem, s kamionem soli. Povinný attrition.org odkaz .

Pojďme se podívat na Gibsonův popis jeho protokolu.

• QR kód zobrazený poblíž přihlášení výzva obsahuje adresu URL ověřovací služby pro web. URL obsahuje bezpečně vygenerované dlouhé náhodné číslo, takže každá prezentace přihlašovací stránky zobrazuje jiný QR kód. (V krypto kruzích je toto dlouhé náhodné číslo známé jako „nonce.“)

• Aplikace pro ověřování SQRL chytrého telefonu kryptograficky hashuje název domény webu, který uživatel zadal „hlavní klíč k vytvoření páru veřejného klíče pro konkrétní web.

• Aplikace kryptograficky podepíše celou adresu URL obsaženou v kódu QR pomocí soukromého klíče pro konkrétní web. Vzhledem k tomu, že adresa URL obsahuje zabezpečené dlouhé náhodné číslo (nonce), je podpis pro tento web jedinečný a kód QR.

• Aplikace vydá zabezpečený dotaz HTTPS POST na QR URL kódu, což je služba ověřování webu. POST poskytuje veřejný klíč pro konkrétní web a odpovídající kryptografický podpis adresy URL QR kódu.

• Ověřující web přijímá a potvrzuje dotaz POST vrácením standardního protokolu HTTP „200 OK“ bez dalšího obsahu. Aplikace SQRL potvrzuje úspěšné odeslání QR kódu podepsaného uživatelem.

• Ověřovací web má adresu URL, která obsahuje nonce, který se vrátil z přihlašovací stránky prostřednictvím uživatelského smartphone. Má také kryptografický podpis této adresy URL a veřejný klíč uživatele pro konkrétní web. Používá veřejný klíč k ověření, že podpis je platný pro adresu URL. To potvrzuje, že uživatel, který vytvořil podpis, použil soukromý klíč odpovídající veřejnému klíči. Po ověření podpisu ověřující web rozpozná nyní ověřeného uživatele podle veřejného veřejného klíče pro konkrétní web.

největší věc, která na mě vyskočí, je použití “ hlavního klíče “ uživatelem. Pokud čtu protokol správně, tento jediný hlavní klíč řídí celou online identitu uživatele …

Pravděpodobně je tento hlavní klíč uložen v telefonu uživatele v databázi aplikace. Což otevírá obrovský propastný vektor útoku v podobě malwaru navrženého speciálně ke krádeži hlavního klíče.

Pojďme tedy porovnat rozdíl mezi tím, co se stane, když dojde k prolomení hesla, a tím, co se stane, když bude hlavní klíč bude ohroženo. Za předpokladu, že dodržujete správné postupy při používání dlouhých, jedinečných a vysoce náhodných hesel uložených ve správci hesel, musíte pouze změnit jedno heslo, pokud dojde k jeho zneužití. Co se stane, pokud dojde k prolomení vašeho hlavního klíče? bude muset nějakým způsobem dostat všechny weby, které jste ověřili, aby rozpoznaly, že váš hlavní klíč byl kompromitován. Jediným problémem je, protože nemáte žádné jiné prostředky k ověření na webu, například uživatelská jména nebo e-mailové adresy, jak bude stránka vědět, že se ve skutečnosti pokoušíte odvolat hlavní klíč?

Stejně jako cokoli, co pochází z Gibsonu, je toto schéma SRQL velmi chybné a oproti konvenčním nenabízí žádné výhody. metody.

Comme nts

• “ Pokud ‚ dodržujete osvědčené postupy pro heslo “ je obrovská výhrada a většina Netizens to nedělá ‚.Součástí slibu SQRL ‚ je snížit počet uživatelů ‚, kteří potřebují zůstat na vrcholu osvědčených postupů. Dále bude specifikace SQRL vyžadovat, aby byl hlavní klíč uložen zašifrovaný pomocí hlavního hesla a nebude možné hrubou silou (vyladěno na ~ 60 s na jeden pokus). Získání hesla bude často netriviální, protože SQRL podporuje mimopásmové ověřování (tj. Keylogování hacknutého počítače vám ‚ vždy nepomůže). I když jsou důsledky úplného kompromisu vysoké, pravděpodobnost kompromisu je poněkud nízká.
• SQRL ještě může mít nedostatky, které je třeba řešit, ale tvrdí , že řeší řadu problémů nalezených ve stávajících přístupech k ověřování a jakákoli kritika SQRL, která ji prosazuje, “ nenabízí žádné výhody “ by měl obsahovat vyvrácení těchto nároků namísto očekávání slepého přijetí tvrzení.
• > Jako cokoli, co vychází z Gibsonu , toto schéma SRQL je velmi chybné a nenabízí žádné výhody oproti konvenčním metodám. — Zdá se, že to ‚ na zodpovězení otázky nepomůže, a já mám vlastně pocit, že máte s touto technologií problémy kvůli tomu, kdo ji vymyslel. Některé z bodů, které jste zmínili jako nedostatky, jsou skutečně řešeny “ spec „. Například samotný SQRL nezmiňuje ‚ t, jak je uložen hlavní klíč, ale Steve Gibson ‚ o tom říká, že mobilní Například klient by jej zašifroval pomocí hlavního hesla pomocí skriptu, jehož provedení trvá v průměru 60 s.
• Gibson explicita řeší ochranu hlavního klíče.
• Vydržte druhý. Ukradený hlavní klíč SQRL přirovnáte k jednomu z ukradených klíčů LastPass. Nebylo by ‚ lepší analogií přirovnat ji k ukradení celé vaší dešifrované databáze hesel LastPass ?

Celkově se zdá, že protokol nezvyšuje zabezpečení oproti stávající technologii. Pokud hledáte nejlepší způsob, jak chránit svou identitu online, je to bezpochyby ne . Ale pojďme projít výhody a nevýhody:

Výhody

Je nemožné “ sdílet heslo v úzkém smyslu, že škodlivý web nemůže použít přihlášení poskytnuté jednomu webu k přihlášení na jiný web.

Útok hrubou silou proti ověřovacímu tokenu je neproveditelné.

Pověření nejsou ve vašem počítači uložena. Chrání vás to před malou podmnožinou Útoky zaměřené na pracovní stanici. Konkrétně jste chráněni před útoky, které vám z počítače odcizí heslo. Nejste chráněni proti jakémukoli útoku na únos relace nebo útoku na prohlížeč a nyní jste také náchylní k útokům souvisejícím s telefonem. O tom později.

Nevýhody

Tato technika je nebezpečně náchylná k útokům MITM a sociálnímu inženýrství. Pravděpodobně více než jakékoli jiné používané ověřovací schéma, včetně hesel. Krok ověřování a krok zahájení přihlášení jsou neodmyslitelně odpojeny v tom smyslu, že se telefon správně autentizuje proti jakémukoli prezentovanému QR kódu, bez ohledu na to, jak a kde se uživateli zobrazí.

Takže například phishingový web může zobrazit autentický přihlašovací QR kód, který se místo uživatele přihlásí k útočníkovi. Gibson je přesvědčen, že uživatelé uvidí název banky, obchodu nebo webu v aplikaci pro telefon během ověřování, a proto budou dostatečně ostražití, aby zmařili útoky. Historie naznačuje, že je to nepravděpodobné, a tím rozumnějším očekáváním je, že zobrazení správného názvu v aplikaci uživatele falešně uklidní, aby si myslel, že je web legitimní, protože byl schopen spustit známý požadavek na přihlášení v telefonu. Opatření, která již byla v hlavě uživatelů narazena na bezpečnost hesel, se nemusí nutně promítnout do nových technik ověřování, jako je tato, díky čemuž je tato aplikace pravděpodobně méně odolná vůči sociálnímu inženýrství.

Tato technika kombinuje autentizaci i identitu do fyzického objektu, který je často ztracen nebo odcizen. V tomto smyslu to “ spíše jako pas než heslo. Každý, kdo má váš telefon, má najednou výlučně vaši identitu: útočník vás může nejen vydávat, ale bez druhé kopie na druhém telefonu ( nepravděpodobné), nyní jste ztratili schopnost identifikovat se.Ověřovací klíče nelze odvolat, takže bez mimopásmového obnovení z každého webu nemůžete obnovit svou identitu. A i když existuje mimopásmové zotavení, při konfrontaci se dvěma uživateli, jedním s vlastnictvím identity a druhým bez, může být obtížné pochopit, proč by vám měl provozovatel webu důvěřovat.

Tato technika kombinuje všechny vaše ověřovací tokeny do jednoho klíče , pokud ručně nevytvoříte další. Díky tomu je váš jeden klíč mimořádně šťavnatým cílem pro útočníky. Klíč je navíc uložen ve vašem telefonu, což zařízení obvykle měla směšně porézní vnitřní zabezpečení. Kombinace neobvykle šťavnatých cílů s nestandardním zabezpečením vás nezajistí.

Alternativy

Nejproblematičtějším aspektem tohoto schématu je to, jak špatně se porovnává s dostupnými alternativami.

Nejbezpečnější univerzálně přijímanou možností je dnes lastpass, keepass a další podobné systémy hesel integrované v prohlížeči. Zejména šifrování na straně klienta zmírňuje potřebu důvěřovat jakékoli třetí straně. A co je důležitější, díky integraci prohlížeče je phishing prakticky nemožný . LastPass nebo KeePass vyplní heslo pouze v případě, že je poskytováno ze správné domény, což znamená, že pokud bude uživateli poskytnut škodlivý web, nebude mít přístup k jeho heslu.

Dále LastPass nedávno přidal funkci který nutí uživatele měnit hesla, která nejsou globálně jedinečná. To pomáhá zabránit opětovnému použití hesla, což znamená, že hlavní výhodu Gibsonovy techniky lze snadno získat pomocí tohoto nástroje dnes na existujících webech, bez další nejistoty, kterou jeho schéma naznačuje.

Existující schémata ověřování druhého faktoru, která používají telefony nebo podobná zařízení, pomáhají chránit přihlašovací údaje uživatelů již dnes, a to takovým způsobem, který vás v případě odcizení zařízení okamžitě nezraní krádeží identity. bezpečnost dvoufaktorového ověřování spočívá ve skutečnosti, že zařízení ani heslo nelze použít, pokud je ukradeno bez druhého. Gibsonova technika je do značné míry odolná proti zahrnutí do dvoufaktorového schématu, což činí tuto úroveň ochrany není k dispozici.

TL; DR:

Technika ověřování společnosti Gibson nevytváří dostatečné výhody k překonání dodatečných nákladů na zabezpečení, které také ukládá. Tyto náklady jsou zásadní součástí samotného schématu a je pravděpodobné, že nebudou zpracovány bez sešrotování celého designu.

Dalo by se namítnout, že je to lepší než nic, ale nemůžete tvrdit, že je to lepší než cokoli, co již máme.

Aktualizace společnosti Gibson

Společnost Gibson nedávno oznámila další ochranu proti phishingu, protože to byla hlavní kritika. Jejich ochrana je tato: Pokud NEPOUŽÍVÁTE QR kódy, mobilní telefon atd. A místo toho máte v systému ověřovacího agenta (například v prohlížeči), pak server může zkontrolovat, zda ověřování odpověď pochází ze stejné IP adresy jako požadavek na ověření. To je dobré a dobře, ale celý účel tohoto protokolu je přesunout vaši identitu na váš mobilní telefon. Pokud je jediným bezpečným způsobem použití protokolu nepoužívat jeho jádro funkce, pak bychom možná měli znovu promyslet, čeho se snažíme dosáhnout.

Teoreticky byste mohli nadále používat svůj mobilní telefon, pokud (a pouze pokud) váš mobilní telefon věděl že používal stejnou IP jako váš počítač. Což samozřejmě nemůže vědět, protože nezná IP adresu vašeho počítače.

Lepší řešení

Jak již bylo uvedeno výše, pokud je míra ověřování ve vašem prohlížeči, , bude celý problém phishingu okamžitě vyřešen bez vynaložení úsilí nebo ověření ze strany uživatele. I ten nejméně schopný uživatel nemůže být podveden k ověření na nesprávném webu, protože ověřovací token webu je spojen s názvem domény a prohlížeč vyhrál. “ t povolit ověřování na nesprávnou doménu. Jedná se o techniku, která se dnes již používá, je zcela automatická a nevyžaduje spolupráci webu ani inteligenci ze strany uživatele.

Tuto metodu lze posílit vyžadováním druhého ověřovacího faktoru (například časově proměnný klíč na mobilním telefonu), který je opět k dispozici a používá se dnes, a který vás (zejména) chrání před pokazením ze strany cílového webu nebo společnosti.

Co se týká obav z toho, že autentizace na straně prohlížeče bude zranitelná vůči útokům na klientské pracovní stanice: i když je to pravda, platí také to, že je-li váš prohlížeč napaden, ne použití tohoto prohlížeče je bezpečné , bez ohledu na to, jaký mechanismus autentizace používáte.Autoři malwaru mohou (a již tak učiní) počkat, až se sami ověříte pomocí své superbezpečné techniky, a poté tiše odeslat potřebný provoz “ vlastní “ váš účet, aniž byste viděli něco špatného. Ani SQRL, ani žádný jiný ověřovací systém nemůže ochránit uživatele kompromitovaného prohlížeče, více než zámky dveří vás ochrání před požárem domu. Nákup ohnivzdorných zámků není řešením.

Kam dál

Pokud hledáte absolutní záruku ochrany před předstíráním jiné identity , podívejte se na token Fido U2F. Tento standard svítí tam, kde SQRL nedosahuje, a poskytuje vám zaručenou imunitu vůči útokům MITM (např. phishingu). Provádí to ověřením nejen uživatele, ale také kanálu, takže vy „je zaručeno, že (a) váš účet nebude možné ověřit bez tokenu, a také (b) váš token lze použít pouze k ověření připojení k počítači, ke kterému je připojen. Další informace najdete v této odpovědi .

Komentáře

• O prvním bodě : pokud dobře rozumím, přemýšlelo se o tom a jednou z možností je nechat web, na kterém se ověřujete, zodpovědný za přesměrování. Po přihlášení jste tedy přesměrováni na stránku skutečné banky ‚, nikoli na útočníka. O druhém bodě se dnes to samé děje s uživateli nástrojů, jako je LastPass. Pokud nenastavíte nějaký ochranný mechanismus (například PIN), budou všechna vaše hesla také odcizena. Proč ‚ to samé nemůže platit pro SQRL? Také, pokud vím ze specifikace, může uživatel zálohovat svoji identitu i na papíře (jako QR kód).
• A o třetím bodě: totéž se děje s většinou uživatelů, kteří si ‚ nepoužíváte správce hesel jednoduchým použitím jediného uživatelského jména / hesla na několika webech. Nebo s uživateli správců hesel, jejichž “ identita “ je rozšířena na několik webových stránek, ale uložena na jednom místě (LastPass ‚ servery, databáze 1Password atd.). Takže to ‚ ve skutečnosti není chybou SQRL. Celkově vzato, čím víc jsem četl o SQRL, tím více vidím jeho výhody ve srovnání se současnými alternativami. Řekněme, že říkáte o Stevovi Gibsonovi, ale SQRL mi připadá jako dobrá alternativa.
• “ Opatrnost, která už byla v hlavách uživatelé týkající se zabezpečení heslem nemusí nutně znamenat nové techniky ověřování, jako je tato. . . “ Jedná se o vynikající bod a marketing již byl prohrán. QR kódy jsou považovány za snadný způsob, jak dělat věci, nikoli za potenciální vektor útoku. Alespoň páry párů uživatelské jméno / heslo byly PRVNÍ použity jako mechanismus ověřování, nikoli jako marketingový nástroj.
• @jpkrohling: Pokud jde o správce hesel, domnívám se, že většina uživatelů takového softwaru NEUCHOVÁVÁ své hlavní heslo na svém mobilním zařízení, právě proto, že si jsou vědomi toho, jak je to nebezpečné. Mám jednu fyzickou kopii svého hlavního hesla na bezpečném místě, ale žádné elektronické kopie. Útoky, které by umožňovaly přístup k mému hlavnímu heslu, se liší od útoků, které by mohly ohrozit heslo webu, a jsou mnohem méně pravděpodobné. (Především proto, že napadení mé databáze hesel by zahrnovalo napadení mě osobně, spíše než rozsáhlého napadeného webu.)
• @jpkrohling Ani LastPass, ani KeePass neukládají kdekoli hlavní heslo. ‚ se používá k odemknutí databáze hesel, ale není ‚ uložena. To se zásadně liší od jediného klíče, který se sám o sobě používá všude.

SQRL určitě není bez chyb, ale je jistě lepší než většina primárních řešení autentizace, která se dnes na webu běžně používají, pokud jde o bezpečnost a (a to je důležité) použitelnost. Dovolte mi to vysvětlit.

Mylné představy

Nejprve mi dovolte vyjasnit několik mylných představ obsažených v některých dalších odpovědích na tuto otázku. Mnohé z těchto odpovědí jsou zastaralé a byly napsány před změnami dokumentace SQRL které řeší problémy, které jsou v nich prezentovány, zatímco jiné zřejmě kladou nepřiměřený důraz na nedostatky v SQRL, které jsou přítomny také v mnoha jiných široce používaných stávajících ověřovacích řešeních, přičemž ignorují jeho výhody. Pojďme si zde vyjasnit několik mylných představ my?

Mýtus: SQRL vyžaduje aby fungovalo skenování QR kódů

To prostě není pravda. QR kódy jsou výhodou což usnadňuje používání SQRL na počítačích, na kterých uživatel nenastavil klientský software SQRL. Web SQRL uvádí následující:

Tři způsoby, jak jít …smartphone volitelné:

Ačkoli původní inspirací pro vývoj tohoto systému bylo smartphone skenující QR kód na přihlašovací stránce webu, malý doplněk k tomuto modelu umožňuje dva významnější režimy provozu: Jednoduše udělejte obrázek QR kódu také klikatelným odkazem na stejnou URL, která je zakódována do QR kódu. To poskytuje tři způsoby přihlášení:

• Naskenujte kód pomocí smartphonu: Pomocí výše popsaný model, smartphone uživatele naskenuje QR kód zobrazený na přihlašovací stránce webu a uživatel je na tomto webu přihlášen.
• TAP KÓD na smartphonu: Chcete-li se přihlásit na web ve smartphonu, je-li vizuální kód SQRL také odkazem ve stylu URL (pomocí schématu sqrl: //), Aplikace SQRL nainstalovaná ve smartphonu obdrží tento odkaz a bezpečně přihlásí uživatele na web v telefonu.
• Klikněte na kód na obrazovce počítače nebo notebooku : Chcete-li použít systém SQRL na jakémkoli stolním nebo přenosném systému, nainstaluje se aplikace SQRL pro stolní počítače, která se sama zaregistruje a bude přijímat odkazy sqrl: //. (To je podobné způsobu, jakým se e-mailový program registruje pro příjem mailto: odkazů.) To umožňuje, aby uživatelé stejného řešení používali na ploše, kterou používají ve svých smartphonech. Pokud kterýkoli web nabízí kód SQRL, uživatel klikne na kód kurzorem myši a místní nainstalovaná aplikace SQRL se automaticky otevře, zobrazí výzvu k zadání hesla SQRL, potvrdí doménu a poté se přihlásí.

Mýtus: Hlavní klíč SQRL je uložen ve vašem telefonu zcela nezašifrovaný a nechráněný

Nejsem si jistý, proč to někteří lidé udělali Předpoklad, jak mi připadá zřejmé, že by tomu tak nebylo. Hlavní klíč SQRL je chráněn stejným způsobem, jakým chráníte databázi hesel: silným hlavním heslem. Krádež telefonu uživatele by vám automaticky neposkytla přístup k jeho online identitě, pokud byste neměli také jeho hlavní heslo. Další podrobnosti o správě klíčů jsou vysvětleny na stránce SQRL Client- Správa bočních klíčů na webu SQRL.

Mýtus: Pokud vám bude hlavní klíč odcizen, nemůžete změnit své přihlašovací údaje

To je také nepravdivé. SQRL poskytuje vestavěný způsob, který umožňuje skutečnému držiteli účtu aktualizovat přihlašovací údaje v případě zneužití klíče. Tato funkce se nazývá zámek identity:

„Identity Lock“ brání změně identity & umožňuje obnovu: Toto je také natolik významné, že si zaslouží vlastní stránku s podrobným popisem: „ Protokol zámku identity “ (strana 4 v bloku odkazů v dolní části této stránky.) Jednou identita uživatele byla stanovena pomocí webového serveru, SQRL c lient není schopen tuto identitu změnit. To znamená, že pokud došlo k nejhoršímu a bylo použito velmi slabé a snadno uhodlné heslo, nebo byl hacknut telefon nebo počítač uživatele, aby získal svůj hlavní klíč a heslo identity, žádná škodlivá třetí strana nemůže změnit online identitu uživatele a zablokovat jej z jeho vlastních online účtů. A navíc po načtení normálně offline „klíče pro odemknutí identity“ může skutečný vlastník své identity odejít do důchodu a nahradit svou ztracenou nebo odcizenou online identitu, aby ji v podstatě vzal zpět od jakéhokoli útočníka, čímž se jejich předchozí identita stává nepoužitelnou.

pravděpodobné: SQRL je více náchylný k phishingu než stávající ověřovací řešení

Dobře, takže je to ve skutečnosti částečně pravda. Pokud používáte SQRL skenováním QR kódu, existuje opravdu velmi malá ochrana proti phishingu. Pokud si uživatel nedává pozor, aby zajistil, že web zobrazený v řádku URL jeho prohlížeče bude stejný jako ten, který se zobrazuje v aplikaci SQRL Client, mohl by autorizovat relaci přihlášení pro útočníka. To je stále lepší než hesla, kde „dávají phisheru trvalý přístup ke svému účtu (a všem dalším účtům, které mají jinde, které sdílejí stejné heslo), dokud nezmění své heslo, ale ne tak dobře jako jiná řešení, která se integrují do prohlížeče uživatele, jako jsou klíče U2F , WebAuthn, klientské certifikáty a (za určitých podmínek) správci hesel.

Když však používáte klienta SQRL na stejném zařízení, ke kterému se přihlašujete, SQRL má určitou ochranu proti phishing na místě. Tyto ochrany jsou vysvětleny na webu SQRL v části Jak může SQRL zmařit phishingové útoky .Existuje také možnost integrace SQRL do prohlížečů (možná prostřednictvím pluginů), které poskytují mnohem silnější ochranu proti phishingovým útokům; srovnatelná s řešeními jako WebAuthn a klientské certifikáty.

Celkově bych SQRL zařadil na přibližně na stejné úrovni jako správci hesel pro ochranu proti phishingu. Má potenciál poskytnout silnou ochranu proti phishingu, pokud je nainstalován na stejném zařízení, ke kterému se uživatel přihlašuje, ale poskytuje minimální ochranu, pokud je nainstalován na jiném zařízení.

Porovnání s alternativami

Pojďme nyní porovnat SQRL se stávajícími široce používanými řešeními ověřování.

Hesla

SQRL je v mnoha ohledech mnohem lepší než hesla. Nejenže je pohodlnější použít jednou nastavené nahoru, protože uživatelé si nemusí dělat starosti s pamětí nebo přepisováním více různých hesel pro každý web, ale také chrání před opětovným použitím hesla, slabými hesly, keyloggováním a do určité míry phishingem.

Nevýhody SQRL ve srovnání s hesly spočívá v tom, že je pro provozovatele webových stránek obtížnější implementovat, ne tak široce používané, vyžaduje více času na počáteční nastavení, vyžaduje určité úsilí při přenosu na nové zařízení a poskytuje jediný bod selhání pro všechny uživatelské účty, pokud dojde ke krádeži hlavního klíče (i když tento poslední pokus) To platí také pro hesla, pokud uživatel používá stejné heslo na každém webu).

Správci hesel

SQRL je v mnoha ohledech velmi podobný správcům hesel. Oba poskytují jedinou centralizovanou kotvu důvěryhodnosti, která slouží jako druh ověřovacího proxy mezi uživateli a jednotlivými službami. Existuje několik způsobů, jak je SQRL lepší než správci hesel.

Hlavní výhodou, kterou si myslím, že má SQRL oproti správcům hesel, je to, že jeho použití na nedůvěryhodných nebo jen částečně důvěryhodných počítačích je snazší a bezpečnější. Řekněme například, že se uživatel chce přihlásit na web pomocí počítače ve veřejné knihovně. Se správcem hesel by musel buď získat přístup k heslu pro tento web ve svém telefonu a přepsat jej do počítače ručně, nebo stáhnout jeho správce hesel a databáze hesel do počítače knihovny, odemkněte databázi pomocí svého hlavního hesla a poté se přihlaste. První scénář je pro uživatele nepohodlný a vystavuje prosté heslo uživatele pro tento web nedůvěryhodnému počítači (a jakýkoli malware na nedůvěryhodném počítači, včetně keyloggerů). Druhý scénář je ještě horší, protože je to jednak nepohodlné, jednak vystavuje nedůvěryhodnému počítači celou dešifrovanou databázi hesel a hlavní heslo uživatele. U SQRL by uživatel musel pouze naskenovat QR kód na obrazovce nedůvěryhodného počítače, což je pro uživatele mnohem pohodlnější, a vystavuje nedůvěryhodnému počítači pouze jednu relaci přihlášení (bez opakovaně použitelných pověření, jako je heslo). .

Další výhodou, kterou má SQRL oproti správcům hesel, je to, že je nejjednodušší zotavit se z nejhoršího scénáře: odcizení databáze hesel uživatele / hlavního klíče. Se správcem hesel nebudete stačí změnit heslo na každém webu, musíte se také starat o to, aby útočník změnil vaše hesla (případně vás uzamkl z vašeho účtu). Útočník má také tu výhodu, že vlastní seznam všech stránek, které máte účet, což výrazně usnadňuje využívání krádeže databáze hesel. Díky SQRL je odcizení vašeho hlavního klíče stále hrozná situace, ale útočník nemá žádný seznam webů, na kterých máte účet (místo toho musíte hádat ), a nemůže změnit vaše heslo, aby vás zablokovalo vašeho účtu. Jakmile načtete klíč pro odemknutí identity, je také o něco pohodlnější změnit své přihlašovací údaje na každém webu, protože klient SQRL má možnost to za vás automaticky udělat pro každý web, který navštívíte po přihlášení. (Není třeba jít prostřednictvím jakýchkoli formulářů „změnit heslo“.)

Nakonec si myslím, že SQRL má oproti správcům hesel jednu malou, ale důležitou výhodu, pokud jde o cíl zcela nahradit hesla, a to, že weby mají možnost vynutit si používání SQRL nad tradičními hesly. Dokud budou mít uživatelé stále možnost špatného zabezpečení, opětovné použití stejného hesla na každém webu, to se stále stane. Pokud SQRL začne získávat široké přijetí, weby mohou ve skutečnosti začít s ukončováním používání hesel. To nelze „udělat u správců hesel, protože se spoléhají na používání hesel, aby fungovali.

Pokud jde o nevýhody, vlastně mě nenapadne situace, kdy by SQRL by nutně bylo horší než správce hesel, pokud jde o bezpečnostní. Hlavní nevýhodou SQRL je, že vyžaduje podporu od provozovatelů webových stránek, zatímco správci hesel nevyžadují žádnou speciální podporu ze stávajících služeb. To znamená, že nyní můžete začít používat správce hesel, ale SQRL bude muset počkat, než jej stránky implementují, než bude možné jej použít. To je významná překážka přijetí.

Certifikáty klienta

Primární výhodou, kterou má SQRL oproti klientským certifikátům, je jedna z výhod. Klientské certifikáty jsou v současné době komplikovaně nastavitelné, obtížně přenositelné mezi počítači a mají problémy s ochranou osobních údajů, když se stejný certifikát používá na různých webech. I když teoreticky bychom mohli vytvořit systém využívající klientské certifikáty, který by tyto problémy vyřešil, vyskytl by se také problém špatné integrace s uživatelskými rozhraními webových stránek a webovými servery, což je obtížnější vyřešit. Tady nebudu zacházet příliš podrobně, protože již existuje vynikající článek o problémech použitelnosti klientských certifikátů na browserauth.net.

Z hlediska bezpečnosti mají klientské certifikáty tu nevýhodu, že vyžadují zapojení CA. To je (potenciálně) drahé a vyžaduje důvěru v certifikační autoritu třetí strany. Kromě toho, pokud se rozhodnete ignorovat CA a místo toho své certifikáty podepíšete sami, máte problém se zrušením certifikátu. Klientské certifikáty mají také stejné problémy se zabezpečením a pohodlím jako správci hesel, když se uživatelé chtějí přihlásit na nedůvěryhodném počítači; musí svůj certifikát přenést na nedůvěryhodný počítač, což je nepohodlné a potenciálně vystavuje svou hlavní identitu malwaru na tomto počítači.

Stručně řečeno, dokud někdo nepřijde s lepším a uživatelsky přívětivým řešením pomocí klientské certifikáty, které řeší (alespoň většinu) těchto problémů, nevěřím, že klientské certifikáty jsou vážným konkurentem SQRL (nebo v tomto ohledu hesel).

Dvoufaktorové ověřování

Jen jsem si řekl: „SQRL a dvoufaktorové ověřování se nevylučují . SQRL je náhradou za první faktor ve 2FA: hesla. U SQRL lze stále používat další doplňková opatření, jako jsou OTP kódy nebo klíče FIDO U2F.

WebAuthn

Nyní zde „s , kde jsou věci zajímavé. WebAuthn je nový (dobře, novější než SQRL) standard W3C navržený tak, aby poskytoval standardní API, které mohou weby používat k ověřování uživatelů pomocí veřejných klíčů na webu. Stejně jako SQRL, podporuje používání telefonu uživatele k ověření relace přihlášení na externím zařízení , kromě několika dalších metod ověřování (například bezpečnostní klíče 2. faktoru) .

Toto je místo, kde se SQRL konečně setká se svou shodou, alespoň z hlediska bezpečnosti. WebAuthn poskytuje nejen stejnou ochranu proti opětovnému použití hesla, slabá hesla a keyloggování jako SQRL, ale poskytuje ještě silnější ochranu proti phishingu integrací s prohlížečem uživatele rovnoměrně při autorizaci přihlášení relace pro PC uživatel dříve nenastavil klientský software ověřovatele na. To je možné, protože v této situaci WebAuthn komunikuje s prohlížečem uživatele přímo pomocí obousměrných komunikačních protokolů, jako je Blutooth nebo NFC, místo toho komunikuje s webem, který uživatel používá, pomocí jednosměrného QR kódu.

Z hlediska použitelnosti jsou věci trochu komplikovanější. Alespoň na první pohled opět vyhrává WebAuthn. Protože se jedná o standard W3C, který již má implementace ve více prohlížečích , teoreticky mohou uživatelé okamžitě začít používat WebAuthn, aniž by museli instalovat jakýkoli software třetí strany. V praxi se však většina stávajících implementací WebAuthn zaměřuje na jeho použití jako formu autentizace druhým faktorem nebo jako způsob opětovného ověření uživatele kteří se dříve přihlásili na stejném zařízení pomocí jiné metody přihlášení (obvykle hesla). Jako primární ověřovací faktor WebAuthn stále spíše chybí životaschopné implementace.

Mezi další drobné úvahy patří skutečnost, že SQRL má budova metoda t-in pro otáčení klíčů účtů v případě odcizení hlavního klíče, zatímco WebAuthn spoléhá na webové stránky, aby implementovaly svůj vlastní systém pro odvolání klíčů, a skutečnost, že WebAuthn vyžaduje určitý volitelný hardware (jako Bluetooth nebo NFC), aby k ověření na vzdáleném počítači, zatímco SQRL může pracovat na jakémkoli počítači s fungujícím displejem.

Celkově si myslím, že je velmi pravděpodobné, že WebAuthn nakonec SQRL zastará. SQRL může prozatím trochu dýchat, ale WebAuthn má mnohem silnější podporu od prodejců prohlížečů, provozovatelů webů a dalších organizací třetích stran (například W3C). Jakmile WebAuthn získá několik implementací umožňujících jeho použití jako primárního autentizačního faktoru, očekávám, že web převezme velmi rychle.

Upozornění

SQRL je stále v aktivním vývoji, takže materiál uvedený v této odpovědi se může změnit. Jak bude vývoj pokračovat, očekávám, že budou vyřešeny některé chyby zabezpečení a nejistoty v této odpovědi. Většina diskusí aktuálně probíhá v diskusní skupině SQRL na grc.com.

SQRL je pohodlné řešení problému uživatelského jména / heslo paradox. (tj. kompromis pohodlí / zabezpečení) bez použití . Poskytuje jednoduchou alternativu k nejpopulárnějšímu modelu ověřování (uživatelské jméno & heslo) bez prakticky bezpečnostního kompromisu. Je prakticky stejně bezpečný jako kterýkoli z běžných modelů ověřování, které se dnes používají, , pokud jste stále při vědomí . Pokud používáte SQRL, neznamená to, že nemůžete dodržovat nejlepší bezpečnostní postupy, jako je kombinace s vícefaktorovým ověřováním pro důležité účty.

Je důležité si nenechat ujít smysl SQRL. Samotný SQRL nemusí zajišťovat lepší nebo horší zabezpečení. Pokud dojde k ohrožení samotného počítače / telefonu nebo k oklamání uživatele phishing, pak se jedná o útok bočním kanálem namísto přímé chyby samotného SQRL. Každá konvenční metoda ověřování má tento problém útoků postranním kanálem Nerozbitná jednorázová podložka je také zranitelná vůči útokům postranním kanálem jako je kompromitace samotné podložky nebo špatné okolní zabezpečení nebo implementace.

Pokud jste poslouchali původní návrh nápadu na stránce Steva Gibsona podcast , následovaný Q & A, byly zodpovězeny mnohé obavy vznesené v tomto vlákně zásobníku. Steve také sám řekl, že tento velmi „jednoduchý“ a „důmyslný“ (jeho slova) nápad bude muset „prověřit“ a „uhodit“ bezpečnostními experty, protože pouze čas ukáže, zda se jedná o bezpečné řešení.

Závěrem lze říci, že většina argumentů proti SQRL spadá mimo doménu samotného SQRL a místo toho jde o problémy se špatným zabezpečením lidí. SQRL nezavádí novou klasifikaci problémů, které již naše tradiční metody ověřování nemají.

SQRL je vynikající, pokud je vhodně používán lidmi, kteří si uvědomují bezpečnost. Musíte pochopit, že vždy existuje kompromis mezi pohodlím a bezpečností a toto řešení je pravděpodobně nejlepší vyvážení ze dvou, které jsem viděl.

Komentáře

• Díky Ansichart. Mohou však ‚ t existující autorizační řešení jednoduše zachovat stejné nebo lepší bezpečnostní funkce jako SQRL a poté použít automatizaci ke zvýšení jejich uživatelského pohodlí? Jaká základní vlastnost uživatelského pohodlí SQRL ‚ není kvůli automatizaci? Ptám se, protože pokud má uživatel dvě černé skříňky, které dělají totéž; jeden označený “ dospělý “ a druhý označený “ SQRL “ a mohou být oba navrženy / automatizovány, mají stejné rozhraní / tlačítka na vnější straně krabice – jakou přidanou hodnotu poskytuje SQRL?
• Řeší problém paradoxu hesla aniž byste museli používat třetí stranu.
• Rozumím. Pokud tedy někdo ‚ nechce riziko 3. strany přihlašování a nebude ‚ generovat / ukládat svá hesla pomocí správce hesel, může SQRL posílit. Pokud je však SQRL mobilní blackbox, který požaduje heslo k odemčení hlavního klíče použitého k regeneraci / uložení SQRLID a následnému propojení back-channel klienta ‚ s cookie / QR session_id se serverem ‚ s zaznamenaným SQRLID pro přihlášení – jak je to jiná černá blackbox od mobilního správce hesel s automatickým přihlášením přes stejný zadní kanál; nebo zásuvný modul pro mobilní klienty s oběma stranami s automatickým generováním & přihlášení přes stejný zadní kanál?
• Provedl jsem několik zásadních úprav svého původního příspěvku po několika druhých úvahách a bližším přečtení toho, co říkají ostatní, protože jsem to možná přehnal. Předpokládám, že mít mobilní telefon jako centrální klíč posune problém a bylo by důležitější mít silnější zabezpečení telefonu. Steve Gibson to přináší také v podcastu Q & A.

SQRL neposkytuje žádná průlomová vylepšení. QR kódy jsou formát optického čárového kódu užitečný pro distribuci krátkého obsahu – nic víc.

Jakákoli situace „automatického přihlášení“, kterou se SQRL snaží vyřešit, může místo toho jednoduše použít klientský certifikát uložený v mobilu.

Hypoteticky by čárový kód QR na stránce HTTPS mohl vrátit serverem podepsanou nebo šifrovanou verzi klientského certifikátu (nebo podobného pověření), jakou dříve server označoval, ale proč? Pro vypršení platnosti pověření? Web mohl jednoduše přímo odmítnout prošlé pověření.

Takže největší bezpečnostní problém s tím mám protokol je: Znovuobjevení čtvercového kola .

Update

Při čtení nových odpovědí a komentářů bych chtěl poukázat na to, jak snadné je udělat něco podobného jako SQRL prostřednictvím jednoduchá automatizace vyspělé stávající technologie :

1. Web vyžaduje jakékoli CAPTCHA nebo podobné ověření „Já jsem člověk“. Jakmile uživatel vyhoví (POSTed), vrátí web HTTP 403.7 - Client Certificate Required nebo chybu vanilky 403.
2. Vlastní stránky 403 jsou dostatečně snadno nastavitelné a mohou být docela hezké a uživatelsky přívětivé. Mohl by dokonce bootstrapovat níže požadované funkce podobným způsobem, jako výzvy „Adobe Reader required“ na mnoha webech.
3. Stránka 403 Custom obsahuje některé značky, na které vlastní plugin prohlížeče reaguje. Nazveme tento vlastní plugin „S403L kompatibilní“ v duchu „SQRL compliance“.
4. Plugin S403L generuje standardní certifikát klienta, který je zabezpečen v obvyklé šifrované mezipaměti certifikátů prohlížeče (nebo třetí mezipaměť strany, pokud je šifrování úložiště klíčů vašeho prohlížeče naštvané). Plugin vytvoří standardní CSR pro cert klienta a odešle CSR na adresu URL uvedenou v označení 403 (např. <s403l ref="https://www.example.com/S403L" />)
5. Server vyhovující standardu S403L používá k vytvoření kontinuity s krokem 1 uživatelský identifikátor session_id (získaný ze souborů cookie nebo řetězce dotazu) a poté vrátí zprávu CSR podepsanou serverem. Obecné ověření serveru přijme jakýkoli certifikát klienta, který byl podepsán serverem (a splnil tak registrační kritéria požadovaná v kroku 1).
6. Plugin S403L ukládá tento podepsaný certifikát klienta do mezipaměti prohlížeče. poté může standardní prohlížeč bez pomoci pluginu „automaticky se přihlásit“ na server standardním způsobem SSL / TLS, dokud platnost certifikátu nevyprší.

„Mobilní“ a „vizuální“ povaha of SQRL is a misdirection as it doesn „t provide detached two-factor authentication and you now need two computers to navigate the internet instead of one. Pokud však nezaměřujete webovou kameru USB na svém počítači na vlastní monitor.

Kompromisy mezi hesly a certifikáty jsou v komunitě zabezpečení dobře definovány: Hesla se vejdou do lidského mozku; certifikáty se nevejdou lidský mozek ( obvykle ), ale může mít šílenou entropii a dobré funkce správy PKI (platnost končí , odvolání, rozšíření zásad atd.) SQRL čistě nezapadá do žádného tábora; a pokud se ubírá směrem k méně lidskému více počítačovému táboru, jak se zdá – má roky vývoje a bezpečnostní analýzy, aby zopakoval stávající funkce X.509.

Komentáře

• > mohl místo toho jednoduše použít klientský certifikát uložený v mobilu.— až na to, že tato technologie existuje celá léta na mobilních i stolních počítačích a není ‚ tak rozšířená, jak by si člověk přál. Na rozdíl od klientského certifikátu SQRL nevyžaduje ‚ t, abyste k vytvoření “ SQRL identity „. Pokud si přejete, můžete si vytvořit tolik identit, kolik chcete. To znamená, že oproti klientským certifikátům je výhodou, že máte anonymitu ze strany autorizačního protokolu ‚.
• @jpkrohling Je běžnou mylnou představou, že klientské certifikáty požadovat použití identifikace. To je požadavek komerčních podpisových orgánů, aby používaly své globálně zaměnitelné řetězce důvěry. V praxi může být certifikát klienta jednoduše anonymní CSR vytvořený klientem a podepsaný konkrétním serverem, po splnění jakýchkoli požadovaných kritérií (CAPTCHA, předchozí účet, atd). Certifikáty mohou mít také integrované vypršení platnosti. Type 40-L QR čárové kódy mohly na přání odeslat / uložit certifikát klienta 1 kB X.509.
• Dobře, moje chyba. Z tohoto pohledu by klient (například mobilní aplikace) mohl generovat klientský certifikát pro každý web, který uživatel registruje. To zní dražší než hašování některých informací, ale mohlo by to být zajímavé řešení. V každém případě stále ‚ nesouhlasím s tvrzeními, že SQRL je horší než zbytečné.
• Možná jsem byl k tomuto znění tvrdý a odstraním ho. Ale nevidím ‚ SQRL jako nic jiného než více sexy způsob distribuce vyjednaných pověření klienta; a ten, který ‚ t nevyřešil některé jemné problémy řešené vyspělými schématy ověřování. Správce hesel je zdlouhavý (netrápím se ‚ integrací prohlížeče, protože jsem ‚ ma paranoik), ale vím, že jen já a jeden sdílet jedno jednorázové heslo v mém šifrovaném úložišti klíčů. Nemusím si ‚ dělat starosti s novými fantastickými schématy hash / auth, jen s kvalitou PRNG / TRNG, kterou můj správce hesel používá ke generování hesel.
• @LateralFractal, koho zajímá, jestli je to ‚ nové nebo ne? SQRL umožňuje uživatelsky přívětivé ověřování, kdy první strana nevystaví své tajemství druhé straně nebo jakékoli třetí straně, která by mohla ohrozit zabezpečení druhé strany ‚. ‚ Jde o pokus vyřešit problém reálného světa, který dosud nikdo jiný nedokázal vyřešit.

Chtěl bych se věnovat první otázce: „jedním z problémů, na které si myslím, je napadení čtečky QR, zobrazit www.google.com místo www.nsa-super-secret-place.gov/123 „:

Hlavní klíč se používá jako zárodek do HMAC společně s adresou webu (FQDN). Ačkoli kód QR může kódovat úplně jinou adresu URL, protokol NEODHADÍ ověřovací kód, který by se normálně odeslal na adresu www.google.com (v příkladu).

Zadruhé, mnoho přispěvatelů zapomíná na klíčové cíle při vypracování tohoto nápadu:

1. anonymita tím, že nepoužívá třetí strany
2. snadné použití
3. na nedůvěryhodných počítačích není třeba zadávat tajné údaje.

Domnívám se, že protokoly je řeší v plném rozsahu!

Ve skutečnosti však existují kompromisy pocházejí z prvního cíle. Pokud do ověřování není zapojena žádná třetí strana, jak lze odvolat jejich údaje o ověření? Zabezpečení hlavního klíče je navíc zjevným problémem. Předpokládám, že to bude dobře chráněno budoucími mobilními zařízeními v čipu podobném HSM. Do té doby je klíčem pouze mobilní zařízení se pinem souborů chráněné heslem, i když PBDKF2 zajišťuje, že je velmi pomalé ho skutečně hrubě vynutit.

Komentáře

• Co je nového v této myšlence ‚? Zdá se mi, že jde o primitivní variaci na nyní zaniklý Windows CardSpace.
• Ano, v CardSpace máte pravdu. Pak je tu U-Prove, který také vlastní Microsoft. Otázkou je, jak byste CardSpace nebo U-Prove použili na počítači, kterému nedůvěřujete (počítač v internetové kavárně nebo přátel). To Steve dodal.
• Aha, dobře, to ‚ mi chybělo. Stále souhlasím s @TerryChia, že se nejedná o spouštěč bez mechanismu odvolání pro uživatelské klíče.
• @Xander Tam je mechanismus odvolání pro uživatelské klíče. grc.com/sqrl/idlock.htm