Názory k článku
Google zapnul přihlašování k účtu bez hesla, passkeys mají chránit před úniky hesel a phishingem

Ne „může“, žádné servery tam nevystupují. Passkeys nad WebAuthn přidává tu možnost, že nepoužíváte hardwarový token, ale že jako token funguje externí zařízení v dosahu, třeba mobil. A o to se musí postarat prohlížeč a systém na mobilu, ty spolu přitom komunikují přes Bluetooth.

E-shop si pouze u uživatele místo hesla nebo otisku hesla uloží jeho veřejný klíč.
Takže k tomu na serveru stačí databáze veřejných klíčů plus nějaká ověřovací funkce a celé to může fungovat bez potřeby např. googlích serverů?

Kdyby vám tím obyčejným nešifrovaným e-mailem poslali kód pro obnovení hesla, bylo by to v něčem zásadně jiné? Jak jsem psal, když někomu sdělíte heslo, musíte počítat s tím, že s ním bude zacházet, jak on uzná za vhodné. Uloží ho do databáze v otevřeném tvaru, pošle vám ho nešifrovaným e-mailem, někde ho zveřejní…

Je dost možné, že ten e-mail byl šifrovaný alespoň při transportu – což by tak nějak odpovídalo zaslání PINu ke kartě dopisem, což je normální praxe.

Já vím, že se nad ukládáním hesel v otevřeném tvaru všichni pohoršují. … Ale mně to nevadí. Připadá mi pokrytecké někomu prozradit své heslo a pak se tvářit, že on ho musí zabezpečit. A ještě se pohoršovat nad tím, když mi ukáže, že to heslo opravdu zná.

Obávám se, že jste nepochopil podstatu mého příspěvku. Heslo uložené v plaintextu není (obecně) ideální, ale samo o sobě by mne to tak nepohoršovalo a v některých případech je to dokonce nutnost. Co mne pohoršuje, je nápad heslo (úplně zbytečně) posílat obyčejným nešifrovaným e-mailem - a navíc ani neumožnit se tomu nějak vyhnout. To je jako kdyby mi banka poslala PIN ke kartě koresponďákem (pokud taková věc ještě existuje).

Já vím, že se nad ukládáním hesel v otevřeném tvaru všichni pohoršují. (Teoreticky by ta hesla mohla být v databázi zašifrovaná a klíč by byl uložen mimo databázi, ale víme, že to tak v případě e-shopů nebylo.) Ale mně to nevadí. Připadá mi pokrytecké někomu prozradit své heslo a pak se tvářit, že on ho musí zabezpečit. A ještě se pohoršovat nad tím, když mi ukáže, že to heslo opravdu zná. „Tady vám posílám své heslo, a když budete předstírat, že ho nemáte uloženo v otevřené podobě, budu spokojen a budu se tvářit, že je to bezpečné.“

Prostě když svoje heslo někomu prozradím (protože prohlížeče mi dnes prakticky nedávají jinou možnost, resp. WebAuthn a Passkeys se teprve rozbíhá), musím počítat s tím, že to heslo zná. Tudíž to heslo nemůžu používat nikde jinde. A nijak mne neuráží, když mi ten server prozradí, že moje heslo opravdu zná – protože já s tím počítám.

Já už narazil na dva různé e-shopy, kde mi nejen heslo poslali v e-mailu potvrzujícím registraci, ale dokonce mi ho znovu poslali jako potvrzení pokaždé, když jsem si ho zkusil změnit. :-(

Za prvé, není to věc Google – je to založené na standardu WebAuthn, na kterém spolupracovala spousta firem, a na samotné PassKeys se podílí vedle Googlu také Microsoft, Apple a další. Za druhé, nejsou tam certifikáty, protože certifikát vám musí někdo vydat. Používají se tam jen klíče. Za třetí, „zpřívěťování“ práce s certifikáty v prohlížeči by narazilo na přísné limity – HTTPS používá TLS, které je záměrně nastaveno tak, že jakmile v TLS komunikaci k nějaké chybě, spojení se ukončuje a uvádí se jen velmi málo informací o tom, k jaké chybě došlo. Takže všechno by to končilo na tom, že jakákoli chyba při přihlašování klientským certifikátem by v prohlížeči znamenala jen nějaké obecné hlášení typu „něco se nepovedlo“.

Navíc s přihlašováním klientským certifikátem se v prohlížečích už moc nepočítá – např. Chrome při použití TLS 1.3 vyměňuje klíče velmi často, přičemž při přihlášení klientským certifikátem je potřeba jeho privátní klíč při výměně klíče spojení. Což má za následek, že musíte zadávat PIN k privátnímu klíči třeba každých pět až deset minut. A nikomu to evidentně nevadí.

(Ale používání klientských certifikátů má v prohlížečích příšerné UX i v těch částech, kde by mohlo být přívětivé, o tom žádná.)

Proč si vymýšlíte?

Fungování Passkeys je popsáno třeba v článku na Root.cz: Passkey: nový způsob přihlašování bez hesla bude pohodlný a zruší phishing. E-shop si pouze u uživatele místo hesla nebo otisku hesla uloží jeho veřejný klíč. Při přihlášení pak jen stránka vytvoří požadavek na přihlášení přes Passkey.

Na tom není nic divného, e-mail je dnes považován za bezpečný kanál. Kdybyste řešil reset zapomenutého hesla, přijde vám na e-mail kód, kterým heslo můžete změnit. Dnes se zkrátka počítá s tím, že když někdo získá přístup k vaší e-mailové schránce, získá tím prakticky celou vaši digitální identitu.

Pro většinu uživatelů bude tohle paradoxně nejbezpečnější reálně dosažitelný způsob přihlašování. Protože správce hesel nepoužívají, používají všude stejné heslo, nebo pár hesel. Takže kdyby tam nechali uživatele heslo vytvořit, použije to heslo, které používá i všude jinde.

Aby se heslo nemuselo posílat, musel by ho mít server uložené v databázi (v plaintextu nebo reverzibilně zašifrované, ne hash).
Ve skutečnosti stačí, když má server uložený hash. A je to dokonce popsané přímo v HTTP standardu jako HTTP Digest autentizace. Stačilo vedle přihlašování přidat i podporu pro zavedení hesla, aktualizovat použité algoritmy a implementovat v prohlížečích lepší UI.

Aby se heslo nemuselo posílat, musel by ho mít server uložené v databázi (v plaintextu nebo reverzibilně zašifrované, ne hash). Aby se dalo dokázat, že klient má plaintext k dispozici, musí ho v nějaké formě mít k dispozici i server. Buď má plaintext v databázi a pak stačí komunikovat nějaký jeho matematický derivát, nebo má v databázi jen hash a pak je nezbytně nutné přenášet plaintext hesla (pokud by se v této situaci měl přenášet hash, stal by se tak vlastně sám heslem).

Obávám se ale, že je pořád mnohem pravděpodobnější, že někomu uteče databáze, než že bude někdo dumpovat hesla za letu někde v kódu aplikace. Takže proto má varianta ukládání hashů stále větší smysl, než druhá možnost.

4. 5. 2023, 21:52 editováno autorem komentáře

Čili jestli to správně chápu, Google vlastně objevil přihlašování klientským certifikátem, které je tu s námi už určitě dvacet let? Jen toto znovuobjevené kolo je nyní správně moderně obalené tunou javaskriptu a dalšího balastu, který si ideálně každý web implementuje trochu po svém. Přitom stačilo trochu zpřívětivit manipulaci s klientskými certifikáty, se kterými umí browsery nativně pracovat dávno.

V podstatě úplně stejně, jako kdyby tam dal reCAPTCHA, aby si ověřil, že zákazník je robot. Jen teda bude muset věřit Google, místo aby si dělal svou databázi uživatelů.

Jak to bude fungovat z pohledu eshopu, který si potřebuje ověřit identitu uživatele?

Dneska jsem se registroval na jednom webu, HTTPS sice ma, ale heslo mi prislo e-mailem :D
Heslo bylo samozrejme nahodne vygenerovany a unikani pro ten web, tak je mi to v zasade jedno, ale prijde mi to vtipny :-)

přitom tohle prohlížeče uměly a dělaly to před desítkami let, viz rfc2069, jen to nikdo nikdy neaktualizoval na lepší algoritmy až doteď (webauthn).

Jasné, že auto potřebuje motor, aby mne odvezlo z bodu A do bodu B.
Ale nepotřebuje k tomu omezovač rychlosti připojený na GPS a aktuální databázi povolených rychlostí, abych tam jel bezpečně - úplně postačí, když nebudu tolik šlapat na plyn.

Podobných věcí dělá prohlížeč milion.

O skriptování nebyla vůbec řeč. To, že si myslíte, že nemáte nějakou potřebu, neznamená, že ji nemáte. Je to jako kdybyste tvrdil, že nepotřebujete v autě motor, protože jenom chcete, aby vás odvezlo z bodu A do bodu B.

To má ale tu nepříjemnou vlastnost, že přímo nutíte prohlížeč vykonávat nějakou chytristiku. Nejen, že musí nějakým scriptem šifrovat přihlašovací informace, ale navíc ještě komunikovat nejen s plug-iny, ale často dokonce s aplikacemi mimo browser, případně zařízeními mimo počítač.
Přitom já naprosto nemám potřebu něco na straně prohlížeče počítat, potřebuji jen zadat údaje na server, aby mi mohl připravit odpověď.
Prohlížeč má IMHO být jen terminál, rozhraní k serveru, přenášející pár nezbytných informací (texty, události) - a s tím by si měl server poradit. Vše musí v základu fungovat i bez scriptů a dalších dodatků - jen to s nimi může fungovat lépe.

(Ani tady nemám scriptování zapnuté. A taky to perfektně funguje!)

to ale nemá nic společného s passkeys, ale s přístupem Googlu, který je občas dost tvrdohlavý. Tohle jsem nezkoušel. Používám yubico, macos a passkeys zatím pro svoje aplikace, je to pohodlné, rychlé, bezpečnější než pořád přepisovat heslo a dobře se to kombinuje s 2FA a zadáváním nějakého pinu.

4. 5. 2023, 12:05 editováno autorem komentáře

My máme zavedený pro Androidy režim, že ten účet je per device, takže je jedno, kdo to zařízení zrovna používá. Beztak na tom nikdo donedávna nelezl na žádné důležité služby.
Akorát nám do toho hodila vidle banka, která nás nutí instalovat si přihlašovací aplikace - a tady je problém, že na jednom zařízení je více uživatelů. (Z nějakého důvodu musí mít každé dítko ke svému účtu svůj e-mail, svoje telefonní číslo a svou aplikaci, aby se podívalo na stav svého dětského konta, které je stejně vedené k účtům rodiče. Což o to, koupit další SIMku a založit e-mail je jednoduché, ale dostat dvě aplikace na jedno zařízení se mi spolehlivě nepodařilo. Naštěstí se lze přihlásit čipovou kartou, takže to zatím není nezbytnost.)

Sdílený počítač se sdíleným účtem je - žel - velmi častým standardem v mnoha domácnostech, kde se IT nevěnují nad rámec nezbytnosti. Obvykle jde o starší stroj, s Windows 7 (v horším případě XP), na kterém kromě starých her funguje jen brouzdání internetem, YouTube a Ofisy. Na ostatní má každý, kdo si to zaslouží, chytrý mobil, přičemž starší mobily se odsouvají od rodičů k dětem, nezřídka bez průchodu továrním nastavením (prostě se tam jen dá nová SIMka).
Další rozšířený modus operandi je jeden tablet pro několik dětí (obě, všechny...), na kterém jsou hry, internet a YouTube... Protože ty hry jsou často vázané na profil, je tam jen jeden.

Nám, kteří se o IT zajímáme, to může připadat divné, obvykle s takovými uživateli nepřicházíme do styku, mezi přáteli je nenajdeme, ale existují a je jich poměrně hodně.

Myšlenku vítám, ale na PCčku mi vyskočilo, že to na tomto zařízení použít nejde a telefon kvůli tomu hledat nehodlám.

Chápu, ale jsem skeptik. Právě mnou zapsané jsou nabeton ze společností, které se slučovat nebudou z principu. Do té doby, než nastoupí jiná mobilní autentizační platforma = čti RFID v paži :-)

Jen poznámka k tomu jednomu účtu... Takto to určitě fungovat nemusí. Sám každému nastavuji vlastní účet a dokonce na Androidu je možnost rodinné mediatéky, tedy sdílení koupených aplikací v rámci rodiny. Používám to takto několik let. Jeden sdílený profil je prostě špatně.

Protože je to úplně jiná technologie.

Jenže heslo se právě z jedné strany na druhou přenášet nemá. Přenášet se má jen informace, podle které si server může ověřit, že uživatel heslo zná (když se bavíme o přihlašování heslem). Pak by nevadilo, kdyby uživatel měl stejné heslo na více webech – protože jediná možnost, kde by heslo mohlo být kompromitováno, by bylo na straně uživatele.

To přihlášení skrze mobil bude vyřizovat webový prohlížeč, webová stránka o to jen požádá, ale pak už to jde zcela mimo ni. Takže profilovací služba se dozví maximálně to, že uživatel používá technologii passkeys.

Proklamace jsou hezká věc, ale praxe je poněkud jiná. Chtěl jsem si to zkusit a píše mi to: "aše zařízení nepodporuje vytváření přístupových klíčů, ale můžete vytvořit přístupový klíč pro jiné zařízení." Tak jsem chtěl zkusit aspoň to "pro jiné zařízení", prohlížeč si nechal odsouhlasit předání informací o tokenu, provést cvičný podpis - a výsledkem bylo jen přidání druhé instance téhož tokenu, u které je stejná poznámka, že ho lze použít jen pro dvoufázovou autentizaci.

ale vždyť to tak přesně je, FIDO podporuje passkey a můžeš mít ten klíč na tokenu místo na zařízení (https://fidoalliance.org/passkeys/).

Tak jsem si chtěl vyzkoušet, jak to vlastně přesně funguje (protože ty oslavné články jsou na můj vkus moc tajemné), a prý že Vaše zařízení nepodporuje vytváření přístupových klíčů, ale můžete vytvořit přístupový klíč pro jiné zařízení. Takže nic...

Ta myšlenka soukromého klíče uloženého přímo v zařízení (včetně mobilních) a jen chráněného PINem nebo dokonce biometrikou se mi ani trochu nelíbí. Ale doba je holt taková, že si každý musí vymyslet nějaký svůj nestandardní cool nesmysl místo toho, aby se drželi existujícího standardu (FIDO2) a nechali na uživateli, jestli chce mít implementaci softwarovou, pevně svázanou se zařízením nebo samostatný token. :-(

P.S.: mimochodem, je dost těžké věřit Googlu, že mi chce pomoci se zabezpečením, když musím po každém přihlášení jako blbec zrušit zaškrtnutí checkboxu "znovu nepožadovat na tomto zařízení" místo toho, aby si prostě zapamatoval, že ten druhý faktor pokaždé použít prostě chci.

4. 5. 2023, 09:01 editováno autorem komentáře

Naopak - tímto by se počet "autentizátorů" měl časem zredukovat pouze na jeden - ten, který bude držet Vaše passkeys. Ale hádám, že to bude ještě dlouhá cesta :(, vzhledem k tomu, že některé banky mají stále přihlašování přes SMS a webové rozhraní jim nefunguje na mobilu...

A použít Google Authenticator nejde? Proč?

Blbosti uživatele se zabránit nedá - a ty formuláře tu nejsou od toho, aby něčemu bránily, ale aby přenesly údaj z jedné strany na druhou.
Profilovací služby se zajímají o to, kam se člověk přihlašuje - a snaží se různými triky udržet identitu napříč weby. Jednotné, obtížně vypnutelné a do zařízení zadrátované (jasně, tohle je stále ještě soft řešení, ale...) přihlášení tomu poměrně dost napomáhá.

Ne, ta hesla ve formulářích nejsou dostačující pro žádné použití. Nedokážou zabránit tomu, že si někdo nenastaví stejné heslo kupříkladu do diskusí na Lupě a také do e-mailu. Profilovací služby pro reklamní servery se o tom klíči nijak nedozví.

Na druhou stranu: ta hesla ve formulářích jsou pro mnohá použití dostačující (kupříkladu pro vstup do diskusí na lupě, na rootu...) a navíc umožňují pracovat více lidem na jednom sdíleném profilu.
(Domácí PC je obvykle pro celou rodinu pod jedním účtem; dvě děti se dělí o jeden tablet s jedním profilem, aby nemusely kupovat hry dvakrát...)
Na ledacos je pohodlnější a vyhovující vyplňovat hesla a mazat cookies. Jednotného klíče vázaného na zařízení (profil) se nezbavíte a prostě si všechny služby sjednotí a přiváže k jednomu místu - nic lepšího si profilovací služby pro reklamní servery nemůžou přát.

To, že ten web neumí ani HTTPS, je už jenom taková „třešnička na dortu“. I trvale odemčený mobil je pro útočníka pořád mnohem větší překážka, než slabé heslo používané na desítkách různých webů. Navíc to passkeys asi také bude vyžadovat opětovanou autentizaci uživatele, třeba otiskem nebo obličejem. A konečně, dneska už mobily umí to, že dokud mobil máte u sebe, zůstává odemčený, ale když ho odložíte, zamkne se. Zabezpečení přes passkey určitě nebude dokonalé, ale je to pořád mnohem lepší, než současná hesla psaná do webové stránky (ono je skoro všechno lepší, než ta hesla ve webových formulářích).

Ano, i v roe 2023 jsem narazil na web (e-shop), kde bylo potřeba vytvořit si účet se jménem (e-mailem) a heslem - a ten web neuměl ani HTTPS!
Ale tohle bezheslové přihlašování je tak trochu z bláta do louže, protože lidé, kteří nezvládnou pracovat s dostatečně silnými a různými hesly, také zpravidla mají zabezpečený mobil ve stylu při nošení odemčeno, doma a v práci odemčeno, zbytek chrání heslo ve tvaru "Z"....
Pokud nevěříte, že tací existují, tak jen nepřijdete do styku s těmi správnými uživateli mobilů....

Škoda, že v mobilu tímto roste počet autentizatoru. MS, Google, banka (každá svůj) , govermerment, mojeid,...

Připadá mi zvláštní, že nejsme schopni přes dvacet let udělat normální bezpečné přihlášení heslem na webu, a pak se rovnou přeskočí do fáze přihlašování bez hesla. Ale OK, díkybohu za to, pokud to znamená, že se konečně v historicky krátké době zbavíme té parodie na zabezpečení, kdy se heslo (pokud možno ke všem službám stejné a jednoduché) píše přímo do webové stránky, tak, aby si ho mohl přečíst každý skript na stránce a pak se v otevřeném tvaru pošle na server, aby si ho zase ho mohl na serveru přečíst a uložit každý, kdo se k té komunikaci dostane (minimálně celá aplikace, nebo často úplně všechno, co je za TLS terminací).