Vlákno názorů k článku Regulace podle NIS2: Rozdělení telco firem podle množství provozovaných SIM karet z vyhlášek zmizelo od Danny - Staci zkontrolovat dve veci - politikou vynucovanou delku...

Staci zkontrolovat dve veci - politikou vynucovanou delku hesla a politikou vynucovanou periodicitu zmeny. To udelate s papirovym checklistem v ruce. A urad tady neargumentuje bruteforce utoky... ale tim, ze vam muzou hypoteticky ty hashe uniknout. Ze kdyz se neco takoveho opravdu stane a hashe nekudy utecou, tak mate mnohem vetsi prusvih se prehlizi... a pak samozrejme ani ta zmena po 18 mesicich kriticky system rozhodne neochrani.

Chapu to narozdil od nekterych diskuteru tak, ze rec je o tom, japa bude ourad kontrolovat existujici hesla ....

A da se to, treba slovnik/bruteforce na ta kratka. Pokud se najde, ...

Co se tyce kontroly pri zadavani, tak ani to nemusi byt mozne, protoze pokud to ma fungovat spravne, nejaky srv kde je ulozeno, se open heslo nikdy nedovi, k tomu doputuje az nejaky hash. Je to tutiz na nejakem zdrojovem systemu, a ten toho nemusi byt, a v 99% ani neni, schopen.

Musel by existovat nejaky univerzalni jediny povine implementovany system, a ten jaksi neexistuje.

Už jsem se potkal se situací, že pravidla pro hesla byla natolik přísná a komplikovaná, že pro jejich změnu měli uživatelé extra aplikaci, která heslo nejprve validovala proti politikám, a pro jistotu neělo ani změnit heslo po stisku [ctrl]+[alt]+[del]­...
...ale napsat net user nebo passwd fungovalo - jen to obyčejný uživatel prostě neznal, nevěděl nebo nezkusil.
Ne, že by to umožnilo měkká hesla, ale přeci jen to bylo tak o dva řády použitelnější.

Přesně jako v tom vtipu

Zadejte nové heslo:
zelí

Heslo musí obsahovat více než 8 znaků
kyselý zelí

Heslo musí obsahovat alespoň jednu číslici
3 kyselý zelí

Heslo nesmí obsahovat diakritiku
3 kysely zeli

Heslo nesmí obsahovat mezery
3blbykyselyzeli

Heslo musí obsahovat alespoň jedno velké písmeno
3BLBYkyselyzeli

Heslo nesmí obsahovat více velkých písmen jdoucích po sobě
3BlbyKyselyZe­li,DejMiTenBlbej­Pristup

Heslo nesmí obsahovat interpunkci
TakTedJsemSeA­leUzFaktNastval3Blby­KyselyZeliDej­MiTenBlbejPris­tup

Omlouváme se, ale toto heslo už někdo používá. Vymyslete jiné!

prakticky nedá, dokonce se často nedá snadno ani interně zjistit.

Všichni tady mluví o uživatelých, ale tyhle pravidla se budou vztahovat na veškerá hesla, tj. vč. hesel do databází, do switchů (které již s nějakými na štítku příjdou), do trezorů (kde jsou zpravidla číselná a není možné splnit požadavek na složitost), dokonce se to týká i hesel k čipovým vstupním kartičkám. Tady je i problém držet tu historii o změnách, aby se heslo neopakovalo.

Prokazuje se to formálně, tj. jestli je dálka evidována, jaká je průměrná, jak probíhá (a kde kontrola na délku a opakovatelnost). Ten, kdo udělá pravidla a systém a na vynucování se vykašle, nejspíš se to nemusí poznat (dokud nejde k úniku), ten kdo to chce řešit podle pravidel má problémy v jejich nerealizovatel­nosti.

Za klienta jsem se účastnil několika diskuzí, nikam to nevedlo. Klient má asi 2 000 aktivních síťových prvků, kde heslo pro lokální správu může být pouze 20 znaké, nepodařilo se nám vyjednat vyjímku, požadují 22 znaků pro technické účty a změnu po 18 měsících. Problém je, že tohle pravidlo se vztahuje na veškerá použitá hesla vč. tokenů či jiných přístupových údajů, které nemají 2FA.

Stejně tak se to vztahuje i na šifrovací klíče, které jsou součástí různých protokolů pro symetrické šifrování. Z diskuzí mě to připadá, že NÚKIB to zaměňuje. Tam je prostě celá bezpečnost na jejich pravidelné transparentní změně založena (probíhá to ale na pozadí, takže o tom nikdo neví), tady se ale bavíme o hodinách a ne měsících.

Samotne politiky pro hesla se vynucuji pri jejich zadani/zmene, to technicky resitelne je - aneb muzete se i dozvedet, ze heslo mate hustodemonsky krutoprisne. A samozrejme nastaveni takove politiky se kontroluje snadno :-)

při registraci noveho uzivatele

Jedna věc mi vrtá hlavou....: jak se ta délka hesla dá reálně zkontrolovat?
Jasně, můžu mít systém, který běžnému uživateli nedovolí zadat slabé heslo, ale stále je možnost, že to heslo vygeneruji nějak bokem - a pokud to bdělý občan nenahlásí, podle hashe se to pozná stěží.

Papirovy draci litaji o sto sest - ale jen tehdy, pokud je rec o cizich systemech. Jakmile dojde na samotny urad, tak pravidla co on stanovi druhym pro jine zda se uz neplati. Nebo cim nam NUKIB ospravedlni, ze jimi provozovany system nedodrzuje jejich vlastni vyhlasku? :-)

On s tím ale kdysi NIST přišel, pak se to rozporovalo a došli k tomu, že to naopak bezpečnost snižuje (kdo by to byl čekal co?) :-)
Checklisty a papíry to je budoucnost. Už teď vidím samý nesmysl na ntou, který nic neřeší, ale papíroví draci lítají o sto šest.

Je prokazano, ze periodicky vynucovane zmeny hesel bezpecnost nijak nezvysuji a rikaji to i NUKIBu ekvivalentni organizace, jako treba NIST v USA nebo NCSC v Anglii, rika to treba uz i Microsoft, najit toho lze za poslednich nekolik let spoustu. Ale holt nas urad v tomto zastydnul ve stoleti pary a porad si jede tu svou pisnicku a tlaci nesmyslne povinne zmeny, zastarale koncepty. Vubec jim nedochazi, ze tech hesel ma kazdy uzivatel desitky a ze svym pristupem bezpecnost snizuji. A je fuk, ze ta perioda je relativne dlouha.

Jediny motiv tady muze byt fakt, ze podobne blbosti se urednikum snadno kontroluji - vytahnou si svuj checklist a delaji si carky. Kontrolovat do hloubky, jak jsou hesla ulozena je pracnejsi a to se linym urednikum zjevne nechce resit. Coz doklada uz jen "oduvodneni", ze ty hashe hesel muzou uniknout a proto se "pry" musi jednou za cas zmenit. Ale s touhle zcela hloupou logikou radoby-bezpecnostnich expertu by clovek musel menit heslo kazdy tyden...kdy se beztak neresi pricina (spatne ukladani hesel v aplikacich), ale jen hypoteticke nasledky.