Názory k článku
Počet iterací KDF v Bitwardenu není u některých účtů dostatečný

Sem asi starej nebo pravověrnej, měl jsem tam 50k :-( Nebýt 1000x hledání slunečnic byl by ten reload v pohodě za 20 minut hotove.

Nevím, docela clickbait nadpis, 100k mi přijde v pohodě a i kdyby, tak to zšestinásobení je furt podobný řád, oproti tomu přidat znak k heslu má větší vliv i když lidská hesla nemají maximální entropii. I kdyby to byla jen číslice tak to je 10x.

Zajímavější by bylo použít nějakou funkci, která nejde paralelizovat na GPU.

Tak dlouho jsem ten nadpis přepisoval a zkracoval, až teď s odstupem vidím, že to nabralo poněkud zavádějící směr. Moje chyba. Každopádně souhlasím, že kvalitnější heslo s vyšší entropií udělá v mnoha případech víc pro zabezpečení než navyšování iterací.

tohle hodnocení musíš vždy stahovat k tomu jakou má heslo platnost, pokud má platnost rok (tj. každý rok změníš heslo), může být 100k dostatečná hodnota dnes. Pokud ale heslo měníš po 3 letech, 100k interací je nejspíš už na hraně bezpečnosti. I ty doporučení zároveň v druhé větě mluví o počtu let, v jakých to je bezpečné

No s tou změnou hlavního hesla to není tak jednoduché. Budeme-li počítat s podrazem ze strany serveru, může si server ponechat I data zašifrovaná starým heslem. Staré údaje to pak nevyřeší, pokud si uživatel nezmění heslo…

Toto jsou pre-cloud a pre NIST 800-63b uvažování.

Pokud chci lámat heslo, tak to nebudu dělat rok. kde žijte. Teď si zkrátka najmu v cloudu X instancí s nabušenou grafikou (pokud tu šifru GPU zvládne akcelerovat) nebo dostatek nabušených CPU a lámu. Už nejsme v době, kdy bych si na to koupil server a lámal to v nějaké zaplivané serverovně rok... Náklady jsou podobné, ale rychlost prolomení úplně jinde. Takže z pohledu iterací je opravdu jedno jestli měním heslo jednou za 3 měsíce, jednou za rok nebo jednou za 3 roky.

Ta doba na změnu hesla je tam dnes kvůli tomu, aby tam uživatel neměl kopie různých hesel z minulých úniků apod. Její délka musí mít rozumnou délku kolem roku, protože jinak je s tím mnoho zbytečných problémů.

Ten počet iterací je tam zkrátka za tím účelem, aby náklady na lámání byly příliš vysoké než, aby se to někomu vyplatilo zkoušet. Tzn. zvýšení ze 100 000 iterací na 800 000 iterací vám zvyšuje průměrnou cenu prolomení jedné hash osminásobně.

shodný problém je třeba i u lastpass (těm ty trezory dokonce unikly), dělá upgrade interací jen při změně hesla, na to ale neupozorňuje a ani ho v čase nevynucuje, natož aby aspoň uměl přeheshovat vše se starým heslem.

1password dělá přegenerování trezoru při upgradu na vyšší verzi (aspoň jsem to tak pozoroval při aktualizaci z 6 na 7 a z 7 na 8), avšak starý trezor nechává na disku se starou verzí, takže při úniku disku to není takú růžové.

Mohl bych požádat někoho znalého o popis, o co přesně jde? Do budoucna jsem si plánoval nasadit Vaultwarden pro správu hesel a moc se zde nechytám. Děkuji.

Pro symetrické šifrování potřebuješ klíč dlouhý tak jak je dlouhý klíč symetrické šifry, typicky tedy 128 nebo 256 bitů. Ale uživatel zadává heslo. Naivní způsob heslo doplnit nulama (nebo naopak oříznout pokud je delší než 128 bitů = 16 znaků) není moc dobrý protože se lidem líbí když klíče jsou „náhodné“ a přímo do AESu nevstupuje jako klíč něco co má moc nul a opakující se hodnoty.

První věc co se s tím dá udělat je heslo zahashovat a jako klíč použít výsledek.

Standardní kryptografické hashovací funkce jako třeba SHA-256 jsou „rychlé“, takže když někdo dostane zašifrovaný soubor, může hesla hádat podle slovníku nebo i hrubou silou a je to rychlé a snadno paralelizovatelné.

Proto se začalo dělat to, že se hashovací funkce aplikuje hodněkrát po sobě. Například SHA256(SHA256­(SHA256(SHA256(hes­lo)))) (v praxi tam asi bude ještě nějaký mezikrok kdy se výsledek nějak zpracovává). Těch opakování je, třeba v případě ze zprávičky, 100k, 350k, nebo 600k. Abys získal z hesla klíč pro symetrickou šifru a mohl zkusit soubor rozšifrovat (nebo nějak jinak ověřit že heslo bylo správné), musíš tak provést tu „rychlou“ hashovací funkci mnohotisíckrát, a tak si nemůžeš dovolit hesla zkoušet příliš rychle.

Nicméně tyto funkce jako SHA-256 mají ještě jednu „vadu“, stačí jim málo paměti a používají ji tak, že se to snadno paralelizuje na GPU. V praxi je pak zkoušení hesel na GPU o dost rychlejší než „legitimní“ používání na CPU (kde si pak nemůžeme dovolit nastavit víc než třeba milion iterací, protože by pak rozšifrování souboru trvalo hrozně dlouho). Proto existují speciální funkce, například Argon2, což jsou „hashovací funkce“ navržené aby nešly moc dobře počítat paralelně, typicky tak, že potřebují hodně paměti (takže se na GPU nevejde příliš mnoho paralelních instancí) a náhodně do ní přistupují (takže se propustnost paměti zabije na tom že to nejde cachovat).

Mě jenom k tomu napadá: je nějaký důvod PROTI používání těchto "paralelizaci odolných" hashovacích algoritmů? Nebo prostě proč nejsou první volba všech, kdo pracují s PBKDF?

25. 1. 2023, 19:37 editováno autorem komentáře

Důvody jsou asi 3 (možná někdo doplní další)

prvním důvodem který může a nemusí být proti je prověřenost algoritmu, ono totiž potvrdit, že hash je kryptograficky správně a nebude snadné najít kolize popř. hash jako takovou prolomit není zpravidla úplně triviální, a tak se určitou blíže nespecifikovanou dobu po uvedení nové funkce čeká, jestli někdo nepřijde s tím že je to slabé. S čímž zpravidla někdo přijde až po té co to začne část programů používat, protože do té doby nemá smysl se tím zabývat ;)

druhým důvodem je podpora v frameworku/jazyku, který se pro vývoj používá. Programátor si zpravidla toto sám nenapíše, a tak buď jeho framework nebo „spolehlivé“ dostupné knihovny toto obsahují a nebo neobsahují. Sám si to psát nebude a pochybné knihovny také nezvolí, to se prostě u kryptografických funkcí nedělá.

třetím důvodem je výkon, každá ta funkce se iteruje X krát, což při přihlašování "sežere" určitý výkon na mašině, která to dělá. Pokud se to vše dělá na serveru, což je celkem standard pro vzdálená připojení typu RDP, SSH a bohužel často i prohlížeče... tak pokud se vám zároveň má přihlašovat třeba i 500 lidí, tak iterované přihlášení, co sežere třeba i 0,4 s výkonu jednoho jádra může způsobit problém, protože některým lidem pak může trvat přihlášení i desítky sekund a to nemluvím o tom, co to může sežrat paměti a CPU na tom serveru (tady jde hodně o druh funkce, výkon serveru a také o to co tam má běžet krom toho přihlašování - běžně to tolik nevadí).

Já bych ten první důvod nepodceňoval. SHA-[123] jsou výsledkem soutěže NSA, už v rámci výběru se ty algoritmy prověřují. Argon2 je alespoň výsledek komunitní soutěže, takže se mu snad do nějaké míry věřit dá, i když není zdaleka tak prověřená, jako SHA. PBKDF2 je podle mne jenom přidání iterací s vírou „co by se mohlo stát špatného“, mám silné pochybnosti o tom, zda to někdy vůbec někdo kryptograficky seriozně zkoumal.

Třetí důvod pak má zajímavé důsledky v praxi. Pak vám někdo vykládá, jak zjistili, že je to pomalé a uživatelé si stěžují, tak na to mají mašiny v cloudu, které to hashují a škálují je podle počtu uživatelů, kteří se přihlašují. No a proč by to nemohl úplně stejně na víc počítačů v cloudu rozdistribuovat útočník?

Jenom dodam ze bitwarden pouziva pbkdf2 ktery neni GPU resistant.