Narušení bezpečnosti LinkedIn

Služba LinkedIn, sociální síť profesionálů, má problém. Nejenom BBC informuje, že se na veřejnost dostala databáze obsahující více než 6 miliónů zahešovaných hesel. LinkedIn potvrdil na síti Twitter, že možné narušení bezpečnosti zkoumá. Doporučit lze změnu hesla.

6.6.2012 18:04 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Xóža Hňabaj]

A ta databáze je ke stažení kde? Že bych provětral GPU :)

[123]

http://www.mediafire.com/?n307hutksjstow3

[Pepe]

torrentz.eu

magnet:?xt=urn:btih:ebfb106193eb7be439fd2f0ac5db8b3ff22ef416&dn=SHA1.txt

[Conyx]

zkousim v tom seznamu vyhledat echo "mojeheslo" | sha1 a neni tam... nejake napady?

[David Jaša]

sůl?

[Käyttäjä 11133]

Hesla AFAIK nejsou saltované, minimálně jeden člověk potvrdil, že našel čistý hash (bez soli) svého hesla v souboru.

[knizmi]

Teď už stačí, aby si někdo sednul k tvému počítači, projel pár posledních příkazů z terminálu a žádné heslo louskat nemusí

[xkucf03]

Třeba zadal:

 echo "mojeheslo" | sha1

místo

echo "mojeheslo" | sha1

[michich]

echo -n ?

[jano]

skus echo -n "mojeheslo" |sha1sum

[Filip Jirsák]

leakedin.org

[zirapha]

Nehladaj len hash ale aj has s prvymi 5 znakmi nahradenymi nulami. Napriklad hash pre "password" je

5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

Ale v tej databaze je len toto:

000001e4c9b93f3f0682250b6cf8331b7ee68fd8

Ako ktosi napisal na slashdote, hashe ktore crackly nakradili 5 nulami na zaciatku

echo "mojeheslo" | sha1sum
690702b77ddd11867e5c2d391cfa027254f6d9d5  -

Hladaj teda 000002b77ddd11867e5c2d391cfa027254f6d9d5, resp. asi by si mal pouzit echo -n "mojeheslo" | sha1sum

66d30c93619758b4fd14eb88a7c7b9ff1d4c4b6e 
00000c93619758b4fd14eb88a7c7b9ff1d4c4b6e 

[w3432]

jop, tak moje(ci spis nase) tam je taky ;) ^00000....

[zirapha]

Inak nechapem ako tak velka sluzba moze nepouzivat per user salt. To je do neba volajuca amatercina.

[w3432]

heh tak to ja nahodou vim zcela presne ;)

[zirapha]

vazne, preco?

[w3432]

no protoze hlupaci jsou vsude a je jich vetsina ;)

[zirapha]

Aha, a ja som sa tesil ze mas nejake inside-info :D

[xkucf03]

LOL, ale asi nejpravděpodobnější vysvětlení

[Filip Jirsák]

Nedivte se. Žijeme v roce 2012, kdy autentizace HTTP DIGEST je hi-tech výstřelek, který ještě ani není pořádně implementován ve všech prohlížečích, ve většině prohlížečů používá hnusné a špatně použitelné GUI a možnost odhlášení nemá implementovánu žádný prohlížeč. Způsob vytvoření hesla pak není ani nijak standardizován a ani v žádném velkém prohlížeči neexistuji návrh takové implementace. Nejrozšířenější způsob přihlášení je pak HTML formulář, který přenáší při každém přihlášení heslo v otevřeném tvaru, platnost přihlášení se pak ověřuje přes cookie se všemi důsledky jako únosy sezení atd. Zkrátka bezpečnost webu nikoho doopravdy nezajímá.

[pavlix]

A co teprve SCRAM, který má podstatně lepší vlastnosti.

[xkucf03]

Tam ale stačí útočníkovi znát to, co je uložené v DB (tzn. to, co bylo teď ukradeno) a může se k té službě přihlásit, ne?

[Filip Jirsák]

To platí v případě HTTP DIGEST, v případě SCRAM by to právě platit nemělo (aspoň podle deklarovaných vlastností, algoritmus jsem nezkoumal). Ale připadá mi to nepodstatné – pokud už někdo získal to, co je uloženo v databázi nějaké služby, připadá mi to, že se k té službě může přihlásit něčím jménem, jako méně významný detail v porovnání s ostatními průšvihy – třeba s tím, že spolu s databází hesel má nejspíš i celý zbytek databáze s ostatními údaji.

[pavlix]

Co takhle si o tom něco přečíst? Tím nechci prudit, SCRAM je relativně zajímavý a jde hodně do limitů toho, co přihlašování heslem umí :).

[xkucf03]

1. Sorry, Google nefungoval (to není tvoje chyba), na „SCRAM“ to nic pořádného nenašlo, je potřeba to rozepsat a hledat „Salted Challenge Response Authentication Mechanism“. Takže jsem to nakonec hodil do jednoho pytle s klasickým CRAMem, který znám (tam se taky používá sůl). Ano, dost povrchní rešerše, dostuduji…
2. Byla to otázka, ne konstatování.
3. Z toho, co jsem zatím stihl přečíst:

Sdílený klíč je odvozený z „nonces“ klienta a serveru a klientského „verifieru“ (hash klientského klíče, který je odvozený z hesla). Klient k němu přiXORuje svůj klíč a pošle na server, který si ho zase odXORuje a pak zahashuje a porovná s „verifierem“. A zatím jsem nepřišel na ten trik, který zajistí obě výhody: a) nestačí ukrást databázi ze serveru, abych se přihlásil jako někdo jiný + b) nestačí odposlechnout komunikaci, abych se mohl přihlásit jako někdo jiný.

[pavlix]

Sorry, Google nefungoval (to není tvoje chyba), na „SCRAM“ to nic pořádného nenašlo, je potřeba to rozepsat a hledat „Salted Challenge Response Authentication Mechanism“. Takže jsem to nakonec hodil do jednoho pytle s klasickým CRAMem, který znám (tam se taky používá sůl). Ano, dost povrchní rešerše, dostuduji… Byla to otázka, ne konstatování.

V pohodě, to nebyla výtka, jen dobře míněné doporučení :). Obvykle zadávám „scram password“.

A zatím jsem nepřišel na ten trik, který zajistí obě výhody: a) nestačí ukrást databázi ze serveru, abych se přihlásil jako někdo jiný + b) nestačí odposlechnout komunikaci, abych se mohl přihlásit jako někdo jiný.

Ten protokol není úplně jednoduchý, napoprvé jsem to taky nedal. Nedávno jsem došel osvícení, ale už jsem to zapomněl, jak to funguje, takže tě nechám to znovu zkoušet :).

Jen nezapomeň na to, že je to v podstatě kombinací těch starých technik, takže kombinace ukradení DB a odposlechu už problém je.

[xkucf03]

napoprvé jsem to taky nedal. Nedávno jsem došel osvícení, ale už jsem to zapomněl

Už jsem na to přišel. Někdy pomáhá odejít od počítače a najednou to člověku dojde hned

[mirec]

V konquerore je implementovaný (no ok, uznávam, že som ho musel implementovať sám).

[Šangala]

Nu co, jestli se nepletu, zde je heslo v plaintextu, kdysi o tom byla vášnivá debata…

[pavlix]

Heslo uložené v plaintextu má tu výhodu, že nemusí chodit plaintextem venku. Heslo uložené některým typem hashe je naopak odchytitelné na síti. Tyhle dvě techniky se dají kombinovat a vznikne SCRAM. Na jeho prolomení potřebuješ mít jak databázi, tak přístup k síti. Není to tedy oproti třeba RSA nějaký zázrak, ale pokud by byl široce implementován, měl by pomoci v rozhodnutí, zda posílat plaintext po síti nebo ho mít uložený v DB.

[Šangala]

Heslo uložené v plaintextu má tu výhodu, že nemusí chodit plaintextem venku.
Nerozumím řeči tvého kmene :). Heslo uložené jakkoliv nemusí chodit v plaintextu - to spolu nesouvisí.
Přiznám se, že nevím jak přesně funguje SCRAM, ale reagoval jsem na „inak nechapem ako tak velka sluzba moze nepouzivat per user salt.“, čímž jsem chtěl upozornit, že z tohoto pohledu existuje ještě horší varianta a není daleko.
Osobně „horší“ uložení hesla v DB (nebo jinak centrálně) než hash (alespoň MD5) + per user salt alespoň 8 znaků, považuji za špatný, k vůli těmto únikům, ochraně DB administrátora před sebou samým a lidí co mají jedno heslo na všechno.

[pavlix]

Nerozumím řeči tvého kmene :). Heslo uložené jakkoliv nemusí chodit v plaintextu - to spolu nesouvisí.

Tak prosím popiš protokol pro ověření hesla uloženého ve tvaru HASH(heslo), případně HASH(heslo+sůl), který nebude zahrnovat odesílání hesla (informací dostatečných pro přihlášení) po síti.

Ten protokol samozřejmě nesmí předpokládat žádné další prostředky (typu certifikát serveru) a neměl by ještě ideálně být náchylný na MITM (což Diffie-Hellman je).

Osobně „horší“ uložení hesla v DB (nebo jinak centrálně) než hash (alespoň MD5) + per user salt alespoň 8 znaků, považuji za špatný, k vůli těmto únikům, ochraně DB administrátora před sebou samým a lidí co mají jedno heslo na všechno.

Zase tam, kde se hledí na bezpečnost spojení (IPsec, WPA2), se dnes spíš používá heslo uložené v plaintextu právě kvůli umožnění pokročilejších způsobů autentizace.

Takže mezi heslem v plaintextu a heslem v zahashované podobě neexistuje vztah jednoznačně lepší ani jednoznačně horší. Nicméně jsem chtěl upozornit na to, že SCRAM v oblasti zabezpečení jako takového je v podstatě kombinace obou, takže z hlediska bezpečnosti je lepší než obě dvě varianty.

Pak už máš k dispozici jen metody typu Kerberos, kde používáš heslo lokálně nebo RSA, kde je potřeba mít k dispozici víc dat než jen zapamatovatelné heslo.

[Filip Jirsák]

Tak prosím popiš protokol pro ověření hesla uloženého ve tvaru HASH(heslo), případně HASH(heslo+sůl), který nebude zahrnovat odesílání hesla (informací dostatečných pro přihlášení) po síti.

Heslo a informace potřebné k přihlášení jsou dvě podstatně odlišné věci. Heslo můžete zneužít pro přihlášení do jiné aplikace, pokud uživatel používá na více místech stejná hesla. Pokud bude mít útočník jen hash osoleného hesla, nepřihlásí se s ním nikam jinam. Že se s tímto údajem přihlásí do původní aplikace situaci moc nezhoršuje, protože to nejspíš mohli předtím.

[pavlix]

Pokud ti neni toto zadání dostatečně jasné, tak se klidně ptej.

[Šangala]

Nepopíšu jen jsem napsal, že uložené heslo v plaintextu automaticky neznamená, že tak musí lítat po síti - může být například jakkoliv zašifrované (třeba přes pubkey se saltem). Protokol nenavrhnu nad tím nepřemýšlím, bo nemám problém s tím, že heslo dorazí (v tomto případě na server) v plaintextu (o to ti asi jde) a po cestě šlo bezpečně (https, šifrované a pod.). Riziko, že dojde k jeho odcizení/odchycení na cílovém serveru (třeba při jeho kompromitaci, nebo je to úmyslně zneužito), považuji za mizivé a je to věc důvěry, ale ukradené databáze, zálohy, nebo nějaké SQL injection a výcuc DB, se děje neustále (a bude dít) a jakmile jsou hesla přímo přístupná, jsou okamžitě všechna obsažená hesla použitelná. A taky sám nemám rád když vidím cizí hesla, jen k vůli tomu že se musím podívat do nějaké user tabulky.
A hlavně většina těch případů je tak, že právě heslo letí po sítu v plaintextu a současně je v DB uloženo buď v plaintextu nebo nějak lehce získatelně (jako třeba tady schází základní koření) . Takže se nebavíme o způsobu bezpečné autentifikace (je to stále ten stejný způsob odeslání hesla od klienta na server pro server v čitelné podobě).
Např. u WiFi WPA2 ať si to tak klidně je, to heslo je jen jedno a není cizí…

[pavlix]

bezpečně (https, šifrované a pod.)

Tak ona je otázka jestli HTTPS a/nebo šifrování implikuje bezpečnost. Podle mě ne.

Takže se nebavíme o způsobu bezpečné autentifikace

To mě právě na skalních zastáncích PLAIN autentizace zaráží, že je vůbec nezajímá bezpečnost samotné autentizace. Já vím, že leaknutá DB je ostuda, ale je to jenom jedna strana mince.

[xkucf03]

Tak ona je otázka jestli HTTPS a/nebo šifrování implikuje bezpečnost. Podle mě ne.

V některých případech sice ne, ale v takovou chvíli už v podstatě nemá cenu řešit ostatní věci, protože útočník má přístup k datům a může se vydávat za daného uživatele.

Částečně to lze řešit dvoufaktorovou autentizací, kdy uživatel musí potvrzovat aktivní operace třeba kódem ze smsky, ale úniku informací to nezabrání.

[pavlix]

V některých případech sice ne, ale v takovou chvíli už v podstatě nemá cenu řešit ostatní věci, protože útočník má přístup k datům a může se vydávat za daného uživatele.

To je podle mě chybný úsudek. Stejně jako je chybné považovat šifrování za něco víc než jeden z nástrojů, který při správné kombinaci s dalšími přináší nějakou úroveň zabezpečení.

[xkucf03]

Šifrování (třeba to SSL) neimplikuje bezpečnost, v tom se shodneme. Ale tím předchozím komentářem jsem se snažil říct, že absence šifrování implikuje* nebezpečnost.

*) pokud tedy nepředpokládáš nějaké vyhrazené dráty nebo optické kabely, u kterých máš zajištěné (jak?), že je nikdo nemůže odposlouchávat

[pavlix]

V pořádku.

[Šangala]

Einstein by v originále napsal: "The ping-pong with the words".
Přeloženo do češtiny: „To je pouhá hra se slovy“.

[pavlix]

To by napsal. O tvém předchozím komentáři.

[Adamec]

nejake divne http://cz.linkedin.com/ ... Ja to mam ve spanelstine :)