Únik hesel z databáze Xzone

Český herní obchod Xzone dnes na svém blogu oznámil únik uživatelských jmen, hesel, e-mailů a dalších údajů, který se týká více než poloviny uživatelů obchodu (odhadem 108 000 účtů). Všechna hesla byla vyresetována a zákazníkům během dne dorazí upozornění na jejich změnu. Xzone současně přiznává, že k úniku databáze uživatelských účtů došlo již před více než rokem.

26.10.2016 13:54 | Michal Makovec | Bezpečnostní upozornění

Komentáře

[rubymaster]

Ať jdou někam Nejde jen o heslo, to mám každé jinde, ale osobní údaje tam jsou...

[lol]

U úniku jsou uvedena i hesla uživatelů, která se hackerům zřejmě i přes zašifrování (MD5) povedlo v databázi prolomit

[MP]

haha MD5.

[xm]

To jsou panečku profíci Pokud někdo nechápe ani rozdíl mezi hashováním a šifrováním, nelze očekávat, že by chápal proč použít něco lepšího než MD5

A takové fajnovosti jako použití pořádné KDF (nebo alespoň přidat k tomu heslu salt, i když to už dnes stejně nestačí) nelze očekávat už vůbec

[PetrHL]

Salt by stačit mohl, ale musel by být dlouhý. Pochybuju, že jej mají alespoň 10 znaků .

[xm]

Salt dnes nestačí ani náhodou, když člověk vezme v úvahu rychlost hashování na současných grafických kartách a to že lidé používají v naprosté většině případů slabá hesla. Potřeba je alespoň PBKDF2 s dostatečně velkým počtem iterací (aby doba hashování byla minimálně pár sekund na moderním PC) nebo mnohem lépe Scrypt (ještě lépe pak Argon2, ale to zatím není moc rozšířená KDF).

[Jendа]

Co se na tuhle vědu vykašlat a konečně implementovat do prohlížečů zero-knowledge ověření znalosti hesla? Ty protokoly už existují asi 20 let…

[xm]

No třeba takové augmented EKE pokud vim bylo v US patentované (původní EKE není bezpečné) a patent vypršel až někdy v 2013. A SRP které ten patent obcházelo není bezpečné proti offline útoku. Ostatně nejsem si ani jistý, jestli i to augmented EKE vůbec je. Nebo si měl na mysli něco uplně jiného?

[xm]

Yep, měl jsem pravdu, viz třeba tohle co jsem teď vygooglil:

However the verifier used with SRP is sensible to brute force attacks on the password : If the verifiers are stolen, attackers will be able to recover many password by testing each verifier against dictionary values. There's no way to avoid that and still be able to do the cryptographic calculations needed. So the advantage may not be as big as it seems.

Augmented EKE je IMHO to samé v bledě modrém (a původní EKE vyžadovalo znalost plaitextu hesla i na serveru, takže to je úplně passé).

[xm]

Jinak řečeno - zero-knowledge password proof (respektive obecně PAKE - password-authenticated key agreement) řeší jiný problém, a to sice odchycení hesla útočníkem provádějícím MITM. Ale nijak ti nepomůže proti tomu když někdo hackne server a ukradne databázi, pak je to na podobné úrovni jako by tam ta hesla byla uložená jen hashovaná a brute-force útok na slabá hesla lze stále provést.

[Jendа]

Ale nijak ti nepomůže proti tomu když někdo hackne server a ukradne databázi, pak je to na podobné úrovni jako by tam ta hesla byla uložená jen hashovaná a brute-force útok na slabá hesla lze stále provést.

To nepomůže, ale pomůže to proti tomu, když někdo hackne server a nainstaluje tam něco, co bude hesla logovat. Nebo proti tomu, když sám provozovatel serveru bude zlý a bude hesla logovat. Nebo proti tomu, když provozovatel bude lajdák a použije pro hashování hesel rychlou funkci nebo hesla omylem nebude hashovat vůbec.

However the verifier used with SRP is sensible to brute force attacks on the password : If the verifiers are stolen, attackers will be able to recover many password by testing each verifier against dictionary values. There's no way to avoid that and still be able to do the cryptographic calculations needed. So the advantage may not be as big as it seems.

Tebou jmenované protokoly neznám, ale slovníkování lze řešit solením. Takhle od stolu lze vymyslet třeba protokol, který vygeneruje RSA klíč ze seed=bcrypt(sůl + doména + heslo) a následně použije obyčejné přihlašování certifikátem.

[xm]

Osolení ti pomůže proti rainbow tables, ale proti brute-force útoku s použitím moderních GPU ti moc nepomůže (a to je to o čem se bavíme - většina lidí totiž používá slabá hesla, která se dají brute-force dobře prolomit). Na to je potřeba dobrá KDF (tedy taková která i na moderním GPU potřebuje spoustu času/paměti), tedy zpátky k mému původnímu příspěvku bcrypt není špatná KDF, je lepší než PBKDF2, ale Scrypt nebo Argon2 by byl ještě lepší

Každopádně SRP podle RFC používá SHA1 jako hashovací funkci (byť se tam mluví o možnosti použít jiné), takže pokud by jej implementoval někdo jako Xzone, bezpečnost proti offline brute-force útoku by byla skoro stejná jako když měli hesla jen hashované MD5

Naštěstí použít KDF místo prosté hashovací funkce SRP umožňuje (viz třeba tady), takže řešitelné to je, ale prostě ty kvalitní moderní KDF potřebuješ. Bez ohledu na to jestli použiješ běžný způsob autentikace nebo nějaký protokol založený na zero-knowledge password proof jako je SRP či augmented EKE.

[ast]

SRP lze použít s libovolným hashem. Když už jsme u SRP, tak 1024bit DH není bezpečný vzhledem k precomputaci pouzivaneho prvocisla. Viz Logjam: Diffie-Hellman, discrete logs, the NSA, and you [32c3] https://www.youtube.com/watch?v=TfK5tf3ScR4

[xm]

SRP lze použít s libovolným hashem

Vždyť to jsem nakonci psal, že lze použít místo prostého hashe i libovolnou KDF (v RFC se píše hlavně o SHA1, nicméně nevylučuje jiné funkce).

K tomu DH: SRP vyžaduje, aby byly DH parametry jen 1024 bit dlouhé? Nebo to lze zvolit? Pokud neumožňuje použití delších, tak je to k ničemu...

[ast]

Umožňuje i delší. Standardně definované jsou tyto 1024, 2048, 4096 a 8192. viz RFC5054 od strany 15 (Appendix A. SRP Group Parameters).

Použít však můžeš libovolné "bezpečné prvočíslo". (Neptej se mi jak je deifnovaný, ale dá se to dohledat.) Jediný problém je v tom, že v TLS-SRP (RF5054) je to definované jako konstanty. Pokud však člověk nechce používat TLS, pak je to celkem jedno.

[allstar]

No myslím, že se podpory RFC5054 v prohlížečích jen tak nedočkáme vzhledem k tomu, že certifikáty jsou velký business.

[PetrHL]

Salt 10 znaků by mohl znemožnit použití rainbow tables. Ale jinak je MD5 na hash hesel na nic, to souhlasím. Je prostě příliž rychlý. Na hashování hesel ve webové aplikaci používám bcrypt+salt.

[Michal Makovec]

Až teprve nyní jsem si přečetl článek na iDNES.cz Uniklo 108 tisíc českých e-mailů a hesel. Zřejmě z obchodu XZone. Při psaní zprávičky jsem žil v mylném a naivním přesvědčení, že internetový obchod Xzone publikoval zprávu o úniku uživatelských údajů na svém blogu bez vnějšího podnětu.
Inkriminovaný textový soubor zhirnaya_igrovaya_baza.txt je snadno dohledatelný a obsahuje 108 152 řádků - což samo o sobě zcela jistě není dokladem toho, že jim ukradli pouze půlku databáze ! :( Patnáct minut po půlnoci a příslib uveřejněný ve včerejším blogu - zákazníkům během dne dorazí upozornění na jejich změnu, zůstal v mém případě nenaplněn. Přitom newslettery mi chodí bez problémů. Došel už některému z diskutujících zákazníků e-mail s vysvětlením/doporučením na změnu hesla? Na Xzone jsem měl unikátní heslo, takže žádná velká škoda nevznikla. Slevovovým kuponem na příští nákup si ale moji důvěru určitě zpět nekoupí.

[DaVee]

Od xzone mi do mailu stále nic nedošlo, ale pokud je ten soubor pravý tak mé údaje tam nejsou.... ale před cca čtvrt rokem se mi někdo přihlásil na mail (na který jsem registrovaný u xzone a heslo se dalo sestavit z dat v obchodě) a změnil přístupy na steam, GOG, vybral klíče z humblebundle....

... takže určitě ukradli jen půlku databáze :)

(alespoň konečně vím jak se dostali do mého mailu)

[MP]

Stalo se mi to same uz v unoru. Takze jsem prisel o email ucet (se seznamem se neda domluvit) a ebay. WOT, steam a prekvapive xzone se mi podarilo obnovit. Jak rikas aspon ted vim odkud to prislo.

[GA]

Jen jestli tam vůbec nějaká MD5 byla....

https://blog.richardkapicka.cz/20120831-bezpecnost-dat-podle-xzone

[andrej]

...a to este pan neziadal o zmenu hesla z podvrhnutej adresy odosielatela...

[Matlák]

Podle všeho nebyla. A věřím že to dokonce byl záměr. Už jsem se i setkal s názorem "managera" že je lepší mít hesla v databázi v plaintextu nebo symetricky zašifrovaná a ne zahashovaná, že prý co kdyby chtěl uživatel poslat heslo na e-mail. Na to se těžko něco říká...