Složitost hesla a jeho zjištění

co dvojite sifrovani? osobne pouzivam v prvni fazi sha512 a pote sha256

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.

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.

imploder
„Pak se útočník podívá do zdrojáku“
jak se mu to povede?

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é

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.

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

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.

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.

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.