NÚKIB aktualizoval minimální požadavky na kryptografické algoritmy

Michal v tom vlákně na twitteru má správné poznámky k argonu2 a požadavku na 2GB paměti, běžná to chyba.

Podle mě ale nesprávně hodnotí samotný bcrypt podle matematické složitosti. Hlavní problém bcrypt v praxi je citlivost pouze na prvních 72 bajtů z hesla, zbytek ignoruje (v případě utf-8 znaků to je jen 36 znaků). S využitím pepřování, prehashingu a dalších technik se bcrypt stává nebezpečný a vede to k reálným zranitelnostem.

Bcrypt je i v OWASP Cheat Sheet označen jako spíše neodporučený než doporučený, pro nové systémy dokonce nežádoucí.

Někdy problém s bezpečnostní nemusí být spojen s objektivní slabostí uvnitř algoritmu, ale s nástrahami, které plynou z jeho použití a tím se celá bezpečnost hroutí jako v případě bcryptu.

K tomu bych ještě dodal, že doporučení NÚKIB se vztahuje hlavně na kritickou infrastrukturu, pro ostatní to je jen doporučující zdroj.

citlivost pouze na prvních 72 bajtů z hesla, zbytek ignoruje (v případě utf-8 znaků to je jen 36 znaků)
UTF-8 kóduje znaky do 1 až 4 bajtů, přičemž spodní polovina ASCII se kóduje do 1 bajtu. Takže u běžných hesel platí, že počet znaků = počet bajtů. Víc bajtů na znak by bylo třeba u českých znaků s diakritikou – nemám odvahu takové znaky do hesla dávat.

S využitím pepřování, prehashingu a dalších technik se bcrypt stává nebezpečný a vede to k reálným zranitelnostem.
To je problém, že se vždycky někdo rozhodne samo-domo zvýšit bezpečnost, ale nedohlédne, jaké to má souvislosti. K těmhle pokusům teda řadím i bcrypt…

Někdy problém s bezpečnostní nemusí být spojen s objektivní slabostí uvnitř algoritmu, ale s nástrahami, které plynou z jeho použití a tím se celá bezpečnost hroutí jako v případě bcryptu.
Ukládání hesel je z 90 % o použití, algoritmy jsou ta méně podstatná část. Ostatně kdyby se s hesly zacházelo dostatečně bezpečně, není potřeba je na backendu hashovat vůbec. A naopak kdyby se s nimi zacházelo doopravdy bezpečně, backend se nikdy nemůže dozvědět heslo v otevřeném tvaru nebo jeho ekvivalent a nemusel by řešit žádné hashování.

koukám, že máš pořád potřebu rozporovat každé slovo :).

s UTF-8 máš pravdu. Nejde jen o české znaky, ale např. české banky často používají i cizinci a ti mají často svá hesla v různých jazycích.

Tak solení a pepřování je běžný způsob, který tyhle aplikace automatizují.

Asi není nejlepší volba slova "algoritmus", už bylo použito v článku, tak jsem ho zachoval, v tomhle kontextu to tožit zároveň znamená použít ověřenou implementaci. Samotné hashovací algoritmy nejsou v žádném případě "méně podstatnou částí", ale kritickou části, jen nejsou pro posouzení bezpečnosti dostačující a je nutné řešit celý proces, to správně zmiňuješ.

Právě proto existuje prehashing a tyhle algoritmy s ním počítají, teda až na bcrypt, tomu podle některých zrovna nesvědčí.

Důvod proč se na backendu musí hesla, tokeny hashovat není jen to, že nechceš vidět heslo uživatele, ale zároveň nechceš, aby se dala využít uniklá databáze k přihlašování a tím je mohl kdokoliv okamžitě zneužít. Tohle nezmění ani chystaný Passkey, stejně bude nutné všechny identifikační hesla/tokeny hashovat.

O tom, že mají cizinci hesla v různých jazycích, dost pochybuju. Ale i kdyby to tak bylo, není to 36 znaků, je to 18–72 znaků.

Solení a pepření je v pohodě, mně šlo hlavně o to prehashování, opakované hashování a další vynálezy.

Trvám na tom, že hashování na backendu je jen hack na chybný proces. Ty chyby jsou ovšem v současných standardech a hlavně v implementaci v prohlížečích, takže provozovatelům backendu nic jiného, než to nějak hackovat, nezbývá.

Důvod proč se na backendu musí hesla, tokeny hashovat není jen to, že nechceš vidět heslo uživatele, ale zároveň nechceš, aby se dala využít uniklá databáze k přihlašování a tím je mohl kdokoliv okamžitě zneužít.
Nosíte sovy do Atén. Nic z toho, co jsem napsal, není s tímhle v rozporu – z čehož se dá usoudit, že o tom vím.

Tohle nezmění ani chystaný Passkey, stejně bude nutné všechny identifikační hesla/tokeny hashovat.
To si nemyslím. Passkey je pokud vím založen na kryptografii veřejného klíče.

Siln2 šifrované slabé heslo zůstane slabým heslem, ať se posolí či opepří jak chce.

Přehnané nároky na délku hesla a četnost jeho změny vedouk heslům typu "Ja#na#to#fak­t#seru#jaro#2022"

Spíš by měl NUKIB řešit, jak je možné, že v AD lze pomocí powershell scriptu detekovat, že více účtů používá shodná hesla. Tady se, kmotře Petře, ten vepř už asi úplně přepepřil.

Druhá oblast, kde bych nějakou aktivitu NUKIB očekával, je nebezpečí plynoucí z přílivu IT pracovní síly UA původu. Ta země totiž byla a je na špici nelegálních aktivit z oblasti kyberbezpečnosti, kam se hrabe nějaký HUAWEI

Tak třeba nás ti Ukrajinci něco naučí ... na rozdíl od nás mají zkušenosti s opravdu masivníma a sofistiovanýma útokama. A umí na ně reagovat ...

https://www.theregister.com/2022/06/08/silverados_alperovitch_viasat_attack/