Vlákno názorů k článku
Bezpečné přihlašování uživatelů

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.

Ne tak docela. Hesla muzes mit klidne hashovana trikrat, ale plati ze na overeni challenge-response tohoto typu klientovy staci vedet co mas v databazi (muzes mit v databazi hash hesla a na klientovy pocitat response z hesla tak, ze nejdriv udelas hash - ale pak uz nemuzes overit, ze klient skutecne mel to heslo a ne jen ten hash, ktery mohl ziskat napriklad ukradenim databaze).

Challenge-response tohoto typu proste zvysi bezpecnost proti odposlouchavani a snizi bezpecnost proti ukradeni databaze.

Jedina spravna cesta pro challenge-response (ktera ma vyhody obou) je asymetricka kryptografie. Jenze obavam se, ze RSA v javascriptu nespocitas ... a i kdyby, pouzit na to SSL je vyhodnejsi. (SSL challenge-response je situace, kdy se klient prihlasuje vlastnim certifikatem).

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

RSA v JavaScriptu spocitat lze, viz treba JavaScript Encryption Program (je tam i ukazkove "sifrovatko") nebo Google (?q=…).

Sice to neni zadny fofr, ale na zasifrovani hesla to ujde.

A co takhle?

1. U každého uživatele bude uložen login, challenge a md5(hmac_md5(password, challenge)).
2. Při přihlašování se AJAXem zjistí, jaký challenge uživatel naposledy použil, a pošle se hmac_md5(password, old_challenge) a md5(hmac_md5(password, new_challenge))
3. Na serveru se navíc ověří, jestli md5(old_hmac) souhlasí s tím, co je uloženo v databázi, a pokud ano, přepíše se to novými hodnotami.

Autorem této myšlenky je Paul Jonhston. Přikládám Proof of Concept.

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!

Důležité je uvědomit si, že se neposílá new_hmac, ale md5(new_hmac). Pokud to útočník odposlechne, k ničemu mu to neposlouží, protože k příštímu přihlášení chceme samotný old_hmac. Tedy ta část, kterou nepovažujete za nepodstatnou, je skoro nejpodstatnější.

Nojo, dik za upozorneni. To je ono. Samozrejme by se slo pokusit ten hash cracknout, ale vzhledem k tomu, ze hmac je take md5 z 'neceho', tak by mel mit 128 bitu (16bytu), tudiz dost odolny vuci brute force a prakticky nemozny vuci slovniku. To uz je jednodussi z old_hmac cracknout skutecne heslo, presto, ze se na nej aplikuje MD5 dvakrat. Prefixy $k_ipad a $k_opad se spocitaji ze znalosti old_challenge, takze crackujete pouze heslo a bude to trvat pouze O(1) krat dele, nez kdyby se crackovala obycejna MD5.

Jinak nevidim zas takovou nutnost sahat si pro predchozi challenge AJAXem. Nejedna se o nezavisly kanal, a je akorat zavisly na tom, ze uz potrebuje znat uzivatelske jmeno

Jak jinak získat předchozí challenge, když ne AJAXem nebo podobnou technikou? Tedy pominu-li možnost poslat předchozí challenge všech uživatelů rovnou s formulářem nebo rozdělit přihlášení do dvou kroků.

AJAX je zasadni chyba. za pouzivani berlicek k implementaci funkci(onalit) bych vesel. za koule.

"napr. SHA" :)))