Teď ještě aby web, kam se přihlašuju, obdržel nějaká metadata o mě. Minimálně časové pásmo (Europe/Prague), protože z prohlížeče lze zjistit jen offset a to není dost dobré -- takže se to všelijak hádá. A pak také, podle volby uživatele, i další data: jméno, adresa (pokud je to třea e-shop) a tak vůbec.
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.
...před finalizací precizovat standardizaci pro CA a současně precizovat algoritmus dialogu při přihlašování. Google bude motivován už tím, že Franta Vopršálek frekventně užívá jeho reklamně prošpikované služby. osobně mám pouze obavu, co s tím udělá globální rozšíření a multiplikace dotazů k jedné CA v daném čase...
Za chvili bude tolik vselijakych ID prihlasovacich systemu, ze to bude uplne stejne, jako mit hafo uctu s ruznymi jmeny a hesly. A typicky web bude podporovat tak 3 z existujicich 250. Krome toho mi nejak unika vyhoda tehlech veci. Sice si nemusim pamatovat hafo hesel, ale kdyz o to heslo prijdu, ma utonik pristup na vsechna ma konta.
Co když si nasimuluju identifikační autoritu a vygeneruju si certifikát na cizí emailovou adresu a ten pak dotlačím do prohlížeče a budu se snažit s tím někam přihlásit?
Z článku vůbec není patrné, jaká je vazba mezi webovou stránkou, kam se chci s browserID hlásit a tou identifikační autoritou (krom zmínky, že autorita neví, kdy a kam chodím).
V popisu přihlášení je kouzelný bod
4. Odpověď je vrácena stránce a uživatel je přihlášen.
Uživatel nemuže být přihlášen vždycky, odpověd je přece třeba ověřit.
Jak se toto ověření děje, když autorita neví, kdy a kam chodím a i v článku se píše
"Po provedení výše uvedeného postupu už autoritu vůbec nepotřebujeme, protože jsme získali potvrzení o platnosti naší adresy a o tom, že jsme jejími vlastníky."
Ještě by to mohlo fungovat tak, že při prvním pokusu o přihlášení konkrétního uživatele si od autority vyžádá jeho veřejný klíč, ten si někde schová a dál autoritu nepotřebuje, ale zase jak se pak řeší revokace kompromitovaných klíčů... no asi si to budu muset někdy přečíst v odkazovaném originále
Při registraci u autority dostanete certifikát, kde bude napsáno "já, autorita, potvrzuji že uživatel XY má email XY a veřejný klíč ABC". Tento certifikát je zakódován privátním klíčem autority. Vy ho ještě zakódujete svým privátním klíčem.
Certifikát pošlete webu, kam se chcete přihlásit. A řeknete mu svůj veřejný klíč a jméno autority. On se autority zeptá na její veřejný klíč (nebo už ho bude vědět). V tomto dotazu neříká na koho se ptá, jen ho zajímá veřejný klíč té autority. Následně dekóduje certifikát vaším veřejným klíčem a následně i veřejným klíčem autority. Porovná váš veřejný klíč s tím co je uložen v certifikátu - tedy že mu ho poslal ten, kdo byl certifikován. A toť vše. Web opravdu nepotřebuje autoritě říkat koho chce ověřit.
Nicméně z pohledu poskytovatele obsahu se budu nutně rozhodovat, kterou autoritu budu brát vážně a ignorovat ty, jež neznám. A jsme zase na začátku, protože kromě několika explicitně povolených autorit nebudu věřit nikomu a tedy email/identitu nebudu považovat za potvrzenou.
U openID je to jiné, protože ověřuji přímo skrze zadanou adresu/identifikátor. A pokud ta identitu ověří, tak se za ní nikdo cizí bez jejího souhlasu nemůže vydávat.
Ja to pochopil tak, ze autority tretich stran (jinych nez je poskytovatel danyho e-mailu) jsou jen do zacatku a casem by mely idealne uplne zmizet. Kazdej poskytovatel e-mailu by pak byl autoritou pro svoje ucty a bude existovat nejakej standardni zpusob, jak od nej dostat potrebny info pro overeni klientskyho certifikatu (zatim neexistuje)
.
To na prvni pohled vypada dobre, protoze by to znamenalo, ze kdyz si to rozjedu na svy domene, bude to stejne plnohodnotny jako od nekoho velkyho, podobne jako u OpenID. Zaroven to ale vypada jako slaby misto, protoze to znamena verit komukoliv, vcetne nejakyho MITM sediciho mezi cilovym serverem a autoritou a vydavajicim se za ni. Ale pokud by melo byt jeste neco nad tim, tak uz je to zase nezajimavy, protoze by to bylo nechutne centralizovany. I kdyz kdyby se ten standardni zpusob, jak se dostat k autorite, nacpal napr. do DNS, tak s DNSSEC by to bylo bezpecny dost. Zavislost na nekom dalsim je tam sice taky, ale system uz funguje a nestoji to nic navic, takze by to bylo prijatelny.
Asi to vůbec nechápu. Kde jsou metadata? Proč bych si měl chtít ověřit/vybírat z vícero email adres, když k tomu žádná data vázána nejsou a je tedy jedno, kterou použiji. Co se zobrazí např. na diskuzním fóru? (já nechci zveřejňovat email). Proč se email ověřuje jestli je můj, pokud se nebude zveřejňovat na cílovém webu a celé to slouží jen k ověření, že to jsem zase já, je přece jedno, jaký tam bude identifikátor, klidně email souseda nebo hacker007. Snad jen abych mu to jako identifikátor "nezabral". Navíc když už bych něco bezpečného vymýšlel, asi bych se snažil, aby to bylo na ostatních službách (zvláště emailu posílaného často nezabezpečeně) nezávislé.
Nevím co mají být v tomto případě metadata, jestli to mají být dodatečná data o uživateli (jméno,příjmení, adresa, atd.), tak je na provozovateli služby co si od užtivatele nechá vyplnit a je na uživateli co tomu provozovateli o sobě sdělí. To se mí líbí mnohem víc, než kdybych musel do jednoho profilu třeba kvůli e-shopu vyplnit svoji adresu a ta by pak byla dostupná i nějakému diskusnímu fóru, kde po mojí adrese nikomu nic není, jen proto že se tam přihlašuju se stejnou identitou.
To samé je důvod pro vícero e-mailových adres -- asi nejsem sám, kdo používá víc e-mailových adres a vybírá si, kterou komu dá k dispozici (i kdyby se pak nikde veřejně nezobrazovala, při přihlašování ji dávám nějakému provozovateli služby, ke kterému mám nějaký stupeň důvěry)
Ano, metadaty myslím právě jméno atd, o kterém se vůbec nikde nepíše. Pokud si tyto informace ode mě vyžádá následně konkrétní web, tak to pak není vůbec žádná výhoda, to už mohu rovnou vyplnit celý formulář (i s jménem/heslem). U openID mi to bylo jasné, tam se o jménu, adrese atd bavíme od začátku a komu co z toho pak poskytneme.
Více adres - a právě proto píšu, že používat email pokud neslouží k něčemu dalšímu jako identifikátor je nesmysl, protože musím řešit, komu jaký dám a navíc (opět narážím na chybějící zmínku a metadatech) je to jediný údaj, který by (možná) web o mně měl, takže bez otravování dalším formulářem by neměl možnost zobrazit třeba na tom fóru u mého příspěvku nic jiného, než ten email, což asi málokdo bude chtít. A další věc je, že do něčeho, co má být bezpečné, se montuje posílání linků emailem, což je z principu po cestě neuhlídatelné a nebezpečné. Nelíbí se mi to (zrovna tak jako openID, to ale i z trochu jiných důvodů), nic mi to nepřinese, nic to nezjednoduší, nevěřím v rozšíření mezi prostý lid, tak jako jsem nevěřil openID.
V této chvíli se to asi neřeší. Možnosti jsou dvě a obě velmi triviální na implementaci:
1. Můžete metadata předat autoritě a ona je vloží už do certifikátu, kterým potvrzuje vaši identitu (ve smyslu "má email XY, jmenuje se ABC atd."). Nevýhoda je, že se při změně údajů musí generovat nový certifikát. A také to svádí myslet si, že ty údaje někdo ověřil, což není pravda - jediná ověřená věc je ta, že se vám podařilo přečíst autorizační email.
2. Můžete metadata přidat sám ve chvíli, kdy balíte certifikát od autority svým privátním klíčem. Výhoda je, že si svoje metadata udržujete ve svém prohlížeči. Ve smyslu "hele, autorita potvrzuje, že mám email XY, a já navíc tvrdím, že jsem Karel". Navíc tak můžu použít jedinou emailovou adresu a stejně si volit co kterému webu prozradím.
Osobně bych preferoval druhou variantu. V každém případě obě varianty jsou velmi jednoduché na implementaci, takže asi nikdo zatím nemá potřebu to řešit.
Autorita ktory by podpisala nieco co si neoverila by bola nedoveryhodna a prave tak aj jej certifikaty a nikto by s nou nespolupracoval.
Cele je to ovela jednoduchsie. Cely napad spociva v jedinecnosti identifikatora. Teoreticky by to mohlo byt vygenerovane jedinecne cislo. No a autorita by musela vediet managovat tvoju identitu cez toto cislo.
Takze 2 muchy jednou ranou:
- Emailova schranka je jedinecny retazec (jeden clovek moze mat viac adries ale jedna adresa nemoze patrit dvom ludom bez toho ze by o tom vedeli)
- V pripade straty privatneho kluca, hesla, ... sa autorita moze obratit s moznostou potvrdenia prislusnej akcie
Uz sa len nepomylit a nedat si ten kluc ako autentifikacny pre prihlasenie do mailu :-).
Na implementaci možná, ale hlavně to musí být jednoduché pro uživatele. Moje mamka nemá nejmenší problém vyplnit formulář na eshopu, vidí co jim poskytuje za data, nebo se přilogovat na Seznam do pošty. Rozhodně by ale měla problém spravovat několik emailů (proč, jeden jí stačí) a pamatovat si, co v navázaných certifikátech je za data, jak to případně změnit/přegenerovat (bod 1), prostě nereálné.
Bod 2 bude pro ní úplně stejně nereálný a navíc ona jednou brouzdá ode mě (Chrome), jednou od sestry (FF), to si jako bude umět ty certifikáty synchronizovat, aby je měla ve všech prohlížečích kam přijde? Bude umět pochopit, co kam a kdy může synchronizovat, aby to nebyl bezpečnostní problém? Prostě klidně ať vypadám jako brzda pokroku, ale na přihlášení jménem/heslem pro drtivou většinu neIT lidí tohle nemá.
Postup vypadá zajímavě (konečně někoho napadlo oddělit nebezpečné zadávání hesla od webového obsahu). Nicméně se bojím, že jej nikdo nebude chtít nasadit převážně z těchto důvodů
- přišel pozdě
- přihlášení bude dokonale anonymní (a provozovatelům služeb jde v první a poslední řadě o osobní údaje)
- po obřím tlaku na prosazení zpackaného MojeID už nikdo nebude chtít experimentovat s dalšími technologiemi
- M$ má své liveID, takže v IE na BrowserID můžeme rovnou zapomenout
Musím říct, že víc se mi líbil nedávný pokos Mozilly zvaný Account Manager: h*tp://zdrojak.root.cz/clanky/spravce-uctu-ve-firefoxu/
A už měli i ten plugin pro prohlížeč (Firefox samozřejmě) a veškerou dokumentaci k tomu aby technologii mohl každý správce stránek okamžitě implementovat.
Tlačítko do prohlížeče realizované jako plugin je ovšem už nefunkční v FF5, což bude asi špatné znamení, vzhledem k tomu že jsem už o tomto nápadu dlouho neslyšel a v prohlížeči to tlačítko není tak to asi odpískali.
BrowserID se zase nebude moc líbit programátorům... s mojeID měli docela dobře zaručenou originalitu uživatele, ale emailů může mít každý stovky, takže nasazení takové technologie jim nic nepřináší a jestli ji přímo nebudou vyžadovat uživatele tak se dalšího roku existence nedožije.
identit přes OpenID můžete mít také stovky.
Výhoda BrowserID je srozumitelný identifikátor, nevýhodou fakt, že identita je ověřena někým třetím (nějakou certifikační autoritou). A to už přeci existuje, odlišnost mi unikla.
Pro mne nejsnazší řešení by bylo rozšířit OpenID o možnost zápisu identifikátoru ve tvaru emailu a zahrnutí definice nějakého standardního překladu na url do standardu: xxx@example.com na example.com/openid/xxx
Jestli to poskytovatel spojí s emailem je jeho boj. Z pohledu poskytovatele identity by nastavit přesměrování nemělo být těžké (chce-li to podporovat) a knihovny pro poskytovatel obsahu by se upravily jen lehce pro ošetření uživatelského vstupu.
Přes OpenID určitě, o tom taky snad nikdo nepochybuje... já psal o mojeID, které se ověřuje adresou domu, nebo i předložením občanky a správce serveru který přihlašování přes mojeID implementuje se může dotázat 'jak moc je identita přihlašovaného ověřená?'.
To je ta věc co přiměla (a snad ještě přiměje) hodně správců stránek mojeID použít. Víme jak problematické je na netu mít anketu/dotazník, kterou by nikdo nefalšoval... s tímhle se možnosti falšování velmi omezí.
Tak pokud zavedete anketu jen pro lidi s plně ověřeným MojeID, bude super objektivní - bude vám tam hlasovat pár nadšenců a geeků.
Ty podmínky - vědět co je to MojeID, pochopit to, zaregistrovat se (pravá adresa, pravý mobil), počkat než přijde dopis (do vlastních rukou, takže pracujíc člověk musí na poštu), a nakonec donést osobně občanku do sídla NICu v Praze v jejich úžasnou otevírací dobu 8-16 (nebo úředně ověřovat kopii a posílat ji poštou, to je ještě horší).
A doplněk do Wordpressu byl zase stažen 211 krát ;)
http://wordpress.org/extend/plugins/browserid/
Mě by zajímalo jak to bude s časovými platnostmi certifikátů, které získám při registraci. Budou mít certifikáty platnost 100 let nebo budou vyprchávat a já se budu muset přeregistrovávat/generovat nové certifikáty?
Doufám, že to někdo masám BFU vysvětlí a plugin do FF přegenerování za ně ohlídá.
Není to tak dávno, co čeští podnikatelé narazili na praktické "výhody" certifikátů.
Takze tady se jedna o vydavani certifikatu na zaklade pristupu k e-mailu. Takze tady budou muset byt "certifikacni autority", jen tezko si nekdo postavi sveho vlastniho providera stejne jako u OpenID. Bude jenom par duveryhodnych certifikacnich autorit a kdokoli se dostane k temto autoritam je pak schopen si vytovorit pristup k libovolnemu uctu. Dokonce i k uctu, ktery drive u neho overovan nebyl (urcite se resi, kdyz nahodou nejaka autorita prestane fungovat. Takze proste musi byt moznost stejny mail podepsat jinou autoritou). Takze u OpenID riskujete ze vas poskytovatel je nechopny u BrowserID je pro vas rizikem kazdy poskytovatel.
Navic je pro vas timto rizikem i poskytovatel vaseho E-mailu a kazdy narusitel vaseho E-mailu, ktery automaticky ziska pristup ke vsem Vasim uctum.
A k tomu pripocteme integraci do Browseru. Vsude kde se budete chtit prihlasit budete nejprve naimportovat certifikat do browseru (samzorejme jednoduse, pres stranku certifikacni autority a pristup do e-mailu), jenze kdyz se blbe ukliknete a zaskrtnete - pamatovat si certifikat trvale. Ma pripadny utocnik pristup ke vsem vasim uctum.
Jako pro naprosto nezvazne blogovani, diskutovani atd. to asi nemusi byt problem, ale pro cokoli s vyssi dulezitosti bych tohle nepouzil.
Všechny ty vize o jedné kartičce pro všechny služby (Opencard), jednotného přihlašování (OpenID) mají jeden základní problém ve svém designu - nechápou fakt, že KAŽDÝ provozovatel chce mít vlastní databázi, do které si o svých ovečkách sbírá data a nechce ji s nikým sdílet, nebo někoho žádat o povolení. Proto máme peněženky plné "universálních" RFID plastových kartiček a na každou hloupost se musíme znovu a znovu registrovat a dávat k dispozici svůj e-mail a další osobní údaje. Takže, buď bude BrowserID obrovským molochem, který bude rozdávat osobní údaje komukoliv na vyžádání, anebo skončí jako jeho starší bratříček.
Přesně tak.
A proto mi taky připadá nejlepší mít SSL certifikáty. Vygeneruju si svůj, private klíč mám v security store v prohlížečí, certifikát neobsahuje žádné údaje krom public key. Každému poskytoveli služeb pak při registraci vyplním kromě public key jen takové další údaje, které bude vyžadovat.
A nikdo centrální o mně nebude nic vědět.
BrowserID ale řeší spoustu věcí.
- zajišťuje +/- stejnou bezpečnost, jako byste se pokaždé přihlašovali tak, že na mail přijde jednorázové přihlašovací heslo (tato úroveň je pro většinu internetových aplikací brána jako dostatečná)
- dělá to uživatelsky přívětivě - 3 kliknutí a jste přihlášeni
- žádná centrální autorita Vás nemůže sledovat - stránky si jen stáhnou veřejné klíče k certifikační autoritě a vůbec nikomu nemusí říkat, na co je potřebují
- odstraňuje riziko stejných přihlašovacích jmen a hesel - provozovatel jedné stránky je nemůže použít k přístupu "Vaším jménem" na jinou stránku
- uživatel vůbec nemusí řešit heslo - kolik znaků, jak velkých, kolik písmen a číslic a jak je heslo silné
- osobních údajů se browserID vůbec netýká - Váš veřejný klíč obsahuje pouze emailovou adresu (tento údaj lze relativně bezpečně a zdarma ověřit) a nic jiného obsahovat nebude - to by musel být placený certifikát. Nahrazuje tedy výhradně heslo - přihlašovací jméno je totožné s emailem.
Zůstává nevýhoda - že lze na napadeném počítači získat tajný klíč a potom má přístup na všechny stránky, na které chodíte a také na ty, na které budete chodit ;-)
Přibývá nevýhoda - že pokud se jednou někomu podaří zjistit heslo k elektronické poště a stáhnout si odpovídající údaje, lze se úspěšně vydávat za někoho jiného - bez zanechávání dalších stop - bude jen jediný email a ten lze rychle smazat.
Jsou formulovány v článku When will we ever learn? . Autor je zjevně pesimista, v závěru článku poukazuje na skutečnost, že Browser ID je určen jen pro Firefox a vůbec není jasné, zda tímto směrem budou chtít jít ostatní prohlížeče, z existujícího popisu není jasné, kde všude probíhají autentizační postupy a zmiňuje pochybující vyjádření zakladatele Open ID (Dick Hardt).