Vlákno názorů k článku Kladivo na francouzské uživatele: Pozor, nebezpečí úrazu! od Bilbo - No on je for hlavne v tom, ze...
-
Bilbo (neregistrovaný)
No on je for hlavne v tom, ze tradicni prihlaseni pres browser challenge-response (a ostatne ani tu asymetrickou kryptografii) neumi, takze v praxi je vzdy prvni krok stejny:
klient posle heslo v plaintextu
a pak nasleduje bud:
if heslo=heslo_v_databazi ten prihlas
nebo
if hash(heslo)=hash_v_databazi then prihlas
V druhem pripade je mensi riziko kdyz nekdo celou databazi nejak ukradne, ale po drate putuje v obou pripadech to same (plaintext heslo).
Jsou i vyjimky, weby kdy behem prihlasovani je nejaky javascript co to heslo napr. zahashuje, pripadne muze implementovat i challenge response, ale ty jsou celkem vzacne a obvykle putuje i v pripade hashovani heslo v plaintextu.
-
Bilbo (neregistrovaný)
Jo. Je to v standardu. Klasicka http authentication (kdy se heslo posila v kazdem requestu, u digest sice ne plaintext heslo, ale i tak se dela autorizace v kazdem requestu) ale neni v praxi moc rozsirena.
Mozna zcasti i proto, ze u vesiny browseru se pak nejde odhlasit, nekterym vadi i ze se zobrazuje login okno browseru a ne uzasne nacancane login okno jejich serveru..
V praxi se pak moc HTTP autorizace nepouziva, tak na jedne strance z 30, jinde je vertsinou jen nejaky prihlasovaci formular + session cookies. A heslo prenasene v plaintextu (pokud nepouzivaji SSL)
-
polygon (neregistrovaný)
Ok, a jak se to liší v tom, když si za heslo dosadíte hash(heslo) a za uložené_heslo uložený_hash_hesla? Nemusel byste zbytečně ukládat ty plaintexty... Nehledě na to, že nějak se k vám musely dostat do db. Takže buďto nezabezpečeně, nebo opět ssl.
Stejně je to jen teorie. Uživatelé tohle nevidí. Pro ně je jen ikonka v browseru zabezpečená/nezapezpečená oblast. A když už je SSL spojení navázáno, tak se klidně může posílat i ten plaintext. -
Tady si asi ne úplně rozumíme terminologicky. Pokud použijete protokol výzva-odpověď, tak to, co je uloženo na serveru je vždycky plaintext.
Plaintext a hash jsou prostě jenom zkratky pro jisté chování.
Plaintext - musí být uchován v tajnosti, prozrazení znamená kompromitaci.
hash - může být volně k dispozici, protože neexistuje jednoduchá cesta, jak z hashe přijít k tajemství.
To, že mám řetězec "/sNCH4s2mN9C." vůbec nic neříká o tom, jestli je to plaintext nebo hash neznámého plaintextu. Pouze podle chování v tom kterém algoritmu poznáte, co je to zač, a jestli by to mělo být utajeno, nebo to není nutné.
-
polygon (neregistrovaný)
Tak ještě jednou. Jaký je racionální důvod proč by uživatel nemohl použít svoje heslo, na server přenášet hash(x,hash(heslo)) a na serveru ukládat/ověřovat jenom hash? Je to to o čem hovoříte bez nutnosti ukládání původních hesel. S tím, že si myslím, že je to jen paranoidní teoretizování a platí co jsem psal před tím. SSL+jakákoli autentizace+neukládání plaintextu je zcela ok.
-
kdežto klasická metoda použitá při hashovaném uložení hesla je následující:
Server: pošli jméno a heslo
Klient: posílám jméno a hesloserver: if hash(heslo) == ulozene hashovane heslo then OK, else FAIL
Čili v tomto případě jde heslo po lince a musejí být použita další zabezpečení, aby to heslo na lince nikdo neodposlechnul (SSL, atd.), jak už jsem napsal v prním příspěvku.
-
petr_p (neregistrovaný)
A nebo se obě metody složí, kdy se na server uloží osolený hash, klient provede stejnou operaci a s osoleným hashem se pak nakládá jako s čistým heslem (výzva–odpověď). Smysl hashování v tomto případě je, že i když uživatel má všude stejné heslo, tak k vůli soli to nikdo (server po prvním zahashovaní zapomene) neví.
A kromě toho existují protokoly, které umožňují oboustrannou autentizaci bez dalšího zabezpečení i bez otevřených hesel (SRP).
-
Bilbo (neregistrovaný)
A co asymetricka kryptografie?
Server zna uzivateluv public key (protoze mu ho uzivatel dal pri registraci)
Server posle klientovi nahodny retezec. Klient to zasifruje svym private key. Server to rozsifruje uzivatelovym public key a porovna. Pokud se shoduji, uzivatel je prihlasen. Heslo po drate pri prihlaseni vubec neputuje, jen jeden nahodny chrchel k uzivateli a dalsi nahodny chrchel zpatky :)Heslo nikdo neodposlechne, i kdyz pokud cela komunikace neni sifrovana (napr. SSL), tak utokum man-in-the-middle nic nezabrani (uzivatel se regulerne prihlasi a pak dotycny utocnik proste ukradne spojeni, uzivatele uplne odstrihne a dela si co chce :)
ČLÁNKY DO MAILU