Názory k článku LastPass byl podruhé napaden, unikly hashe hesel
Článek je starý, nové názory již nelze přidávat.
-
OMG (neregistrovaný) 193.108.184.---
a vsude platite hotove, protoze kreditka by mohla byt zneuzita... Nekdo ma rad pohodli a pouziva k tomu vhodne nastroje, nekdo povazuje i bankovni ucet za zlo a ma vsechno doma v hotovosti... az do doby kdy ho nekdo nevyloupi, nebo mu neodejde disk, nebo... kazdy clovek ma jine preference, jine mysleni, tudiz vam ten rar extrahujici se nekam do tempu neberu...
-
Honza (neregistrovaný) 217.30.75.---
zaheslovaný rar??? proč ne :-)
ale řekl bych, že vlastní úložistě hesel je již dávno vyřešené pomocí http://keepass.info/
-
Pokud by ty prostory byly stejné, znamenalo by to, že SHA256 mapuje každé z čísel 1 až 2256 na jiné číslo z rozsahu 1 až 2256. Což by samozřejmě platilo i opačně, tedy že ke každému SHA256 hashi existuje právě jedno "zdrojové" číslo v rozsahu od 1 do 2256. Zároveň byste dokázal - pokud byste někdy v budoucnosti měl tabulku všech hashů od 1 do 2256-1 - určit hodnotu SHA256 hashe 2256 bez použití SHA256 funkce. To není zrovna hezké chování na hashovací funkci.
-
Ano, ano, to je pravda. Udělal jsem chybu v tom slově "je stejný". Měl jsem napsat něco v tom stylu, že nevíme, jak je ten prostor pokrytý, takže je (za předpokladu téhle neznalosti) stejně pravděpodobné, že heslem pro AES bude cokoli z prostoru 0-2^256, čili jestli heslo proženu SHAčkem jednou nebo stotisíckrát, tak se tím nijak nezmění moje znalost o tom, co je heslem - pořád to (pro mě jako útočníka) může být cokoli z prostoru 0-2^256. Ve skutečnosti to některé z těch hodnot být nemůžou, čili prohnat heslo SHAčkem víc než jednou vede ke SLABŠÍ bezpečnosti, čili i tak se "hrk" zmýlil, akorát moje zdůvodnění nebylo přesné.
-
Záleží na tom, jak rychle to opakované hashování ten prostor možných kombinací zmenšuje – rád bych to někdy pro ideální hashovací funkci spočítal. Předpokládám, že vzhledem k poměru velikosti výstupní množiny SHA256 (2256) a počtu iterací (v tomto případě 1000) je to na aktuálním dostupném výkonu strojů stále bezpečné. Ale pokud by někdo dostal nápad, že použije nějaký krátký hash a zvýší počet iterací, posouvá se tím ke snížení bezpečnosti.
-
> Záleží na tom, jak rychle to opakované hashování ten prostor možných kombinací zmenšuje – rád bych to někdy pro ideální hashovací funkci spočítal.
To se obecně řešit nedá, ne? Záleží to na tom, kolik bude v té které iteraci kolizí, což by u dobré hashovací funkce mělo být náhodné číslo, ne? Nebo se na to dá vymyslet nějakej fígl - odhad, střední hodnota apod.?
-
frk (neregistrovaný) ---.tor.ninja
Ono se to možná někomu nezdá, ale třeba i s miliardovou iterací PBKDF2 bude mnohem schůdnější hrubě útočit z prostoru možných hesel která lidé zadávají vstupníko okýnka aplikace lastpass, a pokaždé zapbkdf2ovat; než až z prostoru možných hashů.
(Do diskuze, o kolik je menši prostor hashovaných hashů bych se zde raději nepouštěl)
-
frk (neregistrovaný) ---.tor.exit.babylon.network
... znamenalo by to, že SHA256 mapuje každé z čísel 1 až 2^256 na jiné číslo z rozsahu 1 až 2^256. Což by samozřejmě platilo i opačně, tedy že ke každému SHA256 hashi existuje právě jedno "zdrojové" číslo v rozsahu od 1 do 2^256.
Ano, nějak takhle se bude ideální hashovací funkce chovat. Zajímavé, že?
Zároveň byste dokázal - pokud byste někdy v budoucnosti měl tabulku všech hashů od 1 do 2^256-1 - určit hodnotu SHA256 hashe 2^256 bez použití SHA256 funkce. To není zrovna hezké chování na hashovací funkci.
Tak si to zkuste. Kdybyste chtěl každou takovou hodnotu "nakreslit" na jeden atom, tak vám k tomu nebude stačit vesmír..
-
frk (neregistrovaný) ---.gtor.org
Nejprve si opravím chybu - platí to, až na to zpětné mapování - zamozřejmě neexistuje právě jedno zdrojové číslo (dokument), ale je jich nekonečně mnoho (nesprávně jsem použil citaci pana F.J., který porovnával velikosti prostorů)
A ke kolizím: Každá, i nejideálnější hashovací funkce z principu musí mít kolize. Vtip je v tom, že zároveň ale musí být velmi těžké takové kolize najít.
-
No a to byla právě pointa - prostor hesel (P0) je (dejme tomu) nekonečný, po prvním průchodu hashfunkcí se namapuje na prostor P1, po druhém na P2, po třetím na P3 atd. Zaručeně platí, že |Pn-1| <= |Pn|. Podle mě u dobré hashfunkci se nedá obecně nic říct o tom, co Pn obsahuje - měla by to být náhodná množina, takže i ke zmenšování prostorů by mělo dojít náhodně "někdy". Jedinou jistotou, kterou máme, je, že když k tomu zmenšení dojde, tak už se to nikdy "nedožene", nikdy už ten prostor nenaroste. Takže čistě statisticky se zvyšováním počtu iterací se *nějak* ten prostor zmenšuje. Akorátže útočník stejně neví jak a není schopný to hrubou silou vyzkoušet, takže mu to stejně nedá žádnou informaci, kterou by mohl v útoku využít.
-
Ano, nějak takhle se bude ideální hashovací funkce chovat.
Ne, nebude. Ideální hashovací funkce vrací pro vstupní hodnotu náhodnou hodnotu z oboru výstupních hodnot, přičemž pravděpodobnost výběru kterékoli hodnoty je stejná – takže například nijak nezávisí na tom, zda daná výstupní hodnota je nebo není výstupní hodnotou také pro jiný vstup.Představte si to třeba na hashovacích funkcích, které vrací pouze 0 a 1. Ideální hashovací funkce vrací pro jakoukoli vstupní hodnotu 0 s pravděpodobností 50 % a 1 také s pravděpodobností 50 %. (Ideální hashovací funkce se bude chovat tak, jako by měla nekonečnou paměť a ideální generátor náhodných čísel. Pro každý vstup se nejprve podívá do paměti, zda už pro něj nemá známý výsledek. Pokud ne, náhodným generátorem vybere jeden z možných výstupů a zároveň si ho uloží do paměti.) Mnou popsaná funkce, která pro obor vstupních hodnot shodný s oborem oborem potenciálních výstupních hodnot pokryje všechny možné výstupní hodnoty (tedy např. funkce identita), by tedy pro vstup 0 vrátila výstup např. 0, a tím pádem by pro vstup 1 už zbyla jediná možná hodnota, tedy 1.
Pro ideální hashovací funkci s oborem hodnot 21 tedy platí, že s pravděpodobností 50 % zůstane po jedné iteraci obor hodnot stejný a s pravděpodobností 50 % se zmenší na polovinu.
-
frk (neregistrovaný) ---.puckey.org
Ano, rozumím, v 11:16 jsem se opravil.
Ale jestli sleduji diskusi dobře, tak souhlasíte s tím, že po dalším hashování se obor hodnot už v podstatě nezmenšuje?
Taky jsem se někde setkal s otázkou, co se stane při hashování "do nekonečna".. jestli se vždy dojde ke stejné hodnotě.
Odpověd asi bude že ne, a budou to spíše nějaké cykly, velmi dlouhé.. -
Julin (neregistrovaný) ---.net.upcbroadband.cz
U Keepassu je moznost nastavit si pocet soleni hesla libovolne v nastaveni databaze...
A komu v tom nic nebrani tak muze nastavit treba 100.000.000x coz v praxi znamena zbrzdeni slovnikoveho utoku v radu nekolika sekund na jedno heslo...
Takze jednoduzsi to nebude zcela jiste. -
dizzy (neregistrovaný) ---.212-5-214.telecom.sk
presne tak - keepass pouzivam uz rok k mojej absoultnej spokojnosti. Je multiplatformovy (teda skoro - .net, ale frci bez problemov aj po linuxom).
Hesla si pekne synchronizujem cez cloud a mam ich tak na kazdej pracovnej stanici k dispozicii vsetky a hned ako nejake pridam/zmenimCeresnickou na torte je mrte pluginov (okrem ineho aj doplnanie hesiel pre FireFox aj Chrome).... Zabudni na rar.
-
Nerozumím z čeho vyvozujete, že "pohodlí cloudu ne vždy znamená i bezpečí". Jednak je to nesmysl, protože cloud nemá s bezpečím nic společného.
A druhak ani naopak ten případ nesvědčí nic proti tomu mít data v cloudu.
Unikly prostě data z webové služby. To je všechno. To se stává každý den. Vůbec to nesouvisí s tím jestli je bezpečné mít data v cloudu nebo ne.
Osobně se domnívám, že jakkoliv podobné služby nejsou bez rizika, tak celkově zpřístuňují většímu množství uživatelů než kdyby nebyly.
-
Sinuhet (neregistrovaný) ---.sinuhetcloud.net
Souhlas. Paranoidní uživatel, který si uvědomuje rizika cloudu, se bez něj holt obejde.
BFU má naopak možnost nepoužívat jedno heslo všude, což je výrazně horší, než využít jakéhokoli cloudu. Kritika, že cloud je nebezpečný, je na místě. Ale jak bezpečná jsou ostatní použitelná řešení pro BFU? Keepass taky každý BFU nezvládne, zato každý BFU má několik loginů k různým službám, kam se hlásí heslem.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Souvisi to uplne jednoduse.
1) bezbecnost dat v cmoudu nemuzes jako user absolutne nijak ovlivnit
2) cmoud je daleko zajimavejsi a dosazitelnejsi cil, nez PCcko nejakyho franty vomacky.
3) data (zcela libovolna) v cmoudu se klidne muzou z minuty na minutu stat daty zcela verejnymi - proste provozovatel rozhodne, a ty mas smolika. -
Petr M (neregistrovaný) ---.honeywell.com
Souhlasím. Pohodlí BFU znamená moje bezpečí.
Kdo by se věnoval hackování jedné malé domácí sítě, aby získal 50 hesel od dvou lidí (na předem neznámým systému s neznámým routerem, v neznámým formátu a v neznámým souboru na HDD), když může při jedné akci dostat databázi hesel od statisíců BFU v dárkovým SQL balení?
Jinak já jsem zamrzl u KeePassX. Synchronizováno v lokální síti pomocí ssh. Nesmí to na HDD s FAT nebo NTFS...
-
Rád bych upozornil, že "hashe hesel" (tedy master passwordů, kterými se uživatelé dostávají ke své databázi hesel) neunikly a uniknout nemohly, neboť je LastPass na svých serverech nemá a nikdy vžádné podobě neměl (protože by to popíralo princip jeho fungování). Má tam jen vaše zakódované databáze, které se dekódují ve vašem počítači pomocí master hesla, které nikdy váš počítač neopustí. Viz citát z LastPass FAQ: "Our policy of never receiving private data that you haven't already locked down with your LastPass master password (which we never receive and will never ask for) radically reduces attack vectors."
Uniklo toto (cituji): "The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised."
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
A to nekdo overil nebo to jen tvrdej?
Mimochodem authentication hashes je hash toho mastrpasswordu. Jinak by nebylo treba nic menit a zaroven by jaksi nebyli schopni rozhodnout, jestli je to ten kterej user.
Nebo snad nekdo chce tvrdit, ze kdyz typnu nejakej username, tak si sosnu zaheslovany data a pak si je muzu klidanko v klidu lokalne lamat? No to potes, to je jeste vetsi pruser.
-
> Nebo snad nekdo chce tvrdit, ze kdyz typnu nejakej username, tak si sosnu zaheslovany data a pak si je muzu klidanko v klidu lokalne lamat? No to potes, to je jeste vetsi pruser.
Ne. Normalne to zjevne nejde a ani ted se to udajne nestalo:
Because encrypted user data was not taken,
Samozrejme v tomhle jim clovek muze jenom verit...
-
Petr M (neregistrovaný) ---.honeywell.com
No, user accounts a user data... Obojí je asi v nějaké databázi. Pokud to běželo v jednom racku, na stejné databází, stejným železe, stejným OS a se stejnýma lidma okolo, je to jako věřit, že se někdo dostal v noci do trezoru, sebral prachy a šperky tam velkoryse nechal. Takže dost těžký.
Pokud se přihlašuju hashem hesla a data dešifruju hashem stejnýho hesla, tak pokud to není posolený, je to jasný. A i ta sůl je limitovaná, kdyby se měnila v čase, nepřihlásí se z několika zařízení.
Navíc je naivní předpokládat, že útočník našel někde v diskusí zmínku o LastPass, řekl si "ok, jdu na to" a ani to nevyzkoušel. Takže má heslo, má login data, má svoje hesla. Pokud to šifrování svých dat rozlomí a je všude stejný algoritmus se stejnou solí, už to jde skoro samo.
-
J (neregistrovaný) ---.sattnet.cz
Ne.
Chci LastPass používat na více strojích. To nutně znamená, že na všech těchto strojích musí být šifrovací klíč. Jelikož ho uživatel nepřenáší na flashce, tak je buďto nějak uložen u LastPass (pochybuju), nebo je nějak odvozen z master hesla.
Zajímá mě, který případ platí, a odpověď na otázku "Jak?". -
J (neregistrovaný) ---.sattnet.cz
To nepopírám, jenže to, že něco vzniklo "zahashováním" neříká nic:
Šifrovací klíč vzniká zahashováním hesla.
Přihlašovací klíč vzniká zahashováním hesla.
Byly ukradeny zahashované přihlašovací klíče, tedy něco, co vzniklo (opakovaným) zahashováním hesla.
Tak se ptám, jestli někdo nenarazil na přesnější popis algoritmů. Já totiž všude vidím jen marketingové sračky. (A reverzit to naneštěstí nemám čas :X) -
Lukas (neregistrovaný) ---.net.upcbroadband.cz
Docela pekne povidani o fungovani LastPass najdete treba tady:
https://media.grc.com/sn/sn-256.mp3
https://www.grc.com/sn/sn-256.htmpotom povidani o tom hacku tady:
https://www.youtube.com/watch?v=ujDAYTXTpaM
Dulezita informace je ze sul pro kazdeho uzivatele je jina a hashe jsou z hesla vytvareny pomoci velkeho poctu iteraci (da se nastavit) Password-Based Key Derivation Function (PBKDF2) s tim ze misto SHA-1 pouzili SHA-256. viz https://helpdesk.lastpass.com/account-settings/general/password-iterations-pbkdf2/
-
- IT Administrátor/ka - Správce sítě
- Frontend developer
- E-Procurement specialista
- Senior DevOps Engineer – SAP SD + ABAP/BSP
- Group Head of IT
- Content specialista B2B/B2C eshop
-
- Digitální technologie pro osobní produktivitu
- Co potřebuje HR specialista vědět o projektovém řízení?
- Microsoft Teams 1: spolupracujte online pomocí chatu
- Knihovny na SharePointu 2: práce s knihovnou dokumentů v Office 2019
- Jak na skečnouting aneb čmárej si (i) na poradě
- Anglické idiomy II
-
- IT Administrátor/ka - Správce sítě
- Frontend developer
- Senior DevOps Engineer - Webmethods/Linux
- Senior DevOps Engineer - SAP CI/ABAP
- E-Procurement specialista
- Content specialista B2B/B2C eshop
-
- Projektové řízení krok za krokem
- Digitální technologie pro osobní produktivitu
- Microsoft Teams 1: spolupracujte online pomocí chatu
- Jak si pomocí čmárání ulehčit práci
- Knihovny na SharePointu 2: práce s knihovnou dokumentů v Office 2019
- Seznamy na SharePointu 2: vychytávky pro práci s položkami a seznamem
