Vlákno názorů k článku Pravidla pro tvorbu hesla: jaká hesla nejčastěji zkoušejí útočníci? od TencosledujeLupu - Ad cyklická výměna je problematická - user pak...

těžko posuzovat bez kontextu. Není heslo jako heslo, může to být třeba důsledek toho, že heslo se váže k certifikátu s omezenou platností, které je součástí HW klíčenky/vstupní karty. Pravidelná změna hesla se může vázat i na proces fyzické přítomnosti někde, nemusí se ani vynucovat, že nové heslo musí být jiné atd. (viz třeba pin k občance).

Někdy ty omezení plynou i z technologií, které se používají (nemožnost evidovat poslední použití hesla a nutnost pravidelně aktualizovat hashovací algoritmus). Ne, všechny typy hesel se validují pouze online a můžeš zajistit rate limiting a uzamykání.

V tom příspěvku jsem narážel na forward secrecy v rámci šifrování, kdy dneska je norma symetrické klíče v rámci zabezpečeného spojení měnit v hodinových intervalech jako obranu proti zpětnému louskání.

Můžeme se o tom bavit teoreticky jak chceme, ale prakticky se IT systémy budují v nějakém prostředí, které mají nějaká svá specifika, životní cykly a nemůžeš ze dne na den to změnit jakkoliv.

Ne všechno je webová stránka s přihlašovacím formulářem, víme? Miluji, když okamžitě víš, že to je špatně, aniž bys aspoň na chvilku připustil, že rozmanitost systémů může být různá a NĚKDY to může dávat smysl.

Ale my se bavime o tom, ze jsou politiky, co tu zmena hesla proste tupe vynucuji ciste jen na zaklade casoveho kriteria.

A spoustu veci, co zminujete jsou v konecnem dusledku jen zpusoby, jak si ti takzvani bezpecaci na ukor uzivatele obchazi jiny svuj problem (pocinaje tim, ze si vlastne ani neumi pohlidat potencialni unik tech password-hashu). Aneb misto toho, aby bezpecak hlidal incidenty ve sve infrastrukture jen buzeruje uzivatele. Protoze to je pro nej jednodussi.

Ale porad jsme u toho, ze ty limity hlavy jsou nejake - a typicky u beznych uzivatelu na toto i ponekud mensi, nez treba u nas geeku. Ktere ve vysledku vedou k nezadoucimu chovani, ktere bezpecnost naopak dosti snizuji. Bohuzel tem takzvanym bezpecakum tohle stale nedochazi. Pripadne se projevi jejich alibismus stylem, ze to uz neni jejich problem, ze? :-) Ona i ta pravdepodobnost, ze se ztrati papirek s heslem je asi vetsi, nez ze fakt uniknou ty hashe. A navic to pak ma nabyvatel takoveho listecku jednodussi, nemusi ani nic lamat...

Tak si stěžuj u těch politiků. V rámci připomínek k transpozici NIS2 přišla pouze jediná, které se nelíbilo těch 18 měsíců, nikdo jiný k tomuhle oficiálně nevznesl podmět.

Hodně z těch věcí, ale přichází s chování fyzického světa, kde je hromada věcí také vázána na čas a mají expiraci. IT systémy tohle musí respektovat, protože změna není tak flexibilní.

Pořád mluvíš o situaci, kdy máš online systém s nějakým realtime přístupem, centralizovanou databází a můžeš všechny ty fičůry řešit. To ale není jediné užití IT, máme tady řadu ostrovních systémů (řadu jich danou zákonem), máme tady řadu fyzických omezení, máme tady řadu předpisů, které se musí v těch systémech dodržet. Není to pouze rozhodnutí "neschopných bezpečáků".

Samozřejmě máš prvadu, dělat expiraci hesla u online systému je šílenost a byla to šílenost vždycky. Tam máš jiné nástroje k dispozici.

;oD
Nikoliv nevznesl podmět (asi ani přísudek), ale nevznesl podnět. Některá písmena jsou na klávesnici zatraceně blízko sebe!

Tohle je zasite ve vyhlaskach a ty jeste oficialne v legislativnim procesu ani nejsou - a mimoto je politici (tedy poslanci, senatori) ani neschvaluji, ze? ;-) Pripominkove rizeni zvlaste kolem vyhlasek je spis jen o tom, ze se mezi sebou dohaduji urednici z jednotlivych uradu (pripominkovych mist)...

Zrovna u ostrovnich (datove s okolim nepropojenych) systemu tuplem neexistuje duvod, proc buzerovat s periodickou zmenou hesla a v praxi to konci tim, co se tu popsalo opakovane - hesla napsana na listecku, v notysku, nalepena na monitoru (treba ve zdravotnictvi k videni bezne). Tady tak trosku navic sam argumentujete kruhem - ohanite se predpisy a vyhlaskami, co ty nesmysly urcuji jako povinnost - a soucasne tvrdite, ze jinak to nejde. Maximalne vydate dalsi predpis, co formalne zakaze ty hesla do notysku zapisovat - obycejny alibismus, ze? :-) Ale furt narazime na to, ze ta lidska hlava na tohle proste neni nafukovaci... a to vy pri obhajobe toho "jinak to nejde" stale prehlizite.

máš tady řadu věcí, které mají časovou platnost omezenou zákonem (třeba zminěné občanky, licence a povolení, tam všude se to digitalizuje a musíme se nějak vypořádat s prací s hesly/tokeny/klí­či), stejně tak je je vhodné omezovat časovou platnost všude, kde je nějaká kryptografie (viz třeba TLS nebo časová razítka, u nich ti nevadí, že mají omezenou platnost?).

Pořád mluvíš o heslech, který uživatel někam zadává, ale ten problém je širší, já vůbec nemluvím o heslech, který zadávám někam do formuláře a přihlašuji se s nimi. Ono se to ale vztahuje i na hesla, který nikdy neopustí nějaké zařízení a uživatel je ani nemusí nikdy vidět, různé tokeny či jiné preuath věci, technické účty pro integrace. Ten požadavek na platnost hesla 18 měsíců totiž platí i pro technické účty a různé předgenerované tokeny, privátní klíče (vč. klíčů pro ssh), což je daleko větší zásah než platnost osobního hesla pro uživatele.

Třeba u HW tokenu se uživatel může prokázat pouze pinem, ale součástí HW token je master heslo, který má svoji platnost (resp. tu platnost má třeba certifikát v tokenu).

Vztahuje se to celé i třeba na osobní certifikáty, které vydáváš zaměstnancům (platnost 18 měsíců se vtahuje i na ně). TLS postupně snižuje dobu platnosti a 2 leté certifikáty dnes už prohlížeče nemají rádi, to celé se děje právě kvůli bezpečnosti a ty mi tady argumentuješ, že přece neomezená platnost "hesla" je dobře. Ne není a není to bezpečné, znovu zdůrazňuji, že se nebavím o osobních heslech, který zadáváš do webového formuláře na přihlášení, ale ten obor "hesel" je daleko širší než se zdá.

Ano, my se porad primarne bavime o expiraci hesel, ne o expiraci technickych prostredku okolo. Expirace hesel je proste spatna vec, kterou nejde obhajovat expiraci technickych prostredku okolo. A ano, IT/bezpecaci maji resit ty technicke prostredky - ne buzerovat s temi hesly.

Zrovna u tech technickych prostredku se snadno muze narazit na to, ze se neco rychle rozjebe, ostatne u statni spravy to mame ukazkove videt - vymeni se certifikat u NIA a nekde se s tim dlouhe hodiny... aneb portal prazana byl celych krasnych 15 hodin out... defacto kvuli jednomu certifikatu :-) To same hrozi i u tech technickych uctu (kdy v danem systemu nemusi byt uplne trivialni zmenu provest) . Muzeme se stokrat bit v prsa, jak je to technicky spravne delat - ale koncovou obeti je zase uzivatel, ktery dojede na to, ze formalne na prvni pohled spravny postup nekde v praxi selze. A cim slozitejsi to bude, tim vetsi pravdepodobnost nejakeho selhani...

Co se certifikatu tyce - ano, zkracuje se platnost nekterych certifikatu, ale rozhodne se treba nezkracuje platnost certifikatu treba u certifikacnich autorit ci treba komercnich kvalifikovanych certifikatu pro el.podpis, rozhodne neni univerzalni pravda, ze by se na hulvata zkracovalo vsecko. U tech koncovych certifikatu typicky pouzivanych pro weby je to primarne proto, ze ve velkem meritku moc nefunguji kontroly revokacnich seznamu. Coz ale neimplikuje, ze to je obecne nefungujici metoda.

A samozrejme, pokud chcete resit treba SMTP/DANE, narazite na jiste "problemy"... a vite jak se to podle nekterych doporuceni v realu resi? ;-) --reuse-key do certbotu... takze se toci porad stejny privatni klic a nespadnete do bolehlavu s aktualizaci DNS pokazde (a vyvolanymi moznymy problemy s dorucovanim posty), kdyz vymenite certifikaty. :-) Koza se nazere, koza zustane cela - certifikaty se meni... ale zaklad maji porad stejny. Coz samozrejme muzete genericky delat dle libosti, kdyz si vyrabite CSR. To same mame treba i u DNSSECu... kdypak se naposledy menil KSK u .cz? Kdy naposled rotovali klice na gov.cz? ;-) O NUKIBu nemluve, ten to "alibisticky" radsi hodil na komercniho hostera (co jeden keyset pouziva pro vsechny sve zakazniky). Podivejte se, kdy klic naposledy menilo vnitro. Aneb opet ta teorie versus praxe - a tady fakt muzeme natvrdo rict, ze z uradu kazou vodu a sami pijou vino. Po osmnacti mesicich to fakt nemeni...

vytáhl jsi sem diskuzi, kterou jsme měli na lupě, kde jsme se bavili právě o tom nařízení na expiraci hesla. Je důležité si uvědomit, že to nařízení nepokrývá pouze osobní hesla uživatelů/zaměs­tnanců/lidí, ale právě i všech technických účtů a propojení, a to je právě věc, kterou obhajuji jako důležitou a proto jsem ti i psal, že bezpečnost v IT je právě založena na rotování "tajností" a kterou při návrhu nějakých systémů musíme komplexně řešit, expirace osobního hesla někdo v IDM je obecně nesmysl, to s tebou souhlasím, ale to je věc, o které nikde nerozhoduji, to je často politika.

DANE mě mrzí, fandil jsem tomu a je škoda, že se prostě zatím neprosadilo.

To víme, že technická kvalita těch státních IT systémů je do očí bijící. Nám nezbývá asi nic jiného než na to pravidelně upozorňovat, zmiňovat.

A jaky technicky smysl ma periodicka rotace hesla, co pouziva treba aplikace pro pristup k databazi? Pricemz ten ucet muze klidne z te databaze jen cist, mit omezeny view na nektere konkretni data a kde samotna databaze neni ani primo pristupna odjinud nez ze stroje, kde ta aplikace bezi a kde spojeni k te databazi samo o sobe sifrovane? Pokud mi takove heslo unikne a data z te databaze zneuzije, pak mam podstatne vetsi problem - s celym strojem. A ten problem nezachrani to, ze jen periodicky vymenim hesla technickych uctu.

Tady se v obecne rovine bavime o tom, ze nekdo vymysli jednoduse kontrolovatelny nesmysl, ktery v ramci te jednoduchosti proste aplikuje vsude. Namisto seriozni analyzy rizik a s tim spojenych relevantnich - smysluplnych - opatreni.

DANE obecne vzato narazi na svou slozitost v praxi (provoze) - tady je prave problem to DNS - ano, jde zmenu relevantnich zaznamu zautomatizovat, ale ne kazdy to umi a ne v kazdem prostredi je to trivialni vyresit. Ono technicky co se prenosu zprav tyce je treba X.400 navrzene take lepe, nez hojne pouzivane SMTP. Ale neuchytilo se to moc zrovnatak - prave pro svou slozitost (byt pamatuji doby, kdy treba i MS Exchange to drive pouzival nativne).

"těžko posuzovat bez kontextu" no právě na to řečník naráží. Že se kontext vůbec nebere v potaz a plošně se stále memoruje:
- periodicky měnit heslo = lístečky, vzorec
- komplexita = stejný vzorec u různých služeb
- generátor hesel = nelze používat všude (zkuste změnit heslo do domény generátorem :-p) = lístečky, vzorec

A proto neustále je třeba o tom mluvit, co vlaatně navrhujete: kontext mají vnímat i pracovníci bezpečnosti = neděje se tak, důležitý je zážez v politice firmy

Ano a právě z té pozice mluvím, v té době jsem také neměl fištrónu, že to není ono a mělo by se na to jít jinak, to vím až dnes. Je správně, když se člověk poučuje s chyb a dělá si retrospektivu.

Ale ona to nebyla z pohledu dane doby chyba. V dane dobe to bylo reseni dostacujici a technicky zvladnutelne. Nezapominejte, ze to byla doba, kdy jste na stole mel krabici s mensim vykonem, nez si dnes tahame po kapsach a dnes uz i na naramku na ruce, ze? :-) To je proste evoluce, nenazyval bych to chybami.

"kdy jste na stole mel krabici s mensim vykonem, nez si dnes tahame po kapsach"
To plati i dnes.