Ověřování uživatelů na webu

31.10.2007 17:25 | Přečteno: 1190× | WWW

Tuhle otázku musí řešit čas od času každý tvůrce webu. Kromě hotových řešení vestavěných do CMS nebo lahůdek typu OpenID, Kerberos či LDAP, se můžeme rozhodnout i pro svoji vlastní implementaci. Uživatelská jména a (hlavně) hesla jsou citlivá věc, a proto se budeme zabývat v první řadě bezpečností.

Na co si dát pozor:

• Přenos hesel mezi uživatelem a serverem v čisté podobě
• Uložení hesel v databázi na serveru v otevřeném tvaru
• Ukradení session (relace)

Napsal jsem aplikaci, která se jmenuje BG a je to (velmi) jednoduchý systém na správu chyb/požadavků (něco jako Bugzilla, ale mnohem jednodušší).

Tato aplikace používá pro autentizaci uživatelů metodu výzva-odpověď. Pro praxi je nepoužitelná (skoro nic neumí), ale poslouží jako dobrý příklad této autentizační metody. Vydal jsem ji pod GPL, tak se můžete inspirovat, případně využít i nějakou část kódu.

BG je napsaná v PHP a na straně klienta používá JavaScript (pro počítání hashů). Podrobnější popis a odkaz ke stažení najdete na mých stránkách Frantovo.cz.

       

Komentáře

[Käyttäjä 11133]

No... kdyby si implementoval openID udělal by si IMHO mnohem lépe Kéž by google začal poskytovat openID třeba by to pomohlo rozšíření jednotného přihlašování.

[xkucf03]

Protože OpenID tyto otázky neřeší a pouze jejich řešení přesouvá na "důvěryhodnou" třetí stranu. OpenID má svoje pro a proti, ale je to prostě něco úplně jiného, než popisované řešení. Taky o tom plánuji něco napsat...

[mrzout]

Taky doufám, ale zatím se zdá, že Google prosazuje své GoogleID. V placených GoogleApps je možno ho použít pro jednotné přihlašování i z vlastních aplikací.

[xkucf03]

BTW: OpenID jsem zprovoznil na svých stránkách. Spokojený?

[Käyttäjä 11133]

BTW proč je tady jen taková demoverze?

[Deleted [8409]]

na webu máte chybu, "podořte autora", jinak hezke:)

[xkucf03]

díky, opraveno

[Leoš Literák]

Vyzadovat JS pro prihlaseni mi ve verejne webove aplikaci prijde jako silna podminka.

[xkucf03]

Já vím, proto se asi taky výzva-odpověď nepoužívá tady na Abíčku

Problém téhle první verze je v tom, že uspokojivě funguje pouze ve FF. Stránka je validní a i ta knihovna pro výpočet hashe by měla chodit ve více prohlížečích, ale z nějakého zatím neznámého důvodu se mi to jinde rozchodit nepodařilo. Tipuji, že chyba bude někde v okamžiku, kdy chci pomocí JS nastavit vypočítaný hash zpátky do formulářového pole a odeslat.

Jak moc silná podmínka to je, se dá diskutovat, pokud by to bylo funkční v aktuálních verzích FF, IE, Opery a Konqueroru, tak bych to považoval za použitelné pro praxi, bez ohledu na to, že je tam nějaký JS.

[Leoš Literák]

Nekteri uzivatele jsou paranoici, kteri defaultne maji zakazany veskery javascript. Takze se neda spolehat na to, ze lidi maji FF atd. Ale zalezi to na cilove skupine.

[xkucf03]

Nemáš nějakou statistiku? Blokovat JS na ABC by mne nikdy nenapadlo, blokovat ho obecně taky ne, protože tím by se velká část webu stala nepoužitelným. Blokovat ho pro vybrané stránky má smysl - já mám třeba ještě jeden uživatelský účet a pod ním si spustím FF, pokud musím lézt na nějaké méně seriózní stránky - tam mám zakázané všechno, co jde a ten uživatel, pod kterým to běží, taky nemůže prakticky nic (hlavně nemá přístup k souborům ostatních uživatelů).

[Deleted [8409]]

V dnešní době bez javascriptu pomalu neodešlete ani formulář

Ale teď vážně, zajímalo by mě, kolik lidí tady na abc má vyplý javascript ? Třeba já osobně teď dělám jeden ajaxově založený web a prostě už nepočítám s tím, že by někdo javascript neměl.

[Filip Jirsák]

A co třeba klienti, kteří javascript vůbec neumí? Web není určen jenom pro zobrazování na monitorech PC. Web můžete zobrazovat na kapesním počítači, na mobilu, můžete ho předčítat… Vždy je potřeba vyhodnotit, jak moc je javascript pro danou funkcionalitu potřebný. Pokud je např. za přihlášením schováno jenom zobrazování textových informací, nevidím důvod omezovat funkčnost jen na prohlížeče s javascriptem jenom kvůli přihlášení. Používám proto jednoduché pravidlo – rozhoduje samotný obsah (např. uměleckou fotografii těžko budu prezentovat slepcům, takže tam je oprávněné vyžadovat zobrazení a zobrazení obrázků), přičemž cesta k tomu obsahu by nikdy neměla klást větší nároky, než obsah samotný (tj. pokud obsah má takovou formu, že má význam pro uživatele s hlasovou čtečkou, musí se k němu takový uživatel dostat). Pokud má nějaký uživatel více možností (třeba dobře vidí a má zapnutý javascript), můžu pro něj něco udělat komfortněji – např. se někam dostane na 1 kliknutí, zatímco uživatel bez JS musí kliknout dvakrát. Ale pořád se k cíli musí dostat oba dva.

[Deleted [8409]]

Na mobilním zařízení mají prohlížeče také javascript:)

Ale mi šlo spíš o to, že aplikace (hmm stránka:) ), která využívá ajax je jednodušší na implementaci a přenese méně dat po síti.

[Kvakor]

No, ja treba mam defaultne Javascript vypnuty (pres NoScript) a povoluju ho jen pokud je nezbytny pro funkcnost stranky. Stejne to mam i s cookies a Flashem. Takze doporucuju - neni treba pocitat s tim, ze uzivatel Javascript nema (tedy, pokud zrovna neleze na web treba linksem, jenze my, co tohle delame, vetsinou vime, co tim cinime), ale je treba poctitat s tim, ze ho muze mit vypnuty. Proto je vyhodne udelat nejaky fallback, ktery oznami uzivateli, ze si ma Javascript zapnout. Navic, vyhledavaci roboti take neumi Javascript ...

[Deleted [8409]]

Pokud máte dobrovolně vyplý javascript, tak v tom nevidím problém. Víte, že některé stránky se budou chovat podivně a dokážete si ho v případě potřeby zapnout.

fallback je dobrý nápad, to mě nenapadlo

[Marv-CZ]

A když nemáš uložené heslo, jak chceš implementovat takovou funkci, jako je zaslání zapomenutého hesla mailem?

[zelial]

nijak? heslo se nahradi novym - nahodnym a to se posle tim mailem.

[xkucf03]

Přesně tak. Posílání původních hesel e-mailem je prasárna: jednak tím dáváš najevo, že hesla v DB skladuješ v čisté podobě a jednak ten e-mail může doputovat bůh ví kam. Tohle se prostě nedělá, posílá se rovnou nové heslo. Ale ani to není ideální...

[Josef Kufner]

Takže pokud někomu chci znepřístupnit účet, nechám si poslat jeho heslo?

[Lu-Tze]

Necháš mu poslat jeho heslo. Ale tohle už jsem opravdu viděl, bohužel.

[xkucf03]

Copak jsi se s tím nikdy nesetkal? To by bylo dost hloupé. Běžné je, že platí staré heslo, dokud nepoužiješ nové. Resp. nové je jenom kód, který ti umožní změnit heslo. Problém je v něčem jiném, než že by ti útočník znepřístupní účet: problém je v předpokladu, že k dané e-mailové zprávě se nedostane nikdo jiný, než oprávněný uživatel.

[Filip Jirsák]

problém je v předpokladu, že k dané e-mailové zprávě se nedostane nikdo jiný, než oprávněný uživatel.

Což ale použití kódu pro změnu hesla neřeší. Vzhledem k tomu, že nemáte jinou možnost, jak s dotyčným komunikovat, není ani jiná možnost, jak zapomenuté heslo řešit. Tedy pokud ho nechcete nutit, aby se k vám dostavil osobně s občankou.

[xkucf03]

To ano, kód řeší pouze to, kdyby nám někdo chtěl škodolibě zablokovat účet. Ale jsou i jiná řešení - viz Zapomenutá hesla

[Filip Jirsák]

Kdo z uživatelů ale má šifrovací certifikát? To už může ten certifikát použít rovnou pro přihlášení, a není nutné se zabývat nějakým heslem.

[xkucf03]

Já ho mám (GPG, SSL) Pro přihlašování bych certifikát nepoužíval, protože bych ho musel pořád nosit s sebou, ale jako prostředek pro obnovu zapomenutých hesel bych ho uvítal. IMHO by bylo fajn, kdyby si uživatel mohl do profilu zadat svůj veřejný klíč - nemusel by se s ním přihlašovat a měl by ho jen někde bezpečně uložený a v případě potřeby by ho použil pro obnovu hesla.

[Deleted [8409]]

Má někdo podobné řešení pro django ? Co jsem vyzkoumal tak tam je uložené hash hesla, takže hashování na straně klienta asi nepřichází v úvahu:(

[xkucf03]

Četl jsi to pořádně? Moje aplikace hashuje hesla jak v DB na serveru, tak na straně klienta. O hotovém řešení pro django nevím, ale metoda výzva-odpověď je obecný princip nezávislý na technologii, takže by měl jít implementovat kdekoli.

[Deleted [8409]]

Pokud jsem četl správně, tak je potřeba mít to heslo na serveru v normální podobě ne? Jak bych jinak mohl dělat hash s přisoleného hesla?

V djangu je ve výchozím nastavení heslo uloženo pouze jako přisolený hash, proto jsem se ptal.

[xkucf03]

Ne, na serveru je samozřejmě zahashované a se solí. Abychom mohli použít metodu výzva-odpověď, tak musíme heslo zahashovat (a přisolit) i na straně klienta. Nevýhodu to má v tom, že kdyby někdo ukradl zahashovaná hesla z databáze, mohl by se přihlásit k naší službě (ale ne k jiné, protože tam je sůl). Viz ten odstavec "Buď a nebo" - jde o to, co považujeme za vyšší riziko: jestli nabourání databáze našeho serveru, nebo odposlechnutí někde na síti (nad kterou nemáme kontrolu).

[Deleted [8409]]

já to nějak nechápu

Podívejte, měl jsem za to, že to funguje takto: - na serveru je heslo v textové podobě - pokud se chce klient přihlásit, vygeneruje se náhodná sůl, která se pošle klientovi - klient vypočítá hash hesla se solí a pošle na server, který vše ověří

takto by to podle mě šlo, ale už tady vidím problém, že se musí poslat i sůl, a pokud si někdo odchytí ten hash i sůl tak vlastně vyhrál:)

Už nemusíte reagovat, já si to pořádně pročtu ještě jednou, protože mi pořád něco uniká, jinak díky:)

[Filip Jirsák]

Pokud se použijou dvě soli, je heslo chráněné i při přenosu po síti, i před tím, kdyby někdo heslo získal z databáze a chtěl je zneužít někde jinde (tj. uživatel by používal stejné heslo na více místech).

[xkucf03]

To ano, ale metoda není odolná proti případu, že by útočník ukradl databázi a pak se chtěl přihlásit k naší službě - to by se mu totiž povedlo, protože na straně klienta stačí znát hash hesla. Nicméně i tam mi tato metoda přijde vhodnější - vzhledem k poměru velikosti rizik (ukradení DB vs. odposlechnutí na síti).

[Filip Jirsák]

Pokud někdo získá přístup k databázi, je už celkem jedno, že získá heslo pro přihlášení se do daného systému, protože všechny údaje už stejně mohl získat, navíc měl nejspíš možnost i heslo změnit, případně dokonce upravit aplikaci a dát do ní svůj backdoor. Proti krádeži hesel z databáze vás stejně ochrání jenom asymetrická kryptografie, kdy v databázi bude pouze veřejný klíč.

[xkucf03]

Vždyť o tom se nehádám To riziko je tak malé a ve svých důsledcích nepříliš významné, že se s ním můžeme v klidu smířit, ale přesto je dobré o něm vědět.