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).
Odpověď na názor
Odpovídáte na názor k článku Bezpečné přihlašování uživatelů.
Pravidla pro diskutující
Přidáním čtenářského příspěvku do diskusí či fóra souhlasíte s tím, že budete dodržovat následující pravidla. Při jejich hrubém porušení se vystavujete riziku smazání příspěvku, jeho modifikaci, v krajním případě i zablokování přístupu do diskusí.
Redakce ze zásady nezasahuje do čtenářských diskusí a zavazuje se, že nebude mazat ani modifikovat příspěvky, kromě případů, kdy tyto porušují některé z následujících pravidel. V takové situaci je na zvážení redakce, zda příspěvek modifikuje s viditelným upozorněním, či přímo smaže. Redakce nikdy nemaže „nesouhlasné komentáře“ jen proto, že jsou nesouhlasné. Vítáme střet názorů, ale vždy v rámci slušné a kultivované debaty.
Příspěvky nesmí obsahovat:
- Vulgární či hrubé výrazy.
- Urážlivé výroky na adresu druhé osoby či skupiny osob.
- Texty, které mají za cíl jen vyprovokovat emotivní reakci (trolling).
- Rasové útoky či útoky na jakoukoliv jinou menšinu či skupinu obyvatel.
- Komerční nabídky a affiliate odkazy.
- Odkazy na warez, sériová čísla, licenční kódy, pornografii a další nevhodný materiál stejně jako žádosti o poskytnutí tohoto obsahu.
- Prokazatelně protiprávní obsah.
Informace o soukromí: U všech přidaných komentářů provozovatel ukládá IP adresu a hostname odesílatele. U neregistrovaných uživatelů se na webu zobrazuje část hostname, případně IP adresy, neumožňující identifikovat konkrétní počítač.
Povolené značky XHTML: a, br, code, em, li, ol, p, pre, strong, sub, sup, ul
