Názor k článku Bezpečné přihlašování uživatelů od Petr - Djova, teda ted jsem to zmastil vsechno dohromady....

Djova, teda ted jsem to zmastil vsechno dohromady. Pouceni pro priste: Dam si kafe driv, nez budu takhle odpovidat. - Musim si ted odpovedet sam, jinak neusnu :-)

Nejdriv k rozpleteni man-in-the-middle: Normalne se o man-in-the-middle mluvi tehdy, kdyz sifruju a ten uprostred to resifruje. V nasem pripade se samozrejme o nic takoveho jednat nemuze. Samotna komunikace je nezabezpecena proti odposlechu a nezabezpecena proti manipulaci. Po prihlaseni muze teoreticky kdokoliv menit pakety, posilat za me prikazy a tak. Tohle vsechno plyne z rozhodnuti nepouzit SSL. (Obecne: Proti odposlechu je potreba sifrovat a pocatecni key exchange musi vyuzit sdileneho tajemstvi - hesla - aby MiM nemel sanci. Proti manipulaci staci pripojovat nejaky HMAC, zalozeny napriklad na vymenenem klici.)

V nasem pripade se snazime zabezpecit proti nasledujicim utokum:
- slovnikovy utok na heslo
- replay starych paketu
- "triknuti" uzivatele, aby pri zpracovani vhodne zvolene challenge prozradil neco o hesle.

K tomu memu protokolu: 1. Samozrejme tam neni potreba timestamp. Stejne jako v ostatnich protokolech, znalost klice (resp. jedne casti na klientu a druhe casti na serveru) staci posilat nahodne stringy a kontrolovat je. Klient posle s1 sifrovany svym klicem. Server desifruje s1 (nic s nim delat nemuze), pripoji k nemu s2 a zasifruje to svym klicem. Klient desifruje, odsouhlasi s1, zasifruje uz jen s2 a posle to serveru. Server to zkontroluje. Pokud s1 a s2 jsou dostatecne nahodne, replay se nepovede.
2. No a samozrejme neni *nutny* public/private klic. Jde to udelat i symetricky. Vyhoda pouziti public/private je v tom, ze na serveru ulozim jen jeden klic; i v pripade uniku dat ze serveru je utocnik nemuze pouzit na prihlaseni.

K EKE: S tim Diffie-Hellmanem jsem to zmastil neomluvitelne. Nic takoveho potreba neni. Jeste jednou shrnuti: Klient vytvori nahodny public/private par, public klic zasifruje pomoci sveho hesla a posle ho serveru. Server rozsifruje public klic, vygeneruje nahodny symetricky klic a zasifruje ho pomoci public klice a pak jeste pomoci hesla. Klient vse desifruje. Pak si oba stroje navzajem prokazou, ze ten symetricky klic znaji. Utocnik nemuze provest slovnikovy utok, nebot aby mu k necemu byl, musel by nasledne jeste prolomit asymetrickou sifru, aby se k symetrickemu klici dostal (az symetricky klic sifruje neco, kde lze zkouset poznat, zda mam spravny klic).