Vlákno názorů k článku Jak se přihlašovat na SSH bez zadávání hesla od M. Prýmek - Trochu mi v článku chybí diskuse nad tím, o kolik...
-
Trochu mi v článku chybí diskuse nad tím, o kolik je takový postup bezpečnější (čili jaké útoky znemožňuje) než certifikát bez hesla (uložený také na disku).
Laicky si říkám, že k tomu, aby mi někdo ukradl certifikát bez hesla, potřebuje rootovský přístup k danému stroji nebo mě alespoň potřebuje přesvědčit, abych spustil pod svou identitou nějaký jeho skript.
Pokud se nepletu, obě dvě věci mu stačí i ke kompromitaci certifikátu s heslem:
ad „spustím jeho skript“: může si cokoli nechat podepsat mým agentem (má přístup k danému socketu) – ale jenom dotehdy, než na to přijdu (jak?). Toho může využít např. tak, že se přihlásí na stroje, kam mi certifikát umožňuje přístup a přidá tam do authorized_keys svůj klíč. Dokud si toho nevšimnu (jak?), vesele se přihlašuje všude, kam můžu já.
ad „root“: stejný postup. Pokud je šikovnější, mohl by (jak těžké to je?) získat rozšifrovaný klíč z paměti ssh-agenta.
Přijde mi, že jediný skutečně významný nárůst bezpečnosti oproti certifikátu bez hesla přináší hardwarový token. (skutečně hardwarový, ne jako iKey 1000 :)
Pokud se pletu, uvedení na pravou míru uvítám a předem za něj díky!
-
Mordae (neregistrovaný)
Jeste bych dodal; pokud dostane roota, nebo meho uzivatele pres sit, je to borec a zaslouzi si to, ale muze se stat, ze ten notebook nekdo ukradne a podobne. Hlavne u sluzebniho notebooku bych to asi neriskoval. Sifruji tedy pro jistotu cely disk, ale drive jsem sifroval alespon ty klice.
-
> pokud dostane roota, nebo meho uzivatele pres sit, je to borec a zaslouzi si to
Debata o bezpečnosti nějakého řešení je imho debata o tom, jaké situace umožňují kompromitaci. A faktem je, že když se člověk přihlašuje obyčejným heslem, tak kompromitace jeho účtu nevede ke kompromitaci hesla. V tomhle ohledu je teda řešení s ssh-klientem HORŠÍ než normální heslo.
> ale muze se stat, ze ten notebook nekdo ukradne a podobne. Hlavne u sluzebniho notebooku bych to asi neriskoval. Sifruji tedy pro jistotu cely disk, ale drive jsem sifroval alespon ty klice.
V tom případě by útočníkovi stačilo ukrást notebook v okamžiku, kdy jste aktuálně přihlášen ;) První, co udělá, samozřejmě bude, že vypne screensaver :)
-
hajoucha (neregistrovaný)
> Debata o bezpečnosti nějakého řešení je imho debata o tom, jaké situace umožňují kompromitaci.
dovolím si oponovat: Debata o bezpečnosti je především o hodnotě toho, co chci zabezpečit. A proto také Váš nápad se zabezpečením hesla je poněkud mimo. Jestliže heslo k trezoru zůstane utajeno a trezor bude vykraden, tak to asi nebude považováno za skvělé bezpečnostní řešení.
-
> Debata o bezpečnosti je především o hodnotě toho, co chci zabezpečit.
Ano. Ale je potřeba porovnávat cenu dat na jedné straně a pravděpodobnost situace umožňující kompromitaci na té druhé.
> A proto také Váš nápad se zabezpečením hesla je poněkud mimo.
Jaký můj nápad? Napsal jsem, že za jediný postup, bezpečnější než certifikát bez hesla, považuju certifikát na tokenu.
> Jestliže heslo k trezoru zůstane utajeno a trezor bude vykraden, tak to asi nebude považováno za skvělé bezpečnostní řešení.
Nerozumím.
-
„V tom případě by útočníkovi stačilo ukrást notebook v okamžiku, kdy jste aktuálně přihlášen ;) První, co udělá, samozřejmě bude, že vypne screensaver :) “
Nikdy jsem to neskousel s sifrovanym diskem, ale mam obavy zda by v pripade, ze se potencionalnimu utocnikovy podari ukrast notebook (nebo i jen HDD) nestacilo, ze se z disku muze nabootovat system? Pak by teoreticky pri bootu mohlo stacit zadat jadru jako parametr init=„/bin/bash“, nebo nejaky obdobny postup, kterym nastartuji system a ziskam pristup k datum, alespon pro cteni. Vim z vlastni zkusenosti (uz se mi taky stalo, ze jsem zapomelo heslo superuzivatele :) ), ze na normalnich systemech se podobne da nakrasne obejit autentizacni system…
-
Předpokládám, že pisatel měl namysli šifrování disku, které je k něčemu – tj. s požadavkem vložení hesla při bootu.
Mně šlo ale o něco jiného – pokud ukradnu NB nabootovaný s přihlášeným uživatelem a ten používá řešení popsané v článku, mám automaticky přístup ke všemu, k čemu měl přístup on.
Takže opět jediné bezpečné řešení je zadávat heslo, nebo mít certifikát na tokenu (s předpokladem, že ten mi nikdo neukradne).
-
Sten (neregistrovaný)
Z toho důvodu je u NTB stejný požadavek jako u tokenu: nenechat někde zapnutý :)
Jinak já tohle kromě šifrování disku řeším ještě přes automatické zamknutí NTB + smazání hesel z SSH agenta a po chvíli i hibernace na šifrovaný swap, pokud zadané BT zařízení (konkrétně můj mobil) zmizí z dosahu (samozřejmě lze přerušit zadáním hesla). Taky účinné.
-
semerad zula (neregistrovaný)
Základní rozdíl mezi klíčem/certifikátem s heslem a bez hesla je stejný jako u souboru, který je šifrovaný nebo není. Buď máte klíč na disku v šifrované podobě nebo ne. A zjednodušeně řečeno: klíč/certifikát = soubor obsahující heslo. Soubor s hesly si asi také jen tak neuložíte na disk…
Z toho plyne například to, že v případě, že nešifrujete celý disk, stačí pro získání funkčního certifikátu bez hesla fyzický přístup k PC/serveru (a je jedno, jestli je někdo přihlášený nebo ne, je-li spuštěný nebo ne). Dalších scénářů je mnoho a záleží na celkovém zabezpečení serveru/PC.Certifikát na HW tokenu je další úroveň, kdy se ztrácí nevýhody toho, že klíč leží na disku. V případě, že Vás někdo kompromituje pomocí nějakého scriptu, to stejně nepomůže, protože při použití klíče se stejně nahrává do paměti (v případě, že nepoužijete klíč, který Vám také provádí potřebné výpočetní operace → klíč neopustí token). Proti kompromitaci roota hw klíč pomůže (ne nezbytně). Na druhou stranu asi jednodušeji ztratíte hw token než celý notebook … :-).
-
> Základní rozdíl mezi klíčem/certifikátem s heslem a bez hesla je stejný jako u souboru, který je šifrovaný nebo není.
Bavíme se ale o řešení načrtnutém v článku – a to funguje tak, že na disku je heslo zašifrované, ale v paměti leží nezašifrované. Navíc daný uživatel (čili i ten, kdo se dostane k „přihlášenému počítači“) si může nechat podepsat cokoli.
> Soubor s hesly si asi také jen tak neuložíte na disk…
Rozdíl mezi nezašifrovaným heslem na disku a v paměti není imho nijak velký.
> Z toho plyne například to, že v případě, že nešifrujete celý disk, stačí pro získání funkčního certifikátu bez hesla fyzický přístup k PC/serveru
Zatímco v popsaném řešení při fyzickém přístupu k počítači sice nezískám certifikát jako takový, ale můžu si nechat cokoli podepsat, nebo nahraju trojana, který mi podepsání čehokoli zabezpečí i v budoucnu…
=====
Čili sečteno podtrženo: situace „certifikát s heslem na disku + ssh-agent“ oproti situaci „certifikát bez hesla na disku“ nepřináší imho podstatně vyšší bezpečnost.
