Povinná periodicita 18 měsíců pro změnu hesla je navzdory námitce zachována.
Vypořádání se s podněty k NIS2, strana 42 a 43:
Navrhovaná změna:
Vypuštění požadavků na povinné periodické změny hesel v intervalu maximálně 18 měsíců a naopak doplnění požadavku na bezodkladnou změnu hesel při zjištěném bezpečnostním incidentu, tzn. při podezření na kompromitaci nebo přímo zjištěné kompromitaci daného účtu/účtů (ve vyhlášce se řeší pouze částečně u administrátorských účtů, nikoliv však již u účtů uživatelských a účtů technických aktiv).
Podrobnosti:
Tento požadavek explicitně z NIS2 nevyplývá. Odůvodnění vyhlášek se dále odkazuje na dokument NIST SP 800-63B, kde se v sekci 5.1.1.2 přímo explicitně uvádí, že periodická změna hesel by neměla být (SHOULD NOT) vyžadována, pokuď pro toto není explicitní důvod (evidence of compromise). Tento požadavek je z pohledu bezpečnosti překonaný a sám o sobě žádným způsobem vyšší bezpečnost prokazatelně nepřináší, spíše ji v praktické rovině naopak snižuje. Ničím neodůvodněné periodické změny hesel vedou k tomu, že uživatelé si tyto mají problém zapamatovat a často je (i nevhodnými způsoby) zapisují, což je vyšším rizikem než možný únik databáze s následnými offline útoky na ní. Je třeba mít na paměti, že uživatelé dnes nemají jen jedno heslo, musí si jich pamatovat celou řadu a i toto je třeba zohledňovat. Textace vyhlášky navíc umožňuje i kratší intervaly a často jsou kratší intervaly s odkazem na tuto vyhlášku implementovány. K problematice lze dále odkázat například na NCSC (ekvivalentní organizace k NÚKIB ve Velké Británii) - https://www.ncsc.gov.uk/collection/passwords/updating-your-approach – kde se tématu také věnují podrobněji (a rovněž je v duchu NIST SP 800-63B). Změna hesla má být vynucována v odůvodněných případech – tzn. při zjištěných kybernetických incidentech, kdy ke kompromitaci účtu skutečně došlo a nebo kdy na toto existuje důvodné podezření – tomuto se naopak vyhláška nevěnuje vůbec. Požadavky vyplývající ze stávající vyhlášky 82/2018 Sb. je v tomto ohledu žádoucí požadovat za zastaralé a tato by neměla v tomto bodě sloužit jako podklad pro tvorbu nové legislativy. Důvodová zpráva k vyhlášce 82/2018 Sb. se sice také u § 19 na NIST SP 800- 63B také odvolává, avšak opět bez korektní interpretace obsahu sekce 5.1.1.2 zmiňovaného dokumentu, naopak už tato vyhláška je s ním přímo v rozporu.
Reakce NÚKIB:
Akceptováno jinak.
Periodicita 18 měsíců pro změnu hesla je zanechána právě protože subjekty se zpravidla nijak aktivně nezajímají o to, zdali jejich hesla byla kompromitována, tudíž zde lze argumentovat textací NIST jen částečně. Délka 18 měsíců není nijak náročná a je to tak dlouhá doba, že se neočekává "pouze jednoduché pozměnění předchozího hesla" kvůli kterému se od periodicity upouští (protože je to kontraproduktivní), požadavek na změnu hesla při zjištěné kompromitaci přidán do požadavků.
Ve skutecnosti ... nemusi. Pominme prosty fakt, ze to stejne bude jen car papiru. Ale ty muzes klidne prohlasit, ze tvoje nastaveni (=nemenit hesla) je bezpecnejsi, a tudiz legislative neodporuje.
Znam osobne pripad, kdy si uzivatele (banka) museli metit heslo (tusim 20 znaku nejmene) kazdych 14 dnu, a nepravidelne chodily kontroly, ktere kontrolovaly supliky, monitory, klavesnice ... zda to tam nekde nemaji napsane.
A vypadalo to presne podle toho "SkakalPesPresOves202326".
Já se potkal s každoměsíční změnou, ale zpestřenou o kontrolu, že ta hesla si nejsou podobná (3 znaky v řadě na stejné pozici, bez ohledu na malá/velká) v řadě 14 hesel (aby tam nemohlo být číslo měsíce - takže se přidalo koncové číslo roku...).
Používal jsem systém s výchozím heslem MojeHeslo RRM
, každý měsíc rotované o jeden znak dál (MojeHeslo - NpjfIftmp - OqkgJgunq - ...).
Jediným výsledkem takového opatření byl zvýšený počet uzamčených účtů a žádostí o reset hesla.
Radši se neptejte!
(Ale jednoduše: ta hesla se nenastavují přímo v systému, ale speciální aplikací, která si to prostě pamatuje. Takže útočník nemusí pracně sbírat hesla po celém systému, ale úplně mu stačí probourat se k té databázi posledních 14 hesel... Jediné štěstí je, že tam nejsou celá hesla, ale jen hashe nějakých podřetězců - takže z toho to heslo stejně jednoduše nesestavíte.)
Teď nepolemizuji s tím, že to prostě není bezpečné - není, a je to hloupé.
Tříznakové kombinace, to je, řekněme, zhruba 8 milionů použitelných kombinací. To znamená taky osm milionů hashů. Nic, co by se nevešlo naráz do paměti, nic co by se nedalo snadno prohledat.
A taky nic, co by se nedalo kdykoliv spočítat znova, doslova za pár sekund. Tedy: proč to vůbec ukládat?
Úplně postačí odkaz do té neexistující tabulky, uložený opět ve formě hashe. Kontrolujete pouze, jestli už něco takového vyšlo - ale na dekódování chybí spousta dalších informací.
(Což je security by obscurity
jak vyšitá...)
Cimz ale v principu snizim bezpecnost takoveho reseni (bez ohledu na uroven obskurity, kterou okolo vymyslim). A beztak jsou tyhle "potreby" primarne vyvolane temi jedinci, co maji touhu vynucovat periodicke password-change, a to samo o sobe je i formalne oznacene za archaicky pristup k bezpecnosti.
Přiznám se, že nějak nerozumím.
A) Tříznakové kombinace mají s nějakou rozumně očekavatelnou znakovou sadou spíš statisíce než miliony možných kombinací.
B) Vůbec nerozumím, proč bych měl vůbec ukládat hashe _všech_ těch kombinací?
Jestli jsem pochopil dobře, tak ten program rozseká ta hesla na kousky a ty pak ukládá samostatně jako hashe. To aby pak mohl hledat, jestli se ty kousky někdy v minulosti vyskytly. Jenže to je právě esence toho průseru.
Hledat k hashi šestimístné heslo je mnohatisíckrát náročnější než hledat k hashi třímístné heslo. Jenže pokud ho rozseknete a zahashujete jako dvě třímístná hesla, tak je to jen dvojásobné množství práce.
Celá náročnost hledání původního hesla z hashe stojí na tom, že to není možné dělat po kouscích. Jen tak roste stavový prostor exponenciálně s počtem znaků. Brutefocrovat třímístné heslo je brnkačka.
To není security by obscurity. To je ukázkový cargo cult. Protože tím sekáním se rozbije základní princip díky kterému je lámání hashů náročné. V téhle chvíli je nějaké solení o kterém jste psal už jen slaměná věž s křovákem s kokosy na uších.
Když v 80 letech microsoft navrhoval své řešeto LM hash, tak mimo jiné bilionkrát zjednodušil lámání tím, že ho seknul a zahashoval jako dvě sedmimístné půlky. Sekat to na ještě kratší kousky dnes, kdy výkon odpovídající tehdejším superpočítačům nosí po kapsách puberťačky je s prominutím ostuda.
Takovehle vopicarny se daji snadno obejit mechanicky ... staci vyuzit vlastnosti klavesnice. Vysledek je tentyz - kdyz ziskam 2-3 hesla, umim vygenerovat libovolne dalsi.
Ostatne ja si spoustu hesel vubec nepamatuju, umim je mechanicky nabouchat do klavesnice, ale kdyz mi nekdo predhodi treba klavesnici platebniho terminalu s ototecnym numpadem ... sem v loji(musim si pak v duchu predstavit tu pocitacovou a z toho zreverzovat co ze to do ni vlastne mlatim).
Apropos, zarnym prikladem na zmenu hesla je ... nbusr ... na nbusr123.
Na strane 75 je k temuz jeste lepsi blabol :-)
Z kontrolní činnosti i z dobré praxe máme rozdílné zkušenosti,
pokud bychom rezignovali na pravidelnou změnu hesla, máme obavu, že by pozitiva byla velmi rychle přebita negativními následky z toho plynoucími.
Jinymi slovy NUKIB potvrzuje, ze hleda pseudoreseni, ktera se jim snadno kontroluji :-)
;D vzpomel sem si na jeden takovy zazitecek, co se tyce zmeny hesla. Pri covidu se chtelo aby lidi nechodili, takze i novacci si to heslo meli nastavit vzdalene. Jenze ... to windowsi neumi. Pokud je totiz na RDP nastaveno zabezpeceni prenosu (network level auth), tak se uzivateli nezobrazi ta vyzva k nastaveni hesla.
Vpodstate se to da vyresit jedine tak, ze se uzivatel prihlasi, a pak si zmeni heslo "dobrovolne", neda se pouzit enforce. A nekdo na tom supportu to pak musi nejak zkontrolovat + aspon 5x uzivateli popsat, jak se meni heslo.
Dik za potvrzeni, ze vubec netusis o cem je rec...
Kdyz uzivateli expiruje heslo, nebo spravce nastavi vynucenou zmenu hesla, tak pokud uzivatel sedi u pocitace, tak se neprihlasi, dokud tu zmenu neudela. Vyskoci na nej loginscreen, ktery ma 4 policka - jmeno, puvodni heslo a 2x nove heslo.
Stejne tak zjevne netusis, jak funguje RDP. RDP ma v dva rezimy. V tom originalnim (bez zabezpeceni) to funguje tak, ze se kdokoli anonymne pripoji, zobrazi se mu windows loginscreen, a muze pouzit libovolny z desitek znamych a stovek neznamych zpusobu, jak ho obejit (presne to se da udelat na libovolnym stroji ke kterymu je fyzicky pristup).
Aby se toto nedelo, tak tam MS pridal tu druhou, a doporucovanou moznost, ze se uzivatel nejdriv musi prihlasit, a teprve pak se mu neco zobrazi.
Jenze kdyz si uzivatel ma zmenit heslo, nemuze se prihlasit, protoze to mu windowsi nedovoli, takze si ani nemuze zmenit to heslo, protoze se mu zadna vyzva nezobrazi.
A ted mazej, a vyzkousej si to.
Přesně tak, je to jen o nastavení od IT. Nicméně i tak lze zkusit vypnout v nastavení RDP klienta podporu CredSSP, a pokud nepomůže, tak jde heslo změnit vzdáleně PowerShell skriptem. Obojí zde:
https://evotec.xyz/how-to-change-your-own-expired-password-when-you-cant-login-to-rdp/
Ale obecně, pokud IT znemožní uživatelsky jednoduchou změnu hesla, tak to má řešit IT individuálně (např. sami nastaví dočasné heslo).