Vlákno názorů k článku Co víme o uniklých heslech z LinkedInu od Pavel Šrubař - Používat login jako salt má výhodu automaticky zajištěné...

Jen doplním, že obecně se nepovažuje za dobrý nápad stavět bezpečnost na utajení algoritmu. Viz http://en.wikipedia.org/wiki/Security_through_obscurity

rasp: samozřejmě, systém by tento předpoklad splňoval + by ale navíc právě systém šifry nebyl útočníkovi znám - nač mu dávat obrovskou výhodu když nemusím?

pletete hrušky s jabkama, ovšem že SBO plus rozumná šifra zabrání převodu zpět do plaintextu a to se počítá když řada služeb je sociální tj vázána na konkrétní osobu == velký problém.

utočník pokud má hesla nebo jejich hashe je v systému na takové úrovni že už nepotřebuje obcházet bezpečnostní mechanismus tj jde čistě o hesla jako taková.

Kez by ...

Viacnásobné hashovanie môže mať teoretickú slabinu – kolízie, cykly – viď http://php.vrana.cz/opakovane-hasovani.php

Osobne viacnásobné hashovanie používam, akurát v tele cyklu k stringu pridávam časť SALT-u, ktorá závisí od hodnoty iterátora.

Princíp skomplikovania algritmu sa mi páči, aj keď to mnohí IMHO nesprávne považujú za security by obscurity. V praxi to môže aplikáciu zachrániť, pretože väčšinou útočník získa hashe cez SQL Injection a na zistenie algoritmu by súčasne musel nabúrať aplikáciu ešte inak aby získal aj zdrojový kód.

http://pastebin.com/WiS9VvGA

Shodou okolností sem se o problematiku šifrování nedávno extenzivně zajímal (o problematiku dešifrování až tak složitě ne).

Ale zaráží mě, že společnost jako Linked s prakticky neomezeným hw si se zašifrováním hesel nepohraje.

Jestli je tu nějaký odborních na lámání šifer, mohl by mi říci jestli je opravdu tak jednoduché "rozlousknout" šifru u které oproti současným předpokladům útočník nezná způsob jejího vytvoření a ve výsedném klíči se nachází třeba 200 znaků "šumu", které znesnadní analýzu lingvistických vzorců?

Myslím to tak, kdyby linked nepoužilo nějakou známou "md5" 100x rozlousklou metodu, ale udělalo si vlastní šifru, kterou útočník nezná šlo by dešifrování takhle rychle? Já o tom totiž mám velké pochybnosti.

Nehrajme si se slovíčky, jestliže se z hashe podaří získat útočníkovi původní heslo - způsob jak vniknout do systému - jako se údajně podařilo jde prostě o zašifrování a ne že ne.

Nemusel tak začínat své podníkání, ale v momentě kdy měl více jak 1M uživatelů mohl zapracovat na zlepšení, jestli ne jde o alibismus.

To, že je to práce pro třeba 5 lidí na půl roku nepochybuju, šlo mi o odpověď na to jestli je opravdu tak snadné podobnou vlastní šifru prolomit např analýznou třeba těch 200-500 šumu a dojít k tomu, že v náhodně generovaném řetězci se občas vyskytne out of order znak.

Podle mě je to v současné době nemožné.

asi jste se problematikou šifrování moc nezabýval..

hesla se nešifrují, ale pouze se spočte jejich hash, většinou se předtím heslo obohatí ještě o nějaký službě specifický salt, aby nebylo možné používat databáze předgenerovaných hashů (tuším se to nazývá rainbow tables, ale nevím)..

vymyslet ale vlastní, silnou a nekolizní (resp. s definovanou a prokazatelnou kolizností) není triviální záležitost a vytvořit takovou hashovací funkci trvá většinou velmi dlouho a pracují na tom odborníci z oblasti šifrování (a matematiky atp.)..

určitě by bylo možné zvýšit bezpečnost hesel tím, že kromě utajení samotných databází hesel by byl utajen i samotný způsob jejich zpracování (hash).. nákladově mi to nedává vůbec smysl, neumím si představit, že by LinkedIn začínal svoje fungování tím, že nejdříve bude několik měsíců/let vyvíjet vlastní hashovací funkci :D tak se opravdu business nedělá..

jedinou ochranou proti odhalení hesla je jeho slovníková složitost, délka hesla a časová náročnost výpočtu

Dodám ešte to, že k zisťovaniu hashovacieho algoritmu môže pomôcť aj to, že útočník má možnosť vytvoriť si v službe niekoľko účtov a analyzovať získané hashe k svojim účtom. Získa tak X účtov, kde pozná heslo a má k nim hahse.

Já bych jen dodal, že sůl nemusí být ani individuální - stačí, když to bude něco, pro co není vygenerovaná rainbow tabulka. I kdyby útočník sůl znal, neměl by jinou možnost, než si rainbow tabulku vygenerovat hrubou silou - což mu hezkých pár let potrvá. Což je podle mě už samo o sobě poměrně solidní zabezpečení.

Samozřejmě lepší varianta je, když bude mít každý účet jinou sůl (např. přihlašovací jméno) - pak už je útočník úplně bez šance (musel by generovat rainbow pro každého uživatele zvlášť).

Problém bol asi v tom, že algoritmus bol príliš jednoduchý a útočník ho zo získaných odtlačkov zistil. Mohol to spraviť napr. tak, že v databáze hashov vyhľadal odtlačky 1000 najpoužívanejších hesiel. Pri zhode si potvrdil, že odtlačok zodpovedá určitej hashovacej funkcii. Teda ak sa v db našiel hash "5fa339bbbb1e­eaced3b52e54f4­4576aaf0d77d96" a na daný účet sa podarilo prihlásiť heslom "asdfghjkl" je pravdepodobné, že použitý algoritmus je len sha1($password) a bude platiť aj na ostatné účty. Následne sa použije rainbow tabulka pre použitý hashovací alrogitmus a na zvyšok hrubá sila.

Ak by LinkedIn použilo viacnásobné resp. opakované hashovanie (napríklad 10 x sha1) + by bol použitý všeobecný salt (spoločný pre všetky účty) uložený mimo db (áno security by obscuruty - ale častokrát veľmi účinné) + individuálny salt - pre každého usera iný uložený v db, útočník by to mal o dosť ťažšie, pritom technicky by to nevyžadovalo žiadne WH náklady naviac.

Ne opravdu se nejedna o zasifrovani ... hash je v podstate neco jako kontroli soucet tveho hesla .. hash ma nejakou pevnou delku nezavislou na delce hesla .. takze i extremne dlouhe heslo bude mit stejne dlouhy hash ...

Rainbow tables se dela jednoduse. Veme se brute force generator hesel a ke kazdemu heslu se vypocita standartne hash a zapise se k danemu heslu .. postupne se tato tabulka uz roky (mazna desitky let) plni takze nalezeni hesla k danemu hash kodu je potom otazka par sekund (pokud uz je dany hash vypocitany)

Problem hash kodu je ten ze se muze stat to ze ruzne hesla maji stejny hash kod. Nestava se to casto ale ta sance je. Vymysleni hash funkce tak aby sance na stejny hash kod pro ruzna hesla byla co nejmensi nebyla zadna sranda a makalo na tom par fakt panu matematiku a pochybuju ze to dokaze i treba 10 beznych programatoru jenom tak ze srandy ... jen tak neco navrhnout se da ale aby nebyl problem se stejnymi hash kody to uz je jina ...