GPGauth - autentizace na webu pomocí GPG

9.10.2011 03:16 | Přečteno: 1385× | všemožno | poslední úprava: 9.10.2011 02:56

Nedávno jsem se došel k závěru že už mě začíná štvát věčné zadávání hesla na všech webových stránek. Začalo mi vrtat hlavou proč nemůže být webové přihlášení stejně snadné jako autentizace ssh za použití klíčů.

Samozřejmě že nejsem jediný kdo si tenhle problém uvědomuje; již delší dobu jsou zde snahy typu openid, oauth a podobně. Problémem je centralizace - aby jste mohly takovou službu používat musíte si vybrat poskytovatele. Nelíbí se mi poskytovat gigantům typu google, facebook či twitter ještě další informace a proto jsem hledal něco decentralizovanějšího.

Už nějaký čas používám LastPass. Služba mi vyhovuje, je výborně odladěná a je vidět že její tvůrci dbají na každý detail. Ač je to komerční služba (pro mě zadarmo) s centrálním úložištěm dat, tak všechny data jsou zašifrovány pomocí AES respektive pomocí Vašeho hesla. To je důležité zmínit neboť je to obrovská výhoda oproti konkurenci - i když byli jejich servery hacknuty nedošlo zde k žádnému úniku nezašifrovaných dat. Nicméně ač je LastPass tak úžasný a díky jen díky němu je tráva zelenější a lidé štastnější, není to řešení ale spíše náplast pro trvale krvácejícího uživatele jenž je zraněn pokaždé co ho někdo donutí napsat svůj login a heslo.

A pak mě napadlo jak by vše vlastně mohlo být jednoduché - kdyby se použilo GPG. To totiž nabízí metodu jak jasně a bezpečně prokázat že jsem ten za koho se prohlašuji. Ano, narážím na podepisování zpráv. Proč by autentizace nemohla být tak jednoduchá jako podepsání zprávy? Má představa byla následující: uživatel jde url example.com/login . Server mu pošle podepsaný token, v prohlížeči vyskočí nabídka jestli chce uživatel podepsat token a jakým klíčem. Server má nyní možnost ověřit zdali je uživatel skutečně ten za koho se vydává. V případě že není na serveru veřejný klíč uživatele, není problém ho stáhnout z keyserverů. Veřejný klíč je snadné ověřit například pomocí zaslání emailu na uvedenou adresu. Myslím že to není třeba dále rozebírat, metody na distribuci klíčů už zde existují dlouho.

Problémem je zde podpora v prohlížečích - samotné podepisování tokenu musí být automatizované. Tak mě napadlo kouknout se na google jestli zde něco podobného není, nic jsem nenašel. Poté mě napadla spásná myšlenka kouknout se na zdrojáky ne tak docela mrtvého projektu Firegpg, po chvíli jsem našel složku se slibným názvem GPGauth. A skutečně, byla to implementace něčeho hodně podobného.

Konkrétně se jednalo o GPGAuth.org. Na stránkách projektu najdete doplněk do chromu, návody na implementaci v php a djangu. Nejedná se o nic složitého, implementace je tak na dvě hodiny.

Tak a to je vše.        

Anketa

Komentáře

[pavlix]

Nelíbí se mi poskytovat gigantům typu google, facebook či twitter ještě další informace a proto jsem hledal něco decentralizovanějšího.

OpenID jde používat tak decentralizovaně, jak si sám zvolíš.

Tím nechci říct, že by na kryptografické autentizaci pomocí (třeba) GnuPG bylo něco špatného, právě naopak! Ale dokud nebude použití kryptografických klíčů pro uživatele běžnější než autentizace bez ní, tak je zde velký prostor pro obojí.

Ale radši se nejdřív podívej, jak pozvolná je adopce tak jednoduché technologie jako OpenID, než začneš doufat v rozšíření čehokoli složitějšího.

[AAAA BBB]

Ano to vím, nicméně nastavit to je pak dost složité, nemýlím-li se..

[pavlix]

Ty kryptografické klíče ano, OpenID funguje de facto samo (při dobré implementaci). Jediná konfigurace, kterou potřebuješ, jsou přístupy (kdo co smí), ale té se nevyhneš ani při ostatních způsobech.

[Saljack]

Problém tohohle je, že to musí být hrozně jednoduché aby to mohli používat všichni. Stačí když mají mojí spolužáci používat github a hned je problém s kličema. A to jsou lidi, kteří absolvovali předmět o bezpečnosti a diskrétní matematiku. Jak to potom tedy vysvětlíme nějakému nezkušenému uživateli?

[rm -rf]

Jak to potom tedy vysvětlíme nějakému nezkušenému uživateli?

S bicem v ruce.

[AAAA BBB]

on ten plugin je dost user friendly ale stejně asi uživatel musí chápat veřejnou kryptografii aby se s toho nestala magie...

[pavlix]

Vysvětlit to skutečně obyčejnému uživateli je mnohem jednodušší, než to vysvětlit matematikovi. Uživatel se totiž bude snažit to používat, matematik analyzovat. O programátorovi radši ani nemluvím :).

Když se ve firmě zavádí přihlašování pomocí kryptografie veřejného klíče, tak to uživatelům taky bez problémů vysvětlíš („vezmeš kartu a přiložíš ji tady“).

[Saljack]

Asi by záleželo jak by to bylo udělané. Ale představ si modelovou situaci naprostý laik se chce přihlásit ke svému účtu na své oblíbené stránce. Klikne na přihlásit, vyskočí (v lepším případě) dialog zda se chce skutečně přihlásit on klikne na ano a je přihlášen. Na návštěvě u známého se bude chtít taktéž přihlásit a je v pytli protože nebude naprosto vědět jak ho to doma přihlašuje. Řešením by bylo samozřejmě nějaký HW s klíčem (např. mobil).

[CEST]

A proc nepouzivas PKI? Podpora v prohlizecich, na serverech, podpora pro SW a HW klice na vsech plaformach, podpora pro komercni i self-signed certifikaty.

[pavlix]

Ono stačí pozorně číst a v postu najdeš slovo „decentralizace“. PKI je děravé jak podkousaný strom (díra v každé kořenové autoritě).

[xkucf03]

To není chyba PKI, ale chyba lidí, kteří důvěřují nedůvěryhodným certifikačním autoritám. A nakonec se na ty CA můžeš vykašlat a používat tu technologii (HTTPS + klientské certifikáty) stejným stylem, jako se používají SSH klíče.

Ty CA je potřeba brát jako něco, co ti může ulehčit a zpříjemnit práci (případně snížit bezpečnost za určitých okolností – ale za jiných zase zvýšit*), ale co nemusíš nutně používat. Např. když si stahuji zdrojáky Mercurialem z nějakého serveru s nedůvěryhodným certifikátem, zeptá se mě to, zda se mi ten otisk líbí a zda si ho to má zapamatovat a příště mu věřit – prostě se to chová stejně jako SSH klíče.

Tzn. není to o volbě technologie (SSL vs. GPG vs. SSH), ale spíš o způsobu, jakým ji používáš.

*) např. když nemáš bezpečný způsob jak distribuovat otisky veřejných klíčů, tak ti pomůže, že za ten certifikát podepíše CA (která má třeba víc poboček a uživatelé se k ní můžou dostat, zatímco k tobě to mají moc daleko) a zaručí se za toho uživatele (nebo za provozovatele serveru) a ty se např. vyhneš tomu prvotnímu risku, kdy poprvé odsouhlasíš nějaký otisk, o kterém nevíš 100%, zda patří druhé straně – což by se tedy dělat nemělo, ale někdy nemáš možnost, jak k sobě ten otisk bezpečně dostat.

[AAAA BBB]

SSH klíče se dají distribuovat přes DNSSEC..

[CEST]

Cokoliv muzes distribuovat pres DNS, tudis i DNSSEC. A ano, SSH klicne MUSIS distribuovat pres DNSSEC, protoze SSH klice jsou proste jenom klice bez podpisu doveryhodnyho subjektu - proste tam chybi ta autorita.

Ale jinak, x509 nemusis distribuovat pres DNSSEC, protoze x509 uz stejny system pouziva - pres CA.

DNSSEC je prakticky PKI - proste nekomu duverujes a ten pak overuje ostatni a potvrzuje jejich identity - pokud ten jeden duveryhodny selze, jsou vsichni jeho "klienti" neduveryhodni - at uz v PKI nebo v DNSSEC.

[petr_p]

OpenSSH již má nějakou dobu certifikáty.

[SPM]

ale ne X509 - je to spíš taková parodie na certifikáty... nicméně do OpenSSH existujou patche i na X509

[pavlix]

Parodie? Ty děláš, jako by x509 bylo něco víc než jen formát pro uložení klíčů a podpisů.

[SPM]

Nj, mít další formát pro něco jako certifikát mi přijde dost kontraproduktivní... buď už X509 certifikát kvůli něčemu mám a pak ho můžu v ssh použít anebo ho nemám, ale pak si vystačím raději s normálním klíčem, než schraňovat nějaký další nekompatibilní certifikát...

[pavlix]

Asi mě máš za hlupáka, ale já si všimnu, když se někdo vyhýbá otázce. Jestli nechceš odpovědět, v čem je to parodie, nemusíš.

[SPM]

Pokud se narychlo ubastlí něco, co má napodobovat již něco existujícího a spousta věcí tomu chybí, takže to stejně nikdo nebude používat, nazvu to parodií.

[pavlix]

Můžeš si nazývat věci jak chceš, ale těžko pak můžeš čekat, že ti ostatní budou rozumět.

[xkucf03]

Což je stejný princip jako CA.

[pavlix]

Podstatně se liší, a to konkrétně v tom, že CA v DNSSEC mají vymezené pole působnosti, kdyžto trusted ca v klasické PKI půzobí plošně.

[xkucf03]

trusted ca v klasické PKI půzobí plošně

Viz RFC 2459 z roku 1999 a Name Constraints:

The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path shall be located. Restrictions may apply to the subject distinguished name or subject alternative names.

Je zajímavé, kolik věcí už bylo vynalezeno a stačí je pouze začít používat

CA v DNSSEC mají vymezené pole působnosti

Což na druhé straně ale také znamená, že jsou monopolními CA pro danou doménu (neříkám, že je to vyloženě špatně – ono to spíš jinak nejde).

Tím nechci říct, že je používání DNSSEC špatné, naopak – když se někam připojuji (a je jedno, jestli je to HTTPS, SSH nebo cokoli jiného) a najdu tam samopodepsaný certifkát, jehož otisk se nachází i v DNSSEC TXT záznamech, tak je to důvěryhodnější, než samopodepsaný/nepodepsaný certifikát bez ověření otisku přes DNSSEC. Ale beru to jako takovou pomůcku, která lehce zvýší bezpečnost, něco jako druhý zámek na dveřích vedle toho hlavního…

[pavlix]

To není chyba PKI, ale chyba lidí, kteří důvěřují nedůvěryhodným certifikačním autoritám. A nakonec se na ty CA můžeš vykašlat a používat tu technologii (HTTPS + klientské certifikáty) stejným stylem, jako se používají SSH klíče.

Pokud to budu používat stylem, jak se používají SSH klíče, tak z PKI nepoužívám zhola nic. Sice občas lidi předstírají, že self-signed certifikát je něco více než jen veřejný klíč, ale za to já nemůžu.

Ty CA je potřeba brát jako něco, co ti může ulehčit a zpříjemnit práci (případně snížit bezpečnost za určitých okolností – ale za jiných zase zvýšit*), ale co nemusíš nutně používat.

Já PKI beru jako něco, co můžu a nemusím používat, tedy do jisté míry.

Tzn. není to o volbě technologie (SSL vs. GPG vs. SSH), ale spíš o způsobu, jakým ji používáš.

Já o voze a ty o koze.

[CEST]

Ale prd. GPG (original) nemel system duvery, proste sis musel potrdit kazdy klic, kteremu jsi chtel duverovat. Pry uz ted GPG taky nejaky system ma-klice potvrzuji uzivatele: jeden uzivatel potvrdi duveru nekolika jinym, ty potvrdis toho jednoho a tim duverujes tem jeho duvryhodnym-cili to same ja v PKI-pokud si nejaky blackhat potvrdi duveru u toho jednoho, tak bude duveryhodny u tech dalsich, stejne jako u PKI. Samozrejme si muzes i v PKI sam zvolit, komu budes duverovat. Single signon provider bude duverovat nejakym CA nebo i self-signed certifikatum (za cert si dosad gpg). A service provider pak bude duverovat nekterym identity providerum. Rozdil je v tom, ze pro PKI je podpora vsude (servery, browsery, muzes mit file cert nebo HW token, komercni cert nebo selfsigned), pro gpg pouze(?) v emailu.

Ale kdyz nechces vyuzivat tu ifrastrukturu duvery, tak nemusis, proste pouzivej selfsigned a jsi na tom stejne jako gpg. Akorat mas lepsi podporu.

A pro uzivatele je pouziti opravdu jednoduche.

Tak jako tak, je jedno, jestli budes pouzivat certifikaty od duveryhodnych CA nebo ne, v praxi bys stejne pri registraci zadal ten svuj certifikat. A prihlasovani certifikatem v prohlizeci i serveru (alespon apachi) uz existuje.

[pavlix]

Ale prd. GPG (original) nemel system duvery...

Dál nemusím číst, protože zřejmě každý píšeme o něčem jiném.

A prihlasovani certifikatem v prohlizeci i serveru (alespon apachi) uz existuje.

To už pokud vím docela dlouho :).

[CEST]

Ale prd. GPG (original) nemel system duvery...

Dál nemusím číst, protože zřejmě každý píšeme o něčem jiném.

Ano i ne. Premyslis o PGP/GPG jako o mechanizmu autentizace pro Weby.

gpgAuth is an authentication mechanism which uses Public/Private (cryptographic) keys (such as GnuPG, PGP) to authenticate users to a web-page or service.

Pricemz potrebujes implementaci v php a djangu, nejaky navody pro Chrome. Pritom GPG/PGP je pouze jako SW (nevidel jsem dosud zadny HW token, mozna taky existuje), ale pritom PKI je o hodne vic rozsirene a podporovane. Takze proc hledat reseni pro GPG, kdyz uz existuje pro PKI? Pricemz certifikat x509 muzes pouzivat uplne stejne jako GPG a mas k tomu navic moznost pouzit nejake verejne CA, cili duverovat certifikatum podepsanym jednim subjektem.

Takze do ankety bych doplnil - "Podle me to sanci nema, pokud nekdo nezainvestuje do vyvoje podpory v klientech, serverech, HW tokenech a do reklamy, protoze to vsechno uz PKI ma a funguje to a pouziva se to".

[AAAA BBB]

ok, je někde nějaký návod jak si vygenerovat PKI klíč a jak ho narvat do firefoxu? resp.: to narvání do firefoxu vím jak se dělá. Horší je to s generováním klíčů: našel jsem http://www.openssl.org/docs/HOWTO/keys.txt ale nevím jestli PKI je DES nebo DSA. A vůbec je to dost složitější než si v seahorse vygenerovat gpg klíč. Což je podle mě podstatný rozdíl, PKI se afaik většinou používá ve firmách které mají vlastní mechanismy na vytváření a distribuci certifikátů zatímco pgp je více user friendly a není problém ho používat bez speciálních znalostí. Mimochodem nevíte někdo jak je na tom kniha Báječný svět elektronického podpisu? Ostatní knihy v cz.nic jsou výborné, tak by mě zajímalo jak je na tom tahle...

[xkucf03]

jak si vygenerovat PKI klíč a jak ho narvat do firefoxu? resp.: to narvání do firefoxu vím jak se dělá. Horší je to s generováním klíčů

V HTML formuláři může být značka keygen a prohlížeč při odeslání vygeneruje soukromý klíč (ten si uloží) a veřejný pošle na server společně se zbytkem formuláře. Jednodušší už to snad být nemůže.

[xkucf03]

Pritom GPG/PGP je pouze jako SW (nevidel jsem dosud zadny HW token, mozna taky existuje)

Samozřejmě, že existuje – např. OpenPGP card.

ale pritom PKI je o hodne vic rozsirene a podporovane.

Souhlas (alespoň pokud se bavíme o webu/https).

Takze proc hledat reseni pro GPG, kdyz uz existuje pro PKI?

Snad jen proto, že v GPG můžeš mít svůj klíč podepsaný několika různými subjekty, zatímco u x509 máš vždy jen jednu CA. Jenže k čemu je na webu to dobré? Smysl to má snad leda při ověřování identity serverů (např. si stanovím pravidlo, že když danému klíči serveru věří tři moji důvěryhodní známí, budu mu věřit taky – tzn. věřit, že ten klíč patří k dané doméně), jenže tenhle blog je o ověřování klientů – a tady nic takového potřeba není – stačí mi jednoduše při registraci uživatele spárovat jeho veřejný klíč s jeho účtem, což můžu klidně dělat v x509 (viz #12) a není potřeba kvůli tomu zavádět novou technologii.

[pavlix]

To ale reaguješ na blogpost a jeho autora, ne na můj příspěvek.

[AAAA BBB]

Je to dost neintuitivní. Krom toho když jsem hledal informace o tom to používat ve firefoxu tak jsem toho moc nenašel. Ale kouknu se na to...

btw: našel jsem tenhle článek: http://www.root.cz/clanky/enigform-openpgp-rozsireni-pro-mozilla-firefox/ vypadá to že tahle myšlenka zdaleka není nová...

[xkucf03]

Nic proti GPG, ale proč objevovat Ameriku? Máme přece SSL/TLS a klientské certifikáty. Podpora je přímo v HTTPS protokolu a ve většině prohlížečů a snad ve všech www serverech. Certifikační autority nemusíš moc řešit, přihlásíš každého nebo budeš podporovat alespoň pár bezplatných CA (jako např. cacert.org) a v aplikaci si pak vytáhneš hodnotu SSL_CLIENT_CERT (to platí pro Apache, jinde to bude podobné) a podle toho identifikuješ uživatele (při registraci nebude zadávat jméno a heslo, ale svůj certifikát resp. veřejný klíč).

[petr_p]

Nechci vám kazit radost, ale TLS vedle X509 podporuje PGP. Takže netřeba nic vymýšlet, stačí přesvědčit výrobce webových klientů, že jej má smysl implementovat.

[xkucf03]

Jen doplním odkaz na implementaci: GnuTLS.

Support for authentication using both X.509 and OpenPGP certificates.

[pavlix]

Konečně komentář, který nepolemizuje s něčím, co předřečník netvrdí, ale přidává novou informaci! Díky.

[AAAA BBB]

ok, nevíte o nějakém návodu jak to používat?

[petr_p]

Jediná mně známá implementace je v GnuTLS. Ten má nástroje gnutls-serv a gnutls-cli, které mají příslušné přepínače určující veřejný klíč, soukromý klíč, podklíč a klíčenku. Takový drobný problém je, že zřejmě neexistuje HTTP server, který by používal GnuTLS. Co se týče klienta, tak tam třeba wget nebo curl lze přeložit proti GnuTLS, ale zase chybí uživatelské rozhraní, které by umělo pracovat s PGP. Navíc knihovna cURL snad zatím s klíči PGP pracovat neumí. I když umí třeba Serpent, což je třetí autentizační metoda v TLS. Ostatně velmi zajímavá metoda, ve které nepotřebujete certifikáty pro server a přesto klient dokáže autentizovat server. Jinak řečeno žádné hlášky „nedůvěryhodný certifikát serveru“.

[AAAA BBB]

Jinak řečeno je to v současném stavu nepoužitelné.. Škoda.

[xkucf03]

Takový drobný problém je, že zřejmě neexistuje HTTP server, který by používal GnuTLS.

Apache: a2enmod gnutls

což jsem jednu dobu i používal, akorát ne s PGP – ale mělo by ho to umět:

Support for RFC 5081bis OpenPGP certificate authentication.

Horší mi to přijde spíš na straně klientů, www prohlížečů.

[CEST]

Dobre, ale porad chybi ta zakladni odpoved.

Proc pouzivat GPG na veci, ktere uz PKI/X509 umi a da se s nim pracovat na vsech urovnich (servery a klienti, SW cert a HW token, self-signed i komercni cert vyuzivajici duveryhodneho prostrednika)?

* GPG ma slabou podporu v prohlizecich (nejaky pluginy)

* GPG neni na serverech (s gnutls to sice jde, ale nikdo to nepouziva - proc by mel, kdyz PKI/x509 funguje)

* GPG nema(?) HW tokeny (resp. asi by se dal HW token donutit, aby sifroval i pro GPG, ale do tohohle nevidim tak presne)

* GPG nema(?) komercni/"komercni" duveryhodne objekty, jejich klice/certifikaty by byly distribuovany v klientech/serverech

[petr_p]

* GPG nema(?) HW tokeny (resp. asi by se dal HW token donutit, aby sifroval i pro GPG, ale do tohohle nevidim tak presne)

Má. Referenční implementaci prodává firma, za kterou stojí pan Koch. Existují i konkurenční výrobci. Ono v podstatě jde jen o označení typu souboru v šifrovacím zařízením. Zařízení s otevřenými ovladači obvykle PGP klíče podporují.

* GPG nema(?) komercni/"komercni" duveryhodne objekty, jejich klice/certifikaty by byly distribuovany v klientech/serverech

Protože to je vlastnost. Ostatně i PKI má s tímto problém. Alespoň tady v Česku. Naproti tomu PGP má něco, co PKI nemá – klíčové servery. To je ta věc, proč nemusíte tahat celou databázi do vašeho počítače jako s PKI a čekat, až jeho výrobce vám dodá novou verzi. Popravdě řečeno vrcholová úroveň kvalifikovaných autorit v EU je také jenom seznam bez nějaké relace důvěry.

[SPM]

HW tokeny nedělají přímo nějaké SW věci... typicky umí nějakej šifrovací/hashovací algoritmus, dostanou data a vrátí je zpátky podepsané/zašifrované/etc... takže jo, HW tokeny můžou fungovat i s gpg (samotné gpg to snad i umí...), ale někdo by tu podporu musel dopsat... nicméně podpora HW tokenů je vesměs mizerná pro cokoliv - co se týče browsení, tak to spolehlivě s X509 funguje jenom ve Firefoxu (a o pečlivém výběru tokenu, aby fungoval na linuxu ani nemluvě).

[AAAA BBB]

Protože GPG je dostupné každému, je jednoduché na distribuci a neřeší tolik problému jako PKI čímž je mnohem srozumitelnější. OK, PKI má výbornou podporu v prohlížečích a protokolech, nicméně pro běžného uživatele je to docela magie. Ale možná že kecám :)

[marbu]

A co rikas na BrowserID? Neco o tom nedavno vyslo na rootu a na prvni pohled se to zdalo byt docela simpaticke. Ale mozna by pro tebe mohlo byt problem, ze je potreba mit k tomu certifikacni autority.

[AAAA BBB]

Vypadá to zajímavě i když po tom co jsem si pročetl odkazy zdejší komunity se mi to zdá jako jeden z těch horších nápadů.

[pavlix]

Mě to osobně přijde jako pokus „dělat si věci po svém“, což někdý může být dobré, ale v tomto případě tomu moc nevěřím.