Názory k článku Co víme o uniklých heslech z LinkedInu

Spis me zarazi, ze firma jako LinkedIn nepouzila saltovani. To mi prijde jako amaterismus nejvetsiho kalibru.

Podobne jako nedavno Sony se svou PSN, kde pro jistotu vse ukladali primo v plaintextu...Hooray

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á.

No, tak na to jsem příliš líný :)

Kez by ...

Draha sranda, v cem je lepsi jak open source keepass, dostupny navic na daleko vice platformách vcetne JME?

Primární ponaučení je neposkytovat svá data na síti kdejakému hejhulovi. Potom se ubráníte zklamání ve víře, že se o ně subjekt xy, nebo yz dokázal postarat. Neznám podmínky "služeb" linkedinu, ale tak nějak bych si tipnul, že tam bude něco v tom smyslu, že linkedin nenese vůbec, ale vůbec žádnou zodpovědnost.... Internet je nebezpečné místo chlapci.

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ášť).

tak nějak bych si tipnul, že tam bude něco v tom smyslu, že linkedin nenese vůbec, ale vůbec žádnou zodpovědnost...

A ty znáš službu, co prohlašuje, že za všechno nese zodpovědnost? Tohle by si do podmínek nedal snad jenom blázen ;-)

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 ...

Ano, na služby, které pro mě subjektivně nejsou příliš důležité, používám jednoduchá hesla. Nemám pak problém si je pamatovat a když to heslo někdo zjistí/uhodne, tak ať si to užije - a to klidně i na všech ostatních službách, kde ho taky používám :)