Jaký je rozdíl oproti přihlášení klientským certifikátem přes HTTPS? Mně to připadá jako taková levná nedodělaná kopie tohoto systému – přeci jen od certifikační autority se vyžaduje jasně daná certifikační politika, HTTPS je známý a prověřený protokol; BrowserID používá (podle článku) stejný základní princip (přihlášení certifikátem vydaným certifikační autoritou), jenom tam není ta infrastruktura okolo, která v případě PKI předchází útokům zneužívajícím špatné implementace.
To kouzelné slovo je "je to zdarma".
PKI je z pohledu více bezpečné, ale mít certifikační autoritu není jen tak. Za důvěryhodnost CA se musí zaplatit, jinak nebude na seznamu důvěryhodných a prohlížeče budou hlásit, že se jedná o neověřenou CA. To na důvěře nepřidá. A hádám, že to nebude zrovna levné. A kdyby to pak nabízel zdarma, tak sice získá popularitu, ale na druhou stranu prodělá. Příkladem byl třeba epodpis od Thawte. Dnes už zdarma podpisy nenabízí, pač prodělal.
Já ale přece nepotřebuju žádnou autoritu. Vygeneruju si klíč klidně sám, při registraci na nějakém webu mu dám svůj public key. Technologie je dávno hotová, jen to začít používat. A trochu zpřehlednit UI správy a generování klíčů v browseru.
Problém je "jen jeden". Běžný uživatel to asi stejně nezvládne. Ale ten kdo to nezvládne, tomu bych nepovolil ani přihlášení jménem a heslem, protože je to analfabet a v jeho rukách je nebezpečné cokoliv.
Takto by bylo možné si generovat klíč na kohokoliv (na cizí e-mailovou adresu), jestli to správně chápu, role té autority je v ověření vlastnictví té e-mailové adresy). Ale taky mi není jasné jak tam ta autorita figuruje při ověřování, taky první co mě napadlo je vygenerovat si klíč bez ohledu na autoritu...
Na ověření emailové adresy žádnou autoritu nepotřebuju. To si můžu jako provozovatel služby snadno udělat sám.
Pokud někdo potřebuje skutečné ověření, řešení je rovněž jednoduché. Stát nám dává občanky. Zadarmo. Nevidím důvod, proč by mi při té příležitosti nemohla bába podepsat nějaký public key, co si přinesu na flashce. To zabere pár minut. Jasně, běžným uživatelům to bude k ničemu, protože neumí zacházet s daty a privátní klíč jim někdo sebere. Ale takové stejně nelze nachat s počítačem dělat závažné věci.
Prrrrrr,
to nie je take jednoduche. Vy podpisujete verejny kluc PLUS "nejake informacie" a tu je jadro problemu. Ten kto vam to podpisuje prehlasuje ze overil ze vlastnik prislusneho privatneho kluce je aj nejaka osoba (meno, priezvisko) ma nejaky email, bydlisko, ...
Potom je otazne:
- ako to baba overi?
- co vsetko bude sucastou podpisu (ktore udaje)
Jedinym riesenim je aby stat vydaval viacero certifikatov. Povedzme ze:
- Minimalny: s emailom
- Normalny: + Meno Priezvisko, +Postova adresa
- Uplny: +rodne cislo, ...
Vy by ste si potom volili ktory chcete pouzit. Napriklad by ste si pomocou Normalneho alebo Uplneho mohli zriadit ucet v banke - ONLINE (bez potreby chodit na pobocku). A potom na prihlasovanie mozete pouzit Minimalny.
Ako ale vidite nie je to dane ani zakonom ani standardami. Technologia nam toto umoznuje ale realne nastavenie a zakonny ramec nad toto by mal dat stat.
Vždyť jo. Bába by vystavila certifikát s vaším public klíčem z té flashky a údaji z vašeho občanského průkazu. V tom počítači je stejně má, když ty OP vydává.
Pokud si chcete vybírat, které údaje budete komu poskytovat, pak máte pravdu, že řešením je certifikátů víc. Ale to je zhruba stejně tak těžké jako vygenerovat jeden ...
No a servery, které nějaká pavá identita nezajímá (tj. většina), těm bych prostě dával při registraci self-signed certifikát, bez údajů. Ověřoval by se jen public key, to úplně stačí. Však už dnešní prohlížeče vám při přihlašování certifikátem dají vybrat, který použít.
to už je trochu mimo téma, státní ověřování skutečné identity se může v některých situacích hodit, ale to je dost jiná oblast, než na kterou cílí BrowserID -- tj. běžné drobné webové služby, kde sice je potřeba registrace, nejde o nic extra vážného -- prostě +- ta úroveň zabezpečení, kde jsme ochotní si uložit heslo do problížeče.
Tak nechme vyšší ověření být.
Ale furt nechápu, co vlastně BrowserID přináší nového.
1) Bude to privátní klíč v prohlížeči (teda přesněji prý v pluginu Firefoxu).
---> Ten tam můžu mít už teď v PKI storu a vygeneruju si ho sám.
2) Nějaká autorita podepíše, že uživateli s email@domena.cz patří tento public key.
---> To mi ale jako poskytovateli služby nic nedá. Email si dokážu stejně "spolehlivě" ověřit sám, je-li to pro mě důležité.
Úplně by stačilo, aby broswer uměl vygenerovat pár private-public key přívětivým způsobem. A ten public key by se použil při registraci (např. předvyplňoval do označeného pole ve formuláři, nebo nějak jinak). A pak by se to prostě použilo při přihlašování, jako to dělá třeba portál VZP.
Ak nie je zaujem o pravu identitu tak sme uplne niekde inde.
Zriadte si certifikacnu autoritu "prva slobodna". Spravte jednoduchy mechanizmus na vytvorenie uctu a zadanie a overenie mailu. Potom kazdy kto chce integrovat vasu "authentifikaciu" musi iba pridat vas verejny kluc do zoznamu trusted certifikatov na svojom servri. Na to naozaj babu, ani stat, ani OP ani ziadne dalsie specialne technologie nepotrebujeme.
Nebo, jak už jsem psal, ještě jednodušeji.
V prohlížeči budu mít self-signed certifikát (na údajích nezáleží). Důležité jsou jen klíče.
Trust certifikátů na serveru bude založen na základě toho public key. Prostě při registraci místo kolonky "heslo" vyplním kolonku "public key".
A žádnou externí autoritu (zvlášť takovou co by byla zadarmo a tudíž nespolehlivá) k tomu nepotřebuju. Ale to by bylo moc jednoduché a nikdo třetí by na tom nevydělal.
To ty jsi mě obviňoval, že moje řešení způsobí, že správce serveru přihlásí pod mým účem jinde.
Psal jsi "A asi by vas nepotesilo ani to ze majitel jednej stranky by sa vedel dostat pod vasim kontom a "heslom" (public key) vsade kde sa pouziva tento druh authentifikacie.".
Tak vás jenom ujišťuju, že jsem opravdu nechtěl používat nějakou hexa podobu (nebo jak jste moje slova pochopil) public klíče jako normální heslo.
Certifikat by nikdy nevyprsel, ostatne generuju si ho sam, dam si tam platnost klidne 100 let. Na strane serveru bych kontroloval jen public key. Takze po "vyprseni" si vyrobim novy se stejnym klicem.
Co by se delo po ztrate klice? Tak bych pri registraci uvedl zalozni, nejaky "master" public key pro reset toho prvniho (obdoba "kontrolni otazky" nebo PUK u mobilu).
Porad mi to prijde jednodussi nez spolehat na nejakou podivnou treti stranu. Bud by byla zadarmo a tedy nespolehliva. Nebo za penize, a tudiz pro takovehle pouziti "na blbinky" prilis draha. A co kdyz zapomenu heslo na tu autoritu?
V tom mi ale BrowserID taky nepomůže. Když mi někdo sebere notebook s nešifrovaným diskem, tak se záškodník příhlásí na to browser-id, změní tam heslo nebo přihlašovací certifikát a já stejně nic nerevokuju. A jde vůbec Browser-id revokovat? Článek o tom nic nepíše.
Pokud toto chci řešit zdarma self-signed certifikáty:
- jak jsem říkal, můžu mít druhý public-private key pair sloužící na serverech pro reset toho prvního místo dnešní trapné uhodnutelné "kontrolní otázky". Ten na tom notebooku vůbec mít nebudu.
Pokud toto chci řešit pořádně (tedy ale o tom není tento článek!) tedy CA-signed revokovatelnými certifikáty :
- mít pořádnou (=placenou) CA, kam prostě fyzicky dojdu, ukážu jim doklad totožnosti a nechám resetovat všechny odcizené přístupové údaje a revokuju certifikáty.
Základ je, že se mohou rozhodnout sám jako uživatel. Pro server se nic nemění, on prostě kontroluje zda mám private klíč k public klíči certifikátu, který sem zadal při registraci. Akorát některý certifikát holt má revokovací url, některý ne.
Základní omyl všech pokusů o počítačovou bezpečnost je, že to chtějí přinést i mezi běžné lidi, co počítačům nerozumějí. To ale nikdy nemůže spolehlivě fungovat. Je to jako kdybyste chtěl zavést právní systém v zemi, kde lidi neumí číst a psát a nemohou si tak přečíst smlouvy a podepsat se.
Jenže vy řešíte trochu jiný problém. Místo zakládání desítek účtů s jménem a heslem si generujete desítky certifikátů. Stejně jako můžete mít na plno službách stejné jméno a heslo, stejně tak na ně můžete mít i stejný certifikát. S certifikátem si tak místo pamatování jména a hesla musíte ssebou nosit flashku s certifikátem. A riziko zneužití je rovněž stejné - v kavárně může nějaký malware certifikát stáhnout a uložit. Stejně tak se dá certifikát ukrást tím, že řeknete, že jste ho ztratili a služba vám akceptuje zcela nový.
Zkrátka, posouváte se od jmen a hesel (které si člověk zapamatuje) k souborům na flashce. Ale OpenID a BrowserID jdou jinam a řeší něco jiného - místo abyste se nějak přihlašoval k webové stránce, tak se ve skutečnosti přihlásíte k poskytovateli a ten za vás přihlášení k webu obstará. Jestli si certifikát od poskytovatele budete nosit na flashce nebo si ho pokaždé stáhnete znovu zadáním jména a hesla je na vás. Podstatné je, že máte účet jen na jednom serveru a pro weby je výhoda v tom, že ví, že jste na dané emailové adrese alespoň jednou četl poštu, takže to nebude pravděpodobně úplně cizí adresa. Pro vás tak odpadne nutnost u každého webu se registrovat a odpovídat na ověřovací email.
Stejně jako můžete mít na plno službách stejné jméno a heslo, stejně tak na ně můžete mít i stejný certifikát.
Tak to je přece velký rozdíl: když mám na všech webech stejné heslo, tak ho může získat jakýkoli z provozovatelů těch webů (a často i někdo po cestě mezi mnou a tím webem) a zneužít ho na webech ostatních. U SSL/PKI certifikátu (a BrowserID) to nejde, tam musím do kavárny.
A je nějaký důvod, proč by dvě principiálně shodné technologie měly být jedna "drahá" a druhá "zadarmo"? Při zachování stejné úrovně zabezpečení a důvěryhodnosti?
Použití klientských certifikátů nevyžaduje použití nějaké drahé komerční CA - můžeme mít nějakou skupinu serveru (např. iinfo, idnes atd.) a ta bude mít vlastní CA - uživatelé dostanou certifikát zadarmo a potřebný software je už dávno implementovaný (narozdíl od nějaké nové technologie, kterou je teprve potřeba implementovat, vychytat v ní chyby a přemluvit ostatní, aby ji začali podporovat). A jestli bude téhle CA důvěřovat i někdo třetí? Může, proč by ne - úplně stejně jako může důvěřovat cizí CA v systému BrowserID.
V tom případě by to chtělo toho "nahoře" nenápadně zpracovat, aby to dovymyslel tak, že to bude shodné s PKI. A pak ušetřené peníze investovat do toho, aby se práce s certifikáty v prohlížečích trochu zkulturnila.
Ve skutečnosti mi to ale nepřipadá, že by tohle byl nějaký manažerský nápad. Ono by mi bylo i celkem jedno, že někdo zase vymýšlí kolo, je tu však jedno velké ale: v oblasti prohlížečů se vymýšlí nový způsob autentizace certifikáty, vymýšlí se narovnáky na vohejbáky, které mají zabránit krádeži session_id v cookies, vymýšlí se, jak zabránit ukradení formulářových přihlašovacích údajů javascriptovými kejkly… Přitom už tady asi sto let existuje HTTP DIGEST přihlášení a přihlášení certifikáty. V obou případech se citlivé údaje předávají přímo prohlížeči, takže nehrozí krádež dat JavaScriptem nebo napodobení přihlašovací stránky, nehrozí ani jejich krádež odposlechem komunikace. V obou případech je extra chráněn každý požadavek, takže ukrást nějakou cookie je k ničemu.
A v obou případech je to také implementováno úplně nemožně, svorně napříč všemi hlavními prohlížeči. Že bude po přihlášení potřeba uživatele také odhlásit, k čemuž má být ovládací prvek uvnitř prohlížeče a ne na stránce (opět větší bezpečnost), toho si asi tak za 15 let nevšiml žádný autor prohlížeče. Proč prohlížeče soutěží, který bude mít pro HTTP Auth nebo přihlášení certifikátem hnusnější a nepřehlednější dialog, to také nechápu (čest výjimce Chrome, u kterého už se člověk alespoň dialogu na výběr přihlašovacího certifikátu nelekne). Nemluvě o tom, že pro MSIE je HTTP DIGEST taková exotika, že si klidně existuje s úplně základní chybou – někdy se uživatele sice zeptá na jméno a heslo, pak ale příslušnou hlavičku zapomene k požadavku přidat.