Odpověď na názor

Ad 4b. Vetsinou jde o veci publikovane (a mnohdy patentovane :-)). Prislo by mi nefer postavit honorovany clanek na tom, ze neco opisu z literatury.

Zaklad problemu je v tom, ze uzivatele nejde donutit, aby pouzival silne heslo. Pocet bitu, ktere si clovek bezchybne zapamatuje, je silne omezen. Je pravdepodobne, ze vetsina systemu zalozenych na heslech podlehne slovnikovemu utoku.

Kdyz tohle bylo receno, porad jeste je moznost to utocnikovi velmi ztizit. Je velky rozdil, pokud muze otestovat desetitisice hesel za sekundu (z nich pocita jen "rychly" MD5 hash) nebo zda ho donutime hodne pocitat a overeni jednoho hesla trva sekundy. - Dokonce tomu jde i zabranit, pokud pomoci hesla (a i nasledne) podepisujeme jen nahodne stringy nebo pokud pripada v uvahu mnoho hesel.

Takze prvni napad, zalozeny na asymetricke sifre (uvadim ho proto, ze je z me hlavy; ostatni veci budu citovat z literatury :-)): Heslo se pouzije jako seed to dobreho generatoru pseudonahodnych cisel. Pomoci nej vygeneruji standardnim postupem key-pair. Server dostane public key. Prihlasovani vypada tak, ze v klientu do stejneho generatoru zadam heslo (tedy tentyz seed jako puvodne), vygeneruju privatni klic a zasifruju timestamp. Server to rozsifruje ulozenym klicem, overi, ze timestamp je v rozumnem rozsahu (aby nedoslo k replay stare zpravy), konkatenuje timestamp se svym timestampem, zasifruje to ulozenym klicem a posle nazpet. Klient to rozsifruje, overi, ze puvodni timestamp je rovny jeho timestampu a ze timestamp serveru je v rozumnem rozsahu (druha prevence replay). Vezme timestamp serveru, zasifruje jej svym klicem a posle to na server. Server overi, ze to odpovida jeho puvodni zprave a povazuje uzivatele za autentifikovaneho. (Z praktickych duvodu muze byt dobry napad padovat timestamp nebo konkatenaci timestampu nahodnymi bajty.)


Dalsi metody:
1. EKE (popsano v S.M.Bellovin, M.Merrit: Encrypted Data Exchange: Password-Based Protocols Secure Against Dictionary Attack. Proceedings of the 1992 IEEE Computer Society Conferenec on Research in Security and Privacy; viz tez B.Schneier, Applied Cryptography, kapitola 22.5; patentovany algoritmus). Myslenka je v tom, ze se pomoci hesla zasifruje nahodny public klic, odpovidajicim private klicem se sifruje dalsi nahodny klic, a pak si obe strany prokazou, ze tento druhy nahodny klic znaji tak, ze si vymeni zasifrovane nahodne stringy. (Klient posle sifrovany nahodny s1, server desifruje s1 a posle sifrovanou konkatenaci s1 a nahodneho s2, klient desifruje zpravu, overi spravnost s1 a posle zasifrovany s2, server desifruje a overi spravnost s2.) Slovnikovy utok je nemozny, nebot vse je nahodne. - K odstraneni man-in-the-middle se jeden z tech nahodnych klicu nevytvori nahodne, ale Diffie-Hellmanem. Man-in-the-middle si musi s kazdou stranou dohodnout vlastni klic, jinak bude uprostred jen smutne koukat na zasifrovane zpravy (tj. pasivne odposlouchavat). Vzhledem k tomu, ze ten klic si obe strany predavaji ve zprave a ze ke konstrukci zpravy je potreba znat to heslo, ma ten man-in-the-middle smulu.

2. Fortified Key Negotiation (popsano v R.J.Anderson, T.M.A.Lomas: Fortifying Key Negotiation Schemes with Poorly Chosen Passwords. Electronic Letters, v.30, n.13, 23 Jun 1994; viz tez B.Schneier, Applied Cryptography, kapitola 22.6). Myslenka je v tom, ze krome normalni hash funkce se jeste pouzije hash funkce s mnoha kolizemi (takze poslanemu hashi muze odpovidat velmi mnoho hesel. Touto funkci se hashuje neco, co obsahuje puvodni heslo a nahodne Diffie-Hellman-generovany klic. (Diffie-Hellman pripadneho in-the-middle-mana donuti, aby na obe strany pouzival jiny klic a tedy bude odhalen, kdyz si obe strany klic predavaji jako soucast hashe nebo sifry.) Odposlechnuti nestaci (zprave na drate odpovida mnoho moznych hesel) a man-in-the-middle nejde (bez znalosti hesla a vzhledem ke kolizi se nepodari na druhou stranu poslat spravnou zpravu). - Autentifikace pak probehne stejne jako v minulem bode - obe strany si navzajem dokazou, ze umeji zpravu s nahodnymi stringy desifrovat.

3. Schnorr (napr. C.P.Schnorr: Efficient Signature Generation for Smart Cards. Advances in Cryptology - EUROCRYPT, '88 Proceesings; viz tez B.Schneier, kapitola 21.3; patentovano). V tomto pripade jako private key zvolime hash hesla (pripadne modulo q), dopocteme public key a ten ulozime na serveru. Protokol je challenge-and-response - server posle dost velke nahodne cislo (Shnorr doporucuje 72-bitove cislo), klient posle odpoved a server overi, ze overovaci rovnice odpovedi vychazi. (Odolnost proti slovnikovemu utoku vychazi jen z pomalosti uvedenych vypoctu, podobne jako u mnou navrhovaneho schematu.)



Obecne ale myslim, ze utocnik pujde nejakou jinou cestou. Napriklad ze nabouchne prohlizec, ktery provadi ty javascripty, a ziska heslo tam odtud. Ale to uz je jina pohadka :-)