Hlavní navigace

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

9. 6. 2022

Sdílet

NÚKIB Autor: NÚKIB

Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) zveřejnil druhou verzi dokumentu Minimální požadavky na kryptografické algoritmy [PDF]. Subjekty spadající pod zákon o kybernetické bezpečností je musejí zohlednit za účelem ochrany aktiv informačního a komunikačního systému.

Nově se v dokumentu nacházejí také algoritmy použitelné pro bezpečné ukládání hesel (sekce 4 na straně 7). Mezi schválené algoritmy patří Argon2, Scrypt a PbKDF2 s dostatečnými parametry. K volbě se na Twitteru vyjádřil Michal Špaček, přední český odborník na kybernetickou bezpečnost. Zarazila ho absence hašovacího algoritmu bcrypt, který byl prý vyřazen, protože je postaven na zastaralém algoritmu Blowfish.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 9. 6. 2022 15:08

    Uncaught ReferenceError:

    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.

  • 9. 6. 2022 15:20

    Filip Jirsák

    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í.

  • 9. 6. 2022 15:34

    Uncaught ReferenceError:

    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.

  • 9. 6. 2022 16:59

    Filip Jirsák

    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.

  • 9. 6. 2022 18:05

    mad

    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

  • 10. 6. 2022 13:07

    PQK

    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/

Byl pro vás článek přínosný?