Nikdy jsem tomu nevěřil, svých pár hesel mám v zaheslovaném Raru a v žádném cloudu.
Tak tak řeším to úplně stejně. Hlavní heslo na .RAR a všechno v něm. Samozřejmě kdybych zapomněl heslo do toho RARu, tak jsem v řiti, ale to se snad nestane. :) A BruteForce klidně zkoušet můžou, nemají šanci.
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...
Jeste sem nezazil ze by nekde neslo zaplatit hotove (ostatne ani nemuze - zatim), ale bambilionkrat sem videl zoufalce, ktery nemeli ani vindru a resili, jak neco calnou, kdyz ... nejde elektrika/net/zapomeli pin/...
> a vsude platite hotove, protoze kreditka by mohla byt zneuzita
Ano, samozřejmě. Jsem snad magor abych dobrovolně vytruboval do světa co jsem si kde kdy koupil?
> nebo mu neodejde disk
Ještě štěstí že bylo vynalezeno zálohování.
V raru? Jsi delate srandu. To neni zrovna moc uzivatelsky pohodlne. To si je muzete rovnou vytisknout na papir. Pokud nebude alternativa s rozhranim jako lastpass a multiplatformni, budu pouzivat lastpass.
zaheslovaný rar??? proč ne :-)
ale řekl bych, že vlastní úložistě hesel je již dávno vyřešené pomocí http://keepass.info/
SHA-256 is used as password hash. SHA-256 is a 256-bit cryptographically secure one-way hash function. Your master password is hashed using this algorithm and its output is used as key for the encryption algorithms.
.. tak přeju hodně štěstí s tím keepassem :)
Neříkám, že je to úplně špatné, ale dle z popisu článku v prvním přiblížení vyplývá, že prolomit keepass bude 100000x jednodušší než prolomit lastpass, že?
a kdepak se asi bere ten šifrovací klíč, ha?
No šifruje se hashovaným heslem. Ale z toho nijak neplyne, že když to heslo zahashuju dvakrát, tak je dvakrát těžší tu *šifru* prolomit.
Á, pán je znalec a má nějaké udělátko přímo na tu šifru..
Anebo si s tím chce vyhrát a útočí krubou silou tak, že zkouší celý prostor hashů a ne jen prostor hashů možných hesel. Tak hodně štěstí.
Nikoli, prostor hodnot f <= prostor hodnot g. Dokonce pokud by platila ta rovnost, bylo by to podle mne špatně, protože by sha256 byla do jisté míry předvídatelná.
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é.
Chápu to tedy dobře tak, že více průchodů, v daném případě, sice snižuje celkovou bezpečnost, ale v vzhledem k aktuálnímu dostupnému výkonu strojů (+pár let) může pomoci proti slovníkovým útokům? Anebo neplatí ani to?
Ve své podstatě je to pro ukládání hesel workaround a jsou k dispozici funkce specializované na tenhle účel (kdf), které nejsou jenom iterace "univerzálního" hashe. Bcrypt, scrypt...
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.?
Chtěl jsem to počítat pro ideální hashovací funkci, která pro libovolný vstup vrací náhodný výstup, kdy každá možná výstupní hodnota má stejnou pravděpodobnost. Pravděpodobnost kolize pak jde spočítat podle narozeninového paradoxu.
Jasně, tohle je dobrej fígl, to jsem is neuvědomil. Akorát teda je to čistě idealistický výpočet, který s realitou nemá moc společného ;)
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)
... 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..
> Ano, nějak takhle se bude ideální hashovací funkce chovat.
Ideální možná - pokud si takhle ideál nadefinuju. Každá reálná hashovací funkce má nějaké kolize, čím by mělo být dáno, že by neměly existovat kolize ausgerechnet při vstupu 1-2^256?
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, vidím to podobně. Ale pokud by byla řeč o té PBKDF2, tak tam ten prostor vždy trochu naroste, protože se v každé iteraci solí.
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.
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é..
> Odpověd asi bude že ne, a budou to spíše nějaké cykly, velmi dlouhé..
To by mě teda dost zajímalo, kdo a proč tohle tvrdil. Ne že by to nemohla být pravda, jenom by mě zajímalo, jak k tomuhle dospět - jestli nějakou detailní analýzou konstrukce té konkrétní hashfunkce nebo jak...
Myslím si, že rychlost zmenšování je zanedbatelná vzhledem k tomu, kolik iterací jsme dnes reálně schopni udělat. Ale jak jsem psal jinde, než si to jen tak bůhvíproč myslet, radši bych to spočítal :-)
.. vtip není ve "zvětšování prostoru", ale ve zpomalování.
Poznámka: 100000xsha256 bych zapsal asi spíš jako sha256^(100000)
Jasně, zpomalování je korektní argument (narozdíl od předchozího). Jenom by mě zajímalo, jaké zpomalení to reálně může být proti odhodlanému a movitému útočníkovi. Jestliže jsou k dispozici bitcoinové asicy s výkonem v řádu GHash/s...
Problém je v tom, že to zpomalování zároveň způsobuje zmenšování prostoru. A jde o to, aby to zmenšování prostoru nakonec nemělo větší efekt, než zpomalování.
U Keepasu se ale k tomu souboru nejdriv musite dostat :-)
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.
Taky by mě zajímalo, proč "hodně štěstí".
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/zmenim
Ceresnickou 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.
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.
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.
Naprosto úplně každá generalizace je zlo zloucí, horší než prokletý facehuger instalující ti na počítač Windows 8 with Bing. Stačí ti to tahle?
V tom případě nemáte pravdu.
Výrok všechny generalizace jsou špatné není pravdivý, protože v případě pravdivosti by byl v rozporu sám se sebou.
Ano, opravdu všechny.
p.s.: Důležité dokumenty mám zálohované i na odložto. Nejde o to, kde je to uložené, ale JAK je to uložené.
Jako uživatel můžeš do cloudu nahrávat pouze šifrovaná data.
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."
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...
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.
Mohl by někdo napsat, jak +- ta služba funguje?
Jakože já se k nim přihlašuju hashí hesla, kterou oni mají uloženou v zahashované podobě, a ukládám si u nich hesla k webům zašifrovaná mým heslem?
This is a very simplified explanation to convey the gist of what we do
:) A pry kouknete na technology page, kde jsou jenom marketingovy kecy...
Hezké, díky. :)
Jen nepíšou, jak generují decryption key. :X
AES je symetrická šifra, takže žádný speciální šifrovací a dešifrovací klíč. (De)šifrování probíhá lokálně, takže by se LastPass ke klíči vůbec neměl dostat.
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?".
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)
> Já totiž všude vidím jen marketingové sračky.
Jj. Na to, že je to věc, které by člověk měl teda sakra věřit, tak mi taky pořádnej popis chybí.
Promiň, ale je důvod tomu sakra věřit?
Je to jen další uzavřený systém, který o sobě tvrdí, že je nej cat /dev/uradom. Technický popis žádný, jen kecy pro BFU.
Ale vždyť jsem neřekl, že já tomu věřím. Nepoužívám to. Každý ať si věří čemu chce, to je jeho problém.
Docela pekne povidani o fungovani LastPass najdete treba tady:
https://media.grc.com/sn/sn-256.mp3
https://www.grc.com/sn/sn-256.htm
potom 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/
Před nedávnem vydal Intel open source AV1 enkodér SVT-AV1. Nyní přichází s open source enkodérem SVT-VP9 pro kompresi Google VP9. SVT-VP9 je…
Pokud chcete dnes odkazovat doprostřed webové stránky, musí být na správném místě kotva. Tedy tag obsahující atribut name="kotva" nebo…
Mozilla podobně jako Chrome přidává pro video funkci obraz v obraze (Picture in Picture, PiP), která umožní přehrávat video ve zvláštním okně…
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2019 Internet Info, s.r.o. Všechna práva vyhrazena.