Vlákno názorů k článku TrueCrypt: profesionální ochrana dat zdarma od Whirlpool - Este by ma zaujimalo preco?
-
Whirlpool je kryptograficky z mého pohledu nejkvalitnější. Ostatní dvě nabízené funkce (RIPEMD-160 a SHA-1) jsou klony třídy MD, která ztratila kredit kvůli snadnému nacházení kolizí. V Truecryptu se hashovaci funkce používají jako jednosměrné funkce pro tvorbu klíče z passwordu. Tady narušení jejich vlastnosti bezkoliznosti není zatím nijak použitelné, protože ta funkce je složitá. Takže je můžete používat, jen to nebude vypadat moc in.
Zcela mimo ještě uvádím perličku, autentizační protokol APOP (Authenticated Post Office Protocol). Člověk si myslí, že nalézání kolizí v následujícím protokolu nemůže nijak pomoci k útoku na password. Omyl, omyl, celý password lze odhalit pomocí kolizí...
Protokol:
Klient (pozaduje na serveru svoje e-maily)
Server mu posila vyzvu (vyzva ma urcita omezeni, ale nemnoho) C
Klient vraci hodnotu MD5(C || password)
Server zkontroluje hodnotu odpovedi, protoze zna klientuv password. Je-li ok, pošle mu maily.
-
Bilbo (neregistrovaný)Tak to by mne zajimalo jak to u toho APOP prohiha.
Nasadi-li se man-in-the-middle, tak pri prvnim (u tupejsich useru mozna az pri druhym nebo tretim) pozmenenym C nebo poslane response se to provali, nebot server odmitne autentizaci.
A pokud odposlechnu nejakou serii Cx, a MD(Cx || pass) tak v tom nevidim zpusob jak vyuzit ty kolize k prolomeni. Teda pokud tam neni nejaky flaw typu ze Cx muze byt jedna z 256 moznych nebo tak neco. -
Ten útok je opravdu MITM jak píšete, jen ho provádí jakoby server (útočník). Uživatel je ten, kdo se snaží server přesvědčit o tom, že je oprávněný, proto možná není nastaveno pravidlo třikrát a dost. Server se prostě ptá uživatele stále, pokud to uživatel típne, tak se k poště nedostane. Pokud to netípne, tak se server stále ptá na odpovědi na svoje výzvy. Po určité době se už neptá, odvodí si password. Není to všem server, ale útočník, který se jako server tváří.
Víte nějaké podrobnosti, jak je to na straně klienta s nastavením - kolik dotazů mu může server poslat, aby se na něj vykašlal? -
Bilbo (neregistrovaný)To priznam se nevim, ale tusil bych ze postovni program to zkusi asi jen jednou a pak zarve ze je spatne heslo (pri klasicke autentizaci taky nema smysl zkouset to same heslo dokola kdyz server napoprve rekl ze je spatne) ... a pak je to na uzivateli, aby si to nejak prebral
Otazkou pak je spis kolikrat uzivatel bude mackat nejake tlacitko na zpusob Reconnect/Retry nez mu dojde ze je tu asi neco spatne ...
Zase na druhou stranu, pokud server odpovi ze heslo je dobre a nabidne uzivateli ke stazeni prazdnou schranku (nebo treba par spamu at to vypada ze tam "neco je" :), tak si toho ze je neco spatne muze dotycny vsimnout pozdeji (pokud ceka na nejaky email a ten ne a ne dorazit, ale pri takovehle netrpelivosti pak muze kontrolovat schranku treba i kazdou minutu, cili vice poslanych challenges a vice prijatych responses)
Na druhou stranu, pokud stahovani mailu bude probihat nejak automaticky (napr. "zkontrolovat kazdych 5 minut novou postu") tak se muze program bez "vedomi" uzivatele pokouset treba kazdych 5 minut o pristup do schranky ...
Kolik challengi je takhle potreba postat a dostat zpet aby se heslo prolomilo? -
Na odhaleni jednoho znaku jakehokoliv passwordu je potreba v prumeru (za maximalne nepriznivych okolnosti) cca 255 vyzev. Obvykle to bude pouze cca 32. Pri utoku se pocita s periodickym automatickym prihlasovanim klienta. Utocnik uprostred dela hloupy server a stale klienta autentizuje. Voli si svoje vyzvy C a uci se z hodnot MD5(C || heslo).
-
PMoravec (neregistrovaný)Dobry den,
neni v pripade MitM utoku problem s prolomenim bezpredmetny? Mam za to, ze v pripade neuspechu APOP (-ERR Unknown command: APOP) E-mailovy klient automaticky zkouset nesifrovane USER/PASS; resp. APOP vubec nepouzije, pokud nenarazi v uvitani od serveru na timestamp, uvedeny mezi <>. Oboji muze falesny prostrednik sam zaridit. Jina situace by samozrejme nastala pri odposlechu periodicke kontroly E-mailu ve schrance.
Jinak by bylo treba pokazde nove spojeni, protoze se pro MD5 pouzije zmineny timestamp z uvitani POP3 serveru vcetne <> a shared secret.
RFC1939 uvadi jako priklad <1896.697170952@dbc.mtview.ca.us>tanstaaf s MD5 c4c9334bac560ecc979e58001b3e22fb.
Otazkou je, zda by podobny utok sel pouzit na CRAM-MD5 nebo novejsi variantu Digest-MD5. -
To uvitani od serveru <..cokoli..> je prave ona challenge C, o ktere se bavime (pro nezainteresovane ctenare - chapu, ze to tak nevypada, kdyz se to jmenuje timestamp). Pokud klient neodpovi MD5(C || password), tak by nemel od serveru postu dostat.
Kdyz se utocnik postavi do role serveru a nepouzije v uvitani vyzvu <....>, co se stane? Posle mu e-mailovy klient svuj password? Jestli ano, tak je tenhle utok opravdu bezpredmetny. -
PMoravec (neregistrovaný)Alespon v Thunderbirdu 2.0, ktery momentalne vyuzivam to tak vypada - kdyz neni vyzadovana uzivatelem zabezpecena autentizace, tak na serveru, ktery challenge (timestamp) poslal, zkousel rovnou APOP a kdyz ne, zkousel primo USER/PASS, coz by melo byt standardni chovani (vyplyva to z RFC, kde se primo pise "A POP3 server which implements the APOP command will include a timestamp in its banner greeting a The POP3 client makes note of this timestamp, and then issues the APOP command). Nevylucuji ale, ze v nekterych klientech je mozno APOP zvolit separatne. Nemam overenu tu variantu, kdy by v hlavicce od serveru challenge byla a APOP by selhal, muzu vyzkouset nasimulovat vhodnym programkem, tvaricim se jako POP3 server. Na druhou stranu utocnikovi staci pozmenit uvitani, aby challenge (timestamp) neobsahovalo. Oproti tomu pri zvolene zabezpecene autentizaci pri selhani AUTH *-MD5 a AUTH NTLM Thunderbird vyhlasi, ze se nemuze zabezpecene na server pripojit a nepokracuje.
-
PMoravec (neregistrovaný)No pri selhani APOP v bezpecne variante (kdyz jsem to ted zkousel ladit pres netcat) to alespon vyhlasi chybu, ze server nepodporuje bezpecnou autentizaci. Ale neobjevil jsem zadnou Ameriku, jiz je to popsano tady, jak jsem prave zjistil:
http://www.securityfocus.com/archive/1/464584/30/0/threaded
A number of POP3 servers support APOP, but most of them require some
special configuration. And it seems like Mozilla attempts to use APOP if
APOP banner is present in server reply and no secure protocol is
configured. So yes, it's used, but mostly as an alternative to
cleartext. Based on last 115000 sessions statistics for ISP's mail
server with CRAM-MD5, APOP and NTLM support, ~7000 mailboxes:
Cleartext: 96,3%
APOP: 2,1%
CRAM-MD5: 1%
NTLM: 0.6%
ČLÁNKY DO MAILU