Názory k článku Bezpečné přihlašování uživatelů

Ahoj, článek je OK, jen v něm myslím chybí zmínka o tom, že v případě použití challenge-response mechanismu je třeba zvláštní péči věnovat ochraně databáze, kde jsou uloženy otisky hesel. Při zcizení otisků se může zručnější útočník přihlásit v podstatě jako jakýkoli uživatel - stačí jen trochu poupravit uvedený JavaScript, aby již otisk nehashoval. Bohužel ani C-R tedy není "100% bezpečný"...

Presne tak. Je zajimave, kolik lidi propada tehle iluzi, ze zacnou-li misto hesla pouzivat jeho hash, heslo a potazmo soustavu tim fikane zabezpeci. Jenze z hlediska utocnika se nic nemeni, proste odchyti hash 'hesla' a bude se jim prokazovat stejne, jako by odchytil 'heslo'.

Heslo je tím skutečně zabezpečené. Většina uživatelů používá do různých systémů stejná hesla. Pokud se někdo dostane k databázi hesel jednoho systému, kde jsou jen jejich hashe, nemůže hned hesla použít pro napadeních jiných systémů, kde má daný uživatel účet.

Hesla se v databázi nehashují kvůli tomu, aby bylo těžší celou aplikaci hacknout, ale kvůli tomu, aby následky takového hacku byly pro uživatele menší.

Nějak si nejsem jistý, zda jsem pochopil tento příspěvek. Heslo se samozřejmě odposlechnout dá - pokud se ovšem nepoužije C-R nebo něco podobného. V tom případě se odchytí pouze zahashovaný řetězec, který je samozřejmě již na nic, protože při příštím přihlášení bude zase jiný...

tak tak

> Shrnuti: neni SSL od zacatku do konce => neni bezpecnost.

Nesouhlasim a davam protipriklad: S/KEY

Precejen pustit sniffer je nekdy jednodussi (napr. pokud je na siti hub a ja jsem na spravnem miste) nez provoz modifikovat (pokud mam pristup rovnou na router, neni co resit, ale pokud jsem jen na stejnem segmentu site .. )

Pustit sniffer zvladne i kdejaky script kiddie ze zakladni skoly, dat tam proxy co bude modikfikovat nejaky konkretni javascript uz treba ne ...

Nojo. Ale pokud mam hesla v databazi "bezpecne ulozena" (hashovana), nemuzu pouzivat challenge response... Takze si clovek musi vybrat.

Jinak se v algoritmu pouziva nedavno "prolomena" funkce md5. Je pravdou, ze v tomto pripade jeji zranitelnost AFAIK nevadi, ale stejne by mozna bylo lepsi pouzit neco jineho, napr. SHA.

Cekal jsem ze s tim nekdo vyrukuje. Ano, pak musim na klientovi pri prihlasovani provest stejny hash, jako jsem delal pri ukladani do databaze. Coz ale znamena, ze:

1) Hashovaci funkce je verejna a kdokoli ziska DB, muze podniknout slovnikovy utok (a nedelejme si iluze o odolnosti beznych hesel BFU proti nemu).
2) Staci upravit klienta a misto hesla pouzit hash z DB.

Samorejme, RSA to resi, ale s JS je s ni problem.

Dalsi vec je, pokud je potreba se prihlasovat i pres POP3, IMAP, SMTP atp., kde zadny javascript do klienta nepropasuji ;-)

Dalsi vec je, pokud je potreba se prihlasovat i pres POP3, IMAP, SMTP atp., kde zadny javascript do klienta nepropasuji ;-)

To sice ano, ale vsechny zminene protokoly maji SSL i TLS variantu ... a kazdy slusny hosting (a to uz nemluvim o kazdem slusnem spravci) zabezpecene pripojeni nabizi, pokud ho rovnou nevynucuje.

"muze podniknout slovnikovy utok"

Pokud by bylo klasicke prihlasovani s jmenem a heslam posilanym v plaintextu tak by to mohl udeloat taky .... tenhle pristup pri situaci, kdy dojde k vykradeni databaze, nema oproti posilani v plaintextu zadne nevyhody (ale ani vyhody)

Ja jsem myslel, ze kdyz vykrade zahashovana hesla, tak je sice neuvidi primo, ale muze na ty hashe co ukradl udelat slovnikovy utok a velke mnozstvi hesel prevede do plaintextu. Mame zkusenosti s XChatem ;-)

Napad je to zajimavy, ale take se mi zda, ze ma svoje mouchy, opravte me, jestli se mylim: Uzivatel je autorizovan na zaklade predchozi vyzvy, a old_hmac (ze ktereho se na serveru udela md5, ale to neni zas tak podstatne). Je tu tedy zpet riziko odposlechu, kteremu jsme se snazili zabranit. Dokonce je to jeste horsi, protoze: Pri kazdem odposlechu zjistime ctverici: old_challenge, old_hmac, new_challenge, new_hmac K naslednemu prihlaseni staci dvojice: new_challenge, new_hmac protoze se nas na ni bude system ptat jako na old_challenge. A ted pozor! Server nema k dispozici heslo, algoritmus hmac je pouze na klientu. Pokud ho vynechate a poslete cokoliv, co vypada jako hash, server nema jak overit, ze je to skutecne hmac vaseho hesla a challenge! Muzete tedy poslat ctverici: old_challenge, old_hmac, new_challenge, random_hmac a system vas prihlasi a dokonce prepise hmac na vas nahodny, takze puvodni uzivatel uz se tam nedostane, zatimco utocnik ano a to uplne bez znamlosti hesla!

"napr. SHA" :)))

Kdyz pouziji hmac, tak tim jen presunu bezp. problem smerem na DB - musim chranit i otisky.
Tak kde potrebuji opravdu bezpecnost, tak bud pouzivam postranni kanal a nebo pristupove fraze.
postranni kanal: poslu si overovaci kod treba smskou.... meze se nekladou ;)
pristupova fraze: jako heslo, ale je to napr. minimalne 20 znaku dlouhe a pri prihlasovani se neposila cela fraze, ale jenom nahodne vybrane bity nasledne prevedene do hashe. Kdyz se utocnik dostane ke frazi, tak je samozrejme problem... Ale student ze stredni v prvaku se k ni stejne nedostane ;).

Kdyz bezpecnost, tak postanni kanal. To je muj nazor.

A neni nahodou mechanismus pristupove fraze jenom jina varianta challenge-responze?

Response = F(challenge, passwd)

Vyber bitu, ktere ma klient z hesla vybrat a zahashovat je vlastne challenge, misto hmac_md5 se jen pouzije jina funkce (tj. vyber bitu + nejaky hash).
Zbyva otazka, jestli ten vyber bitu je bezpecnejsi, nez HMAC.

Popravde nevidim zvyseni bezpecnosti vuci challenge-response. Tady se taky nedostava na sit heslo, ale bavime se o tom, ze ke kompromitaci dojde v pripade, ze se utocnik dostane k databazi otisku. Tohle riziko mi pripada stejne, protoze i v pripade passphrase musi byt nekde ulozena cela, aby se mohly vybrat prislusne casti i na serveru a overit platnost.

Me ted jeste napadl jeden bezva kanal, kde se da predavat parametr pro prihlasovaci formular. Neni to nic noveho. Proste obrazek s kodem, ktery user musi opsat. Vyhoda je v tom, ze hacker ho osniffuje, ale musi u toho sedet v realnem case a v realnem case udelat utok rychleji nez se user prihlasi ... to prakticky odboura vetsinu utocniku, kteri by chteli vystavovat desitky hesel na web ;).

To moc postrani kanal neni. Jak bys chtel overit konkretniho uzivatele? Ten postrani kanal znamena, ze SMS se posle na konkretni cislo, ktere ma ten uzivatel zadane na uctu, takze se podle nej pozna, ze prislo na jeho telefon, a ze je to dost pravdepodobne on.

Ve tvem pripade bys dal ten kod kazdemu, kdo vlezl na prihlasovaci formular? Nebo by se k tomu zadavalo heslo? Pak je obrazek k nicemu, jen treba "schovany" challenge, coz neodstranuje zadne bezpecnostni problemy pri prihlasovani.

Nejen hacker u toho musi sedet v realnem case, ale take legitimni uzivatel.
Vedle toho zablokujes vsechny slepce nebo obecne kohokoliv, kdo z jakehokoliv duvodu nevidi grafiku. To uz to tam muzes rovnou hazet ve Flashi...

Co takhle:
- server posle klientovi vyzvu (napr. hashnuty aktualni cas + nejaky salt)
- klient udela hash hesla a tento hash hesla jeste jednou zhasuje s vyzvou
- klient posle serveru vysledny hash

Funkcni oproti odposlechum...

0. Vsimnete si, ze v tomto pripade nemusi server vubec challenge posilat. Klient si muze challenge domyslet (je to aktualni cas). Proc se tedy server obtezuje s jejim generovanim? Pokud chcete challenge ze serveru, at je skutecne nahodna.

1. Naprosto to nechrani proti "grand chessmaster" problemu (on-line man-in-the-middle). U https mam moznost zkontrolovat certifikat druhe strany. Tady nemam nic.

2. Nevim, jestli pouzita funkce now() nema problemy s prechodem z letniho casu na zimni ("zopakuje se hodina", takze jde prehrat hodinu stare zpravy).

3. Obecneji, kazda synchronizace casu na serveru otevira prostor pro replay utok.

4. Kde je ochrana proti slovnikovemu utoku? Napriklad omezeni poctu pokusu za jednotku casu apod.

4b. Kde je ochrana proti slovnikovemu utoku II? Utocnik odposlechne challenge a ji odpovidajici heslo a potom off-line zkusi slovnikovy utok "uhodni heslo, aby z nej a ze znameho challenge vznikl znamy hmac". - Tohle je nesrovnatelne jednodussi nez napadnout nejakou variantu Diffie-Hellmana, kterou se zasifruje kanal jeste drive, nez nejaka autentifikace vubec probiha.

5. Ulozeny MD5 hash hesla je vlastne heslo do systemu. (To, co uzivatel chape jako "heslo", je jen mnemotechnicka pomucka pro vytvoreni skutecneho hesla.) Takze mame v databazi de facto ulozena skutecna hesla. To jsme si pomohli...

6. Zpusob, kdy overeni na serveru nepouzije odeslany challenge, ale challenge obdrzeny od klienta (tj. potencialne pozmeneny) rozhodne nevzbuzuje duveru. Kdyby nic, server by mel overit, ze tento challenge byl skutecne tomuto klientovi odeslan (tato vazba pritom v tabulce chybi!). A mel by overit, ze to neni prilis davny challenge.

7. Kdyz uz jsme u toho, pouziti MD5 take nevzbuzuje uplnou duveru :-) Ne ze by utoky byly prakticke (rychle hledani kolize je porad neco jineho nez invertovani hashe), ale u soudu vas kazdy trochu schopny pravnik roztrha :-)


Rekl bych, ze predevsim #4b je vyznamny duvod, proc bych cloveka s takovouto implementaci vyhnal. Existuji lepsi protokoly, ktere takto napadnout nelze. Jsou mozna implementacne slozitejsi, ale knihovny existuji (a navic clovek to pise jednou a pouziva mockrat).

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 :-)

Nevim presne, o kterych krocich mluvime. Je to ta oboustranna vymena nahodnych stringu (puvodne timestampu)? Ta zajistuje dve veci: Server vidi, ze uzivatel zna klic (protoze dokaze otevrit dlouhou zpravu, z ni vyndat substring a ten opet zasifrovat). Uzivatel vidi, ze server zna klic (a tedy ze nejakemu utocnikovi jen tak neposkytuje "munici" - zasifrovane pakety pro pozdejsi replay attack); pokud server nezna klic, uzivatel uz nic zasifrovaneho neposle.

(Pro timestampy ve skutecnosti je jeden z tech kroku nadbytecny - za predpokladu, ze se muzeme spolehnout na synchronizovane hodiny mezi klientem a serverem.)

Jestli to je to generovani public/private klice z hesla, tak to je ten zdrzujici krok, ktery ma odradit utocnika od slovnikoveho utoku. Pokud trva vygenerovani paru nekolik sekund, kolik hesel za den lze vyzkouset?

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).

ad 0, 2: Challenge neni cas, ale poradove cislo, ten cas je v tabulce jenom proto, aby se dala dobre uklizet.

Ale nejlepsi reseni to neni, da se tim udelat DoS:

Uzivatel A dostane challenge X, uzvatel Z (zaskodnik) dostane X+1, ale zkusi odeslat svuj formular se svym heslem a challenge X, kdyz bude rychlejsi nez A, vymaze radek s challenge X z tabulky "challenges" a uzivatel A se neprihlasi. Kdyz tohle bude uzivatel Z opakovat dostatecne rychle, zabrani urcitemu procentu uzivatelu v prihlaseni. (ne ze se bude porad tupe prihlasovat, ale bude si opakovane nacitat prihlasovaci formular, dokud se mu challenge budou zvetsovat jen o 1, vidi, ze je tam sam, jakmile se mu challenge zvysi vice nez o 1, vi, na jake challenge ma utocit)

Obrana:
A. Limitovat pocet zobrazeni prihlasovaciho formulare na 1 adresu
+ zaroven to brani prilis rychlemu rustu tabulky challenges
- velka firma za http proxy s 1 IP adresu bude mit problem
- Porad jde udelat DDoS :-)

B. misto predikovatelne challenge z auto_incrementu pouzit neco jineho, napr.
$UNIQUE_ID (ovsem neresi nadmerny rust tabulky "challenge"). Pridelenou challenge
si ale misto do databaze muzu ulozit do $_SESSION a mam tim i zajistenu vazbu na browser, kteremu jsem challenge poslal (viz bod 6) a nemusim se starat o udrovani tabulky challenge v rozumnych mezich.

Na tohle (neukládání session na serveru) existuje jednoduchý trik: veškerá data poslat klientovi (např. v cookie) spolu s jejich digitálním podpisem (stačí k datům přidat tajné heslo a výsledek prohnat kvalitní hashovací funkcí). No a když klient pošle data s příštím požadavkem zpět, ověříme na serveru ten digitální podpis a pokud sedí, máme jistotu že jsou data autentická.

Povedená otázka, smekám nad (pod) ní. Škoda, že nemám čas na ní odpovědět.

trocha sváteční ironie ;-)