Vlákno názorů k článku Libimseti.cz po hacknutí zvyšuje bezpečnost od Jan Angelovič - Kdyby to bylo nějak implementačně náročné tak neřeknu,...
-
Jan Angelovič (neregistrovaný)Kdyby to bylo nějak implementačně náročné tak neřeknu, ale ono je to NAPROSTO stejně jednoduché na naprogramování.
Při ztrátě hesla prostě pošlete uživateli nově vygenerované heslo nebo rovnou jedinečný odkaz pro zadání hesla nového, to vyjde asi tak na jeden řádek kódu navíc v prvním případě a na dva řádky ve druhém. -
Jeste je tam jeden pozitivni efekt, kdyz se rozhodnete vymenit MD5 za SHA, tak si ho z plain text hesla snadno spocitate. U hesel jednosmerne sifrovanych nezbyva v takovem pripade nez cekat, az se kazdy prihlasi, zachytit poslane heslo, overit ho proti staremu hashi a potom spocitat a ulozit novy.
Ale na libku asi nema smysl skladovat plain text hesla, protoze riziko je prilis velke a schopnost uzivatelu poznat, zda heslo posilaji pres formular, ktery hashuje, nulova. Neco jineho by bylo, kdyby pouzivali nejaky CHAP nebo DIGEST autentizaci. -
Jirka Vejrazka (neregistrovaný)Ach jo, dneska jsem hnidopich kralovsky :(
Ten hash se neda pouzit pro challenge-response? Proc? Kdyz uz ten klient (a ktery klient na beznem webu standardne umi C-R?) umi challenge-response, muze pro vstup stejne dobre pouzit hash z cleartextu jako samotny cleartext. -
Ono by to vyresit slo. Problem bude v tom, ze nebudu moct dany hash osolit. Kdybych totiz poslal ze serveru salt pro ulozeny hash, tak salt prozradim a tim ohrozim cele heslo. A pokud salt ze serveru neposlu, tak ho klient nemuze znat a nedokaze spocitat hash stejny, jaky ma ulozeny server.
Nicmene kdybych rezignoval a to, ze budu hash solit, budu mit na obou stranach ulozenou prostou SHA1 hesla, coz je text, ktery se da do C-R vlozit misto hesla. Jenze soucasne plati, ze ta SHA1 hesla je "snadno" prolomitelna, pokud mam rozumne velkou mnozinu hesel.
Jak by se to chovalo v realnem provozu tezko rict, ale mozna by to jen zbytecne zvysovalo "pocit bezpeci". Lide se prece jen budou chovat odlisne k databazi hesel, kde vedi ze jsou hesla a k databazi hesel, kde si mysli, ze jsou hesla zasifrovana.
Ty neosolene hashe maji jeden problem. Vemte si, ze mate databazi hesel. Prvni co vas zajima (me tedy vzdycky ;-)), ktere heslo je tam nejcastejsi. Tady ziskame nejcasteji se vyskytujici hash u ktereho vime, ze se za nim skryva stejne heslo. Takze ten zacneme louskat jako prvni, jednak takove heslo nam otevre nejvice dalsich kanalu pro utok a jednak takove heslo bude jednoduche. Lide si davaji vzdy jednoducha hesla, takze to nejcastejsi bude soucasne nejsnaze rozlousknutelne. -
davro (neregistrovaný)Obávám se, že si ne zcela rozumíme. Challenge-response funguje takto:
S: posílám ti random
C: ok, má odpověď je O=F(heslo_C,random)
S: kontroluji jestli F(heslo_S, random) = O
Útočník potřebuje znát heslo_S a je mu celkem jedno, jestli heslo_S=MD5(plaintext) nebo heslo_S=plaintext
Nějak moc nechápu, co s tím má dělat solení nebo nesolení. -
Filip Jirsák (neregistrovaný)Digest autentizace v HTTP má dvě soli – jednu pro server a druhou pro spojení. Ta pro server zajistí, že když se někomu podaří ukrást uložený hash z jednoho serveru, nemůže jej použít místo hesla na jiném. Ta druhá pak samozřejmě brání proti odposlechu ze sítě. Přičemž ta první sůl (serverová) je to, co vám prohlížeč zobrazí v dialogu pro zadání hesla (alespoň FF to tak dělá).
Jiná věc je, že drtivá většina implementací je univerzální (i pro Basic autentizaci nebo přihlášení formulářem), takže heslo na serveru stejně ukládá v plaintextu (i když stačí jen hash osoleného hesla). -
Jirka Vejrazka (neregistrovaný)Utocnik jako nekdo kdo posloucha sitovy provoz, nebo utocnik ktery ma pristup k tomu zdrojovemu/cilovemu stroji?
V prvnim pripade by ten hash nesel po siti (jde preci o challenge response, jenom s jinym vstupem), stejne jako by tam neslo originalni heslo.
Ve druhem pripade neresime challenge-response a zase jsme u toho jestli je lepsi ukladat cleartext nebo hash :) -
davro (neregistrovaný)Ano, je to challenge-response, nicméně to heslo tam slouží jako cleartext, nikoliv jako hash, ačkoliv je hashováno.
Ano, útočník nezná původní heslo před hashem, ale to mu může být úplně jedno, protože on si vystačí s tím hashem. Prostě když ukradne MD5(username:realm:password), tak to vyjde nastejno, jako by ukradl username:realm:password. -
Filip Jirsák (neregistrovaný)Nevyjde to nastejno. To heslo nemůže použít na jiném serveru. Že ho může použít na tom zkompromitovaném serveru je celkem jedno – tomu nelze nijak zabránit.
Kdyby teď někdo znovu Libimseti napadl a získal z databáze nesolené hashe, bude muset provozovatel při další vynucené změně hesla kontrolovat, zda uživatel nezadal znova to samé heslo. Kdyby používali hash se solí, stačí změnit sůl a uživatel si klidně může zadat znovu to samé heslo. -
davro (neregistrovaný)Používat na různých serverech stejné heslo je blbost.
To, čemu ty říkáš hash je pro ch-r pouze cleartext (tak jak to chápe kryptografie). Otázka: $1$abcdefgh$irWbblnpmw.5z7wgBnprh0 je hash nebo cleartext heslo?
Změnit to, čemu ty říkáš sůl a je to realm, není možné, protože to by se potom neautentizoval nikdo, protože by měli všichni neplatná hesla. -
Filip Jirsák (neregistrovaný)
Používat na různých serverech stejné heslo je blbost.
Což ale neříká nic o tom, zda se tak děje nebo neděje. Kdyby se tak nedělo, neřeší se přidání soli k heslu v unixech a neřeší se to ani v této diskuzi. Jak ale padlo i v této diskuzi, pro relativně jednoduchá hesla už existují databáze neosolených hashů, takže není potřeba nic louskat, stačí vyhledávat.To, čemu ty říkáš hash je pro ch-r pouze cleartext (tak jak to chápe kryptografie).
Pak ale musí být na serveru cleartext vždy, když se nepoužívá asymetrická kryptografie. Tu můžete dnes na webu rozumně použít jen při HTTPS autentizaci klientským certifikátem. Pochybuju o tom, že generovat žádosti o certifikát a přenášet certifikáty na počítače, které práv+ě používají, je to, co chtějí uživatelé LíbimsetiZměnit to, čemu ty říkáš sůl a je to realm, není možné, protože to by se potom neautentizoval nikdo, protože by měli všichni neplatná hesla.
Stačí jednoduchý trik – starým a novým heslem se přihlašovat na dvě různé adresy. -
davro (neregistrovaný)Pak ale musí být na serveru cleartext vždy, když se nepoužívá asymetrická kryptografie
Ne, používají se ty hashe, a sůl se používá ke zvětšení prostoru, aby případné rainbow tables byly natolik velké, že je získání hesla nerealizovatelné. Pokud se ovšem použije cleartext, tak použitelné kryptografické metody jsou bezpečnější než když se uloží pouze hash.
Stačí jednoduchý trik – starým a novým heslem se přihlašovat na dvě různé adresy.To byl jenom vysvětlení toho, že to, čemu říkáš sůl není sůl ;-)
-
Filip Jirsák (neregistrovaný)
Ne, používají se ty hashe, a sůl se používá ke zvětšení prostoru, aby případné rainbow tables byly natolik velké, že je získání hesla nerealizovatelné. Pokud se ovšem použije cleartext, tak použitelné kryptografické metody jsou bezpečnější než když se uloží pouze hash.
Pokud se nepoužívá asymetrická kryptografie, je vždy to, co je uložené na straně serveru, v roli cleartextu – tedy pokud zjistím, co je na serveru uložené, mohu to použít pro přihlášení. Jediný rozdíl mezi hashem a cleartextem je ten, zda informace získané na serveru můžu použít někde jinde – hesla v otevřeném tvaru ano, hashe ne (pokud je nedokážu snadno – třeba hledáním v tabulce – převést na původní heslo). Použitelné (symetrické) kryptografické metody jsou v obou případech stejné, protože jako „heslo“ do nich vždy vstupuje to, co je uložené na serveru – ať je to otevřené heslo nebo hash.To byl jenom vysvětlení toho, že to, čemu říkáš sůl není sůl
Sůl/salt je cokoliv, co se před hashováním přidá k heslu, aby se zabránilo odhalení hesla tím způsobem, že hash bude stejný jako u jiného hesla, které znám i v otevřeném tvaru. V HTTP digest autentizaci tedy plní roli soli jméno a realm – díky jménu budou mít dva uživatelé na stejném serveru se stejným heslem jiný hash, díky realm budou mít dva uživatelé na různých serverech (s různým realm) se stejným jménem a heslem různý hash. -
davro (neregistrovaný)Použitelné (symetrické) kryptografické metody jsou v obou případech stejné, protože jako „heslo“ do nich vždy vstupuje to, co je uložené na serveru – ať je to otevřené heslo nebo hash.
Tak to si chudáci kryptologové protokoly typu ch-r asi vymýšleli zbytečně, když jsou úplně stejné jako ostatní metody, kde heslo chodí otevřeně po síti...
-
Filip Jirsák (neregistrovaný)Pro protokoly typu ch–r nepotřebujete znát otevřené heslo. To, co do protokolu (při použití symetrické kryptografie) vstupuje na straně serveru je ekvivalent otevřeného hesla pro ten daný server (pro daný realm) – a to nejde žádným způsob změnit. Ale to ještě neznamená, že ten údaj na straně serveru musí být ekvivalentní otevřenému heslu i pro jiné servery – pokud se použije hash se solí, uplatníte ten hash jen na tom jediném serveru.
ČLÁNKY DO MAILU