Vlákno názorů k článku
KeePass: lokální zranitelnost umožňující přístup k heslům od Uncaught ReferenceError: - ale tohle je přece už pár let starý...

Hesla vyhradne lokalne. Nikto nepotrebuje vediet moje heslo, privatny ssh kluc etc. Ak ma nahodou zrazi autobus, tak su efektivnejsie a cistejsie cesty ako moj ucet deaktivovat a pridelit prava niekomu inemu. Ak ich predsa len z nejakeho fakt inak neriesitelneho dovodu treba synchronizovat tak existuju bezpecnejsie cesty ako nazdielat db s heslami na sambu...

Proč výhradně lokálně? Co je na tom lepšího, než když jsou uložena někde vzdáleně?

Pretoze zodpovedam za to, aky sposobom budu pristupy pouzite. Tym padom chcem mat kontrolu ako je s tymi pristupmi zaobchadzane. Pretoze tajomstvo zostava tajomstvom len vtedy ak vie iba jedina osoba. Akonahle sa podeli tak to uz nie je tajomstvo, ale zdielana (mozno doverna) informacia.

dw: No a jaký je rozdíl v tom, zda jsou ta hesla uložená lokálně nebo vzdáleně, vzhledem k tomu, že za ně zodpovídáte a chcete mít kontrolu nad tím, jak se s nimi zachází? Mne napadá jediný rozdíl – na lokálním počítači máte lokálního uživatele a spouštíte pod ním veškeré programy, takže je to mnohem nebezpečnější, než na vzdáleném serveru, ke kterému přistupujete jenom pomocí síťového protokolu.

Doufám, že víte o tom, že hesla na vzdáleném serveru mohou být uložena šifrovaně a mohou se šifrovat a dešifrovat lokálně u vás, takže server se nikdy to samotné heslo nedozví. A dělá to tak každý aspoň trochu příčetný správce hesel.

ale já se nebavil o osobních věcech, ale jak to řešíme ve firmách a korporátech. Pořád máš velké množství různých app id, secred id, hesel, klíčů a všech dalších tajností, které potřebuješ nějak sdílet a generovat pro zaměstnance. Na tvá hesla si soukromně klidně keepass použivej, to ničemu nevadí.

Z mojich skusenosti je to vo firmach a korporatoch riesene vsade inak. Zalezi akych maju shopnych adminov a security team.

To ze su api, ku ktorym je len jedno heslo a ani to nejde zmenit si uvedomujem, tam patri proxy, teda ak nechcem zbytocne premyslat o tom kolko byvalich zamestnancov a ich znamich to heslo ma.

A k tomu ci by zamestnavatel mal vediet heslo ktorym potvrdzujem moju identitu: ziadny zamestnavatel ho nema pravo vediet, moze maximalne nastavit pre hesla politiku ako maju vyzerat.

> Je to důležité, jestli jde o textový soubor? Protože když změníte binárku, k heslům, která zadají přihlašující se uživatelé, se dostanete.

Stačí i textový soubor, například v /etc/pam.d si můžete pověsit vlastní handler (shellový skript), který heslo dostane a může zalogovat.

Taky by mě zajímal ten způsob útoku. Musel bych mít velmi specificky soubory KeePass na síťovém disku, ale ne ostatní věci, protože jinak by mi mohli mnohem jednodušeji přidat libovolný kód do .bashrc, libovolné rozšíření do .mozilla atd.

S většinou těch výhrad ke KeePassu se dá souhlasit. Ale připadá vám jako dobrý nápad používat jako klienta pro password manager aplikaci, která má za rok 2022 celkem 303 bezpečnostních zranitelností? Ano, mluvím o Chromu. K tomu je dobré započíst zranitelnosti webových serverů a vlastních serverových aplikací. Například v roce 2022 dopadl celkem špatně LastPass, když měl dva závažné bezpečnostní incidenty během třech měsíců. Je webový password manager vůbec lepší nápad, než post-it lísteček na monitoru?

Nezáleží na počtu zranitelností, ale i na jejich charakteru. Navíc spousta těch hesel (dnes to bude většina i u spousty IT správců) se stejně používá v prohlížeči, takže prohlížeč se to heslo tak jako tak dozví.

V dnešní době se bráníme v drtivé většině případů proti remote útokům, takže z tohoto pohledu je lísteček na monitoru hodně bezpečné řešení. Má to dvě nevýhody – tolik lístečků, kolik máte hesel, by se vám na monitor nejspíš nevešlo, navíc jejich hledání a hlavně opisování hesel by bylo dost nepohodlné. A pak to má ještě jednu reálnější nevýhodu – správce hesel má chránit před lidskou chybou, že heslo zadáte někam, kam nemáte. Tedy proti phishingu. Tedy je potřeba, aby správce hesel identifikoval, kam chcete heslo vložit, našel správný záznam a heslo sám vložil. U webů to funguje dobře, pokud máte doplněk v prohlížeči, protože weby jsou jednoznačně identifikované svou doménou. Při zadávání do aplikací už to takhle nefunguje, správce hesel obvykle neumí zkontrolovat, o jakou aplikaci se jedná, a vložit do ní správné přihlašovací údaje.

Na prvním místě ty post-it notes. Ty znamenají, že přístup k heslům má doslova každý, kdo jde kolem počítače. Uklízečky, ostraha objektu, údržba, kolegové, kontraktoři... Navíc spousta meetingů dnes bývá online, a tam hrozí riziko, že se díky kameře k heslům dostane i kdokoliv, kdo je na online meetingu.

Teď k těm password managerům používaným z browseru. Jako sorry, ale kdyby měl lokální password manager stovky bezpečnostních děr ročně, tak by vás asi ani ve snu nenapadlo mu svěřit hesla. U webového password manageru ale z nějakého důvodu nevidíte problém. Podotýkám, že jde o scénář, kdy se browser a/nebo serverová aplikace může dostat ke všem heslům, ke kterým máme přístup. Za mě je to velmi rizikové.

Pokud jde o zadání správného hesla na správné místo, tak k tomu není nutný doplněk browseru. A věřit s hesly bezpečnosti browseru a/nebo doplňků je podle mě jako pracovat na cirkulárce se zavřenýma očima.

Ty lístečky na monitoru samozřejmě nebyl návod, že to tak má někdo dělat. Jenom připomenutí, že reálné nebezpečí je dnes někde úplně jinde.

K bezpečnostním dírám v prohlížeči už jsem vám vysvětloval, že nejde o jejich počet, ale o to, co ta která bezpečnostní chyba znamená. Když v bance dojde k bezpečnostní incidentu, že se zahradník škrábne o trn rostliny, také kvůli tomu nebudete hned vybírat peníze z účtu.

Stejně tak jsem psal, že když používáte webové aplikace, stejně se prohlížeč to heslo dozví, takže mu stejně musíte důvěřovat.

Pokud zadání hesla na správné místo necháte na kontrole člověka, můžete na něm nechat i to, aby si heslo zapamatoval, a nepotřebujete žádného správce hesel. Akorát hodně štěstí při hledání takového supermana.