Autor Zpráva
joe
Profil
Teď jsem nakouknul na stránku http://php.vrana.cz/slozitost-hesel.php a rád bych, kdyby mi to někdo trošku vysvětlil, jestli to půjde (záměrně píšu sem, protože tam se na nové komentáře příliš nereaguje) :-)

Na průměrném dnešním počítači trvá vypočtení hašů všech řetězců sestavených z malých písmen o délce 5 znaků pouhých 20 sekund. Zhruba stejně dlouho zabere vypočítání všech hašů sestavených z číslic a malých a velkých písmen o délce 4 znaky. Za jednu sekundu lze tedy v PHP bez jakékoliv optimalizace ověřit kolem půl miliónu hašů.
...
Pro alespoň základní bezpečnost hesla je nutné po uživatelích chtít heslo délky nejméně 7 znaků sestavené z číslic a malých a velkých písmen (jeho odhalení by na jednom počítači trvalo průměrně 40 dní).
- z webu.

Proč píše, že je třeba po uživatelích chtít heslo dlouhé alespoň 7 znaků - pro delší dobu na jeho zjištění, když můžu napsat
$userPassword = "pes";
$password = md5("-KoůÓ5bš°~1" . $userPassword . "@šířc81ABspr@!-)")


Tak přece udělám heslo dost složité nebo ne?
Majkl578
Profil
co dvojite sifrovani? osobne pouzivam v prvni fazi sha512 a pote sha256
imploder
Profil
joe
To je pravda, takhle se heslo "solí" právě aby nebylo dohledatelné v tabulkách. I když kdyby útočníci udělali tabulku hashů pro všechny slova v původní tabulce takhle osolené (museli by ji přegenerovat), tak by jim pak na takové heslo fungovala. Sůl (tj. to, co k tomu přidáváš) prý může být veřejná a může být i konstantní, takže se s touhle možností zřejmě moc nepočítá, že by si s tím někdo dal takovou práci. Vlastně generování tabulky hashů pro všechny kombinace znaků do určité délky zabere stejnou dobu, jako metoda zmíněná v tom článku, tj. brute-force attack. Lepší je logicky mít sůl proměnnou, třeba jako sůl použít jméno uživatele, aby nemohli vygenerovat tabulku obsahující hashe hesel všech uživatelů, ale vždycky jenom jednoho.
imploder
Profil
Majkl578
co dvojite sifrovani? osobne pouzivam v prvni fazi sha512 a pote sha256
Pak se útočník podívá do zdrojáku, zjistí, že to tak máš, a prostě při zkoušení bude šifrovat oběma - tak, jak to děláš ty.
SwimX
Profil
imploder
Pak se útočník podívá do zdrojáku
jak se mu to povede?
joe
Profil
imploder
Jasně, ale když útočník nebude znát salt, pak původní heslo určitě nerozluští. Resp. nějaká šance by tam byla, ale třeba si do té doby uživatel změní heslo :)

Dobré by bylo uložit někde ten salt jako proměnnou v souboru a ten mít úplně někde jinde - pokud to tedy server umožňuje.

Pak se útočník podívá do zdrojáku
Pak si taky rovnou může do zdrojáku napsat, aby mu to všechny hesla posílalo malem jako plain text, když k tomu bude mít oprávnění.

A většinou pokud někdo chcce uživatelovo heslo, tak chce přímo jeho heslo a ne nějaký kolizní řetězec. Takže si nemyslím, že je nutné chtít po uživateli dlouhá hesla, je to na nich.
SwimX
Profil
když se bude solit uživatelským jménem (nebo něčím lepším - náhodným řetězcem ukládaným do db) přidávaným někam (třeba za třetí písmenko hesla - nebo náhodně a místo ukládat do db) - je to sice děsně složitá možná až čuňačina, ale prolomit todle bude asi vcelku nemožné
joe
Profil
SwimX
No já si myslím, hlavně když bude mít třeba tak 8 speciálních znaků...
imploder
Profil
SwimX
Zdrojáky můžou být tajné, ale předpokládal jsem, že nebudou. Obecně pokud se má nějaké šifrování používat, tak nemá být založené na utajení postupu (taková kryptografická zásada). U šifrovacího algoritmu dostupného veřejně je jasné, že se nedá spoléhat na jeho utajení. Podobně když se bude stejná aplikace používat na víc místech a má se nějak šířit.

Taky se dá spoléhat na to, že do databáze se nikdo nepovolaný nedostane ani se nezmocní její zálohy a nezíská z ní tak hesla. Potom můžou být hesla uložená nezašifrovaná. Ty postupy prolamování předpokládají, že se útočník k uloženým heslům v databázi nějak dostane. Jinak by mohl zkoušet leda postupným zkoušením se přihlásit s různými hesly - to by trvalo strašně dlouho a hlavně by se na to přišlo a dostal by ban.
Joker
Profil
Jé, zrovna jsem napsal takový dlouhý příspěvek k tématu v jiném vlákně :-)

Položím dotaz i tady: Víte někdo, jak funguje to vyhledávání kolizí pro MD5? Dá se "spočítat" jen jedna (pořád ta samá) kolize, nebo se dá vyhledávat více kolizí? Dají se vyhledávat i kolize podle nějakých parametrů (třeba kolize začínající/končící nějakým řetězcem, nějaké délky apod.)?

Každopádně podle mě je dostatečný i solený MD5 hash- oproti prostému MD5 to vidím jako dramatické zvýšení bezpečnosti.
1. Útočník musí kromě hashe znát i sůl. Asi spíš malá komplikace (když uvážím, že hash získá nejspíš z databáze, takže nejspíš získá i sůl), ale přesto komplikace.
2. Krom hashe a soli musí útočník znát i způsob, jakým se kombinují. To zjistí leda ve zdrojáku, takže už musí získávat informace nejméně ze dvou různých míst.
3. Vyhledání "jakékoliv" kolize je útočníkovi k ničemu, potřebuje najít kolizi, obsahující konkrétní znaky (sůl) na určitých místech v řetězci (většinou na začátku nebo na konci, ale algoritmus skládání může být i jiný)
imploder
Profil
Joker
3. Vyhledání "jakékoliv" kolize je útočníkovi k ničemu, potřebuje najít kolizi, obsahující konkrétní znaky (sůl) na určitých místech v řetězci (většinou na začátku nebo na konci, ale algoritmus skládání může být i jiný)
To je dobrý nápad - kontrolovat kromě shody hashů i shodu soli, takže heslo musí nejen sedět na daný hash, ale i obsahovat na správných místech používanou sůl.
joe
Profil
Joker
Jak funguje nevím, za půl roku budu chytřejší a pak se ozvu :-)

ad 3. S tím moc nesouhlasim, pokud to bylo bráno tak, že nahlédl už do kódu, pak mu to práci vůbec neztíží, pokud bude hledat kolizní řetězec pro konkrétního uživatele.
srigi
Profil
imploder
Zdrojáky můžou být tajné, ale předpokládal jsem, že nebudou. Obecně pokud se má nějaké šifrování používat, tak nemá být založené na utajení postupu (taková kryptografická zásada). U šifrovacího algoritmu dostupného veřejně je jasné, že se nedá spoléhat na jeho utajení. Podobně když se bude stejná aplikace používat na víc místech a má se nějak šířit.

Joker
Útočník musí kromě hashe znát i sůl. Asi spíš malá komplikace (když uvážím, že hash získá nejspíš z databáze, takže nejspíš získá i sůl), ale přesto komplikace.

Chybna uvaha. Tak ako je chybne si sol ukladat do DB. Sol musi byt ulozena na inom mieste ako v DB! Totizto, ak sa utocnik dostane k obsahu DB (napr. pomocou SQL inj.) a sol je v PHP skripte, nezmoze nic - nema sa ako ku hodnote SALT dostat. Jedine, ze by bola derava aplikacia a on mohom na server nahrat napr. PHP shell. Ale v takom pripade R.I.P. webmaster.
Joker
Profil
imploder
To je dobrý nápad - kontrolovat kromě shody hashů i shodu soli
Shodu soli netřeba samostatně kontrolovat- Kontrola hesla přeci probíhá: Vezmu uživatelův vstup, přidám sůl, udělám MD5 a kouknu, jestli to sedí s databází.
Už samotný ten postup zaručuje, že ta sůl ve vstupním řetězci bude na správném místě ;-)

joe
ad 3. S tím moc nesouhlasim, pokud to bylo bráno tak, že nahlédl už do kódu, pak mu to práci vůbec neztíží, pokud bude hledat kolizní řetězec pro konkrétního uživatele.
Podle mě mu to naopak ztíží práci dost zásadně. A znalost kódu mu vůbec nepomůže.
Vycházím z toho, že najít kolizní řetězec například začínající "qwe" a končící "rty" je daleko složitější, než najít libovolný kolizní řetězec.

Zároveň vycházím z toho, že útočníkovi se nepodařilo narušit samotný kód aplikace (SQL/script injection třeba)- protože pak už nic nepomůže, libovolný bezpečnostní mechanismus může útočník jednoduše vyřadit (například sice nezná heslo, ale prostě vsune do databázového dotazu ověřujícího uživatele ono známé: OR 1=1'--).

srigi
Sol musi byt ulozena na inom mieste ako v DB!
Pak je ale zas jiný problém: bude dost těžké mít pro každého uživatele jinou sůl. A stejná sůl pro všechny zruší jeden pozitivní efekt, o kterém se tu zatím nemluvilo:
Totiž pokud každému uživateli vygeneruju jeho vlastní sůl, nejdou v databázi pak identifikovat uživatelé se stejnými hesly (mají sice stejné heslo, ale různou sůl, takže výsledný hash je různý).
To znemožní útok jiného typu: Útočník zjistí, jak získat údaje z databáze. Založí si pár účtů s "očekávatelnými" hesly (třeba "heslo", "12345" a podobně). V databázi je pak schopný najít uživatele, kteří mají některé z hesel, která použil (mají stejný hash hesla jako nějaký z útočníkových účtů) a jejich účty nabourat.

A i když útočník má heslo i sůl, pořád ještě nemá algoritmus, jakým se to skládá dohromady. Buď si ho tipne, nebo stejně potřebuje nakouknout do kódu.
joe
Profil
Joker
Pokud útočník bude znát ten hash uložený v db pod sloupečkem heslo a dostane se ke skriptu a uvidí sůl a vidí jakým způsobem se zpracovává, pak může provést ten brute force útok stejným způsobem, jako se provádí zahashování hesla a nebude to ničemu platné.

Asi to bylo myšleno jako hledání kolizí, jestli se to dá nějak spočítat to nevím, ale pokud ano, tak jsem kecal :-)

srigi
Asi pravda, jenom tam akorát zabírá zbytečně místo.

Joker
Pak je ale zas jiný problém: bude dost těžké mít pro každého uživatele jinou sůl.
Ten může být třeba pět znaků z toho co vrátí md5($nick)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: