Názory k článku Hesla SSH klíčů jsou špatně hashovaná, lze je prolomit velmi rychle
-
Tak ta funkce podle popisu bude cosi legacy. Forky OpenSSL (LibreSSL, BoringSSL) se k tomu mohou postavit různě – mohou funkci nechat (a různými způsoby varovat, že je to jen pro legacy kód, třeba i deklaraci vyčlenit do legacy.h), nebo ji mohou zrušit. Opravit ji v principu nejde, protože pak by to byla jiná funkce. Problém není v implementaci, ale v návrhu.
-
Jenda (neregistrovaný)
> šifruje pomocí 256bitového AES s blokovým režimem CTR
Hodilo by se dodat, jakým způsobem chrání proti změnám útočníkem, protože u samotného CTR lze flipnout libovolné bity a nikdo nic nepozná. A už úplně vidím jak někdo vymyslí, jak překlopit nějaký bit v klíči tak, aby podpis vyleakoval jedno z prvočísel. Jednoduchý experiment mi neukázal že by se to nějak kontrolovalo a zdrojáky se mi zkoumat nechce.
-
Ondřej CaletkaZlatý podporovatelŘekl bych, že MAC tam žádný není, takže takovému útoku asi nic nebrání. Nicméně úplně si to praktické provedení nedokážu představit.
-
Dnes už ale není moc důvodů, proč GCM mód nepoužít. Resp. je velmi málo důvodů použít CTR nebo CBC v nových formátech/protokolech.
Jeden útok, který sice neni praktický, ale když už hledáme něco teoretického - možnost bitflipu v klíči by mohla vygenerovat špatné podpisy, které jsou jednodušeji prolomitelné (něco jako invalid curve attacks). Možnost flipnutí bitu na disku většinou značí mnohem větší problém, proto čisto teoretické (ale v nějaké šílené kombinaci např. s rowhammer by to velmi teoreticky šlo).
-
cinnamon (neregistrovaný)
Říkají, že jednou z výhod open source je možnost prohlížet/měnit zdrojky, takže neváhej a mrkni na to ;)
-
Ondřej CaletkaZlatý podporovatel
Pokud dobře rozumím dokumentaci, tak se Gnome-keyring chová jako SSH agent, do kterého se klíč nahrává standardní utilitou
ssh-addz balíku OpenSSH. Neměl by být tedy žádný problém načíst klíč i v novém formátu OpenSSH. -
Už je to nějaká chvíle, co jsem to zkoušel, takže asi došlo ke změně. Před nějakým časem (cca rok?) jsem se u toho docela natrápil, než jsem zjistil, že gnome-keyring s ED25519 (vždy nový formát) a klíči vytvořenými s přepinačem '-o' neumí pracovat, takže jsem to řešil tak, že jsem komponentu 'ssh' u gnome-keyringu přestal používat (/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets) a místo toho požul keychain.
-
Ondřej CaletkaZlatý podporovatel
Tak podle všeho od verze 3.28 Gnome vlastní implementaci ssh-agenta zahodilo a nadále používá agenta z OpenSSH s příslušnými wrappery, aby se choval jako původní Gnome keyring.
-
LP (neregistrovaný)
Putty je na tom obdobně, neboť ukládá klíče (privátní i veřejný) do souboru .ppk. Heslo pro šifrování privátního klíče se generuje pomocí algoritmu SHA-1 z heslové fráze, kterou zadá uživatel; viz How does Putty derive the encryption key in its .ppk format? Operace SHA-1 se provede třikrát.
Bezpečnost uložení lze zlepšit pomocí aplikací, které umí simulovat funkčnost pagent:- gpg-agent pro windows umí simulovat pagent. Současné verze GPG pro uložení klíčů používají hashovací funkci a PBKDF s velkým počtem iterací. Počet iterací odvozuje od rychlosti procesoru, u mne je to 17825792, maximum je 65011712
- keepass včetně pluginu keeagent pro simulaci pagent
-
Lion (neregistrovaný)
V článku mě jako začátečníkovi chybí dvě zásadní informace...
1) jakým příkazem ověřím, zda jsou moje klíče bezpečné
2) jakým příkazem provedu překódování privátních klíčů na bezpečnějšíPS: ano, umím používat google, ale je zarážející, že u článku, který informuje o tak zásadním problému autor nedoplnil dva příkazy.
-
Ondřej CaletkaZlatý podporovatel
1) Ověřit, že je klíč bezpečný snadno nelze, může mít třeba slabé heslo, nebýt vůbec šifrovaný, používat zastaralý algoritmus nebo krátkou délku klíče. Ověřit, že klíč používá nový formát můžete snadno nahlédnutím dovnitř, třeba takto:
$ grep -q "BEGIN OPENSSH" ~/.ssh/id_rsa && echo "Klíč má nový formát"
2) Příkaz je popsán v odstavci pod nadpisem „Snadná pomoc existuje od OpenSSH 6.5“ a doplněn ukázkou v terminálu tamtéž. Chcete-li to ještě jednou a explicitněji, tak tedy:
$ ssh-keygen -o -p
-
Ondřej CaletkaZlatý podporovatel
Celý článek je o tom, co se může stát, když vám někdo ukradne privátní klíč. A to se může stát jak na serveru, tak i na pracovní stanici. Dokonce by se dalo říct, že na pracovní stanici, kde je software, který uživatel spouští, výrazně rozmanitější, bude množství útočných vektorů vyšší.
-
DannyStříbrný podporovatelU kompromitovaneho stroje je uz vcelku irelevantni, jakym zpusobem se k privatnimu klici utocnik dostane. V momente, kdy klic uz nejak ziska, je tento klic kompromitovany vzdy - chlacholit se tim, ze je prece dobre heslem chraneny je nesmysl (stejne tak, jako se utocnik mohl dostat ke klici se muze dostat i k samotnemu heslu).
-
Filip JirsákStříbrný podporovatelPak by ta ochrana heslem byla zbytečná. Pokud uživatel heslo používá, asi chce vyšší stupeň ochrany a to, že to nefunguje, není možné omlouvat tím, že to vlastně není potřeba.
-
DannyStříbrný podporovatel
Pokud nekdo skutecne chce vyssi stupen ochrany, mel by spis pouzivat adekvatni hardwarove zarizeni, ze ktereho nejde privatni klic ziskat vubec. Na soubor na disku s klicem jde v dusledku pouzit i hrubou silu - kdykoliv, bez ohledu na to, jak je to zasifrovane. Je to cele jen o tom, jak moc je dany klic "zajimavy". Ochrana ssh klice heslem zneuziti privatniho klice jen komplikuje - ale rozhodne neplati, ze znemoznuje.
-
Ondřej CaletkaZlatý podporovatel
Celé šifrování privátního klíče heslem je právě o tom, kolik úsilí ta hrubá síla bude stát, jestli se bude každou sekundu zkoušet 30 miliard nebo tři sta hesel. Ostatně i z libovolného hardwarového zařízení privátní klíč nepochybně získat lze, záleží jen na rozpočtu.
-
DannyStříbrný podporovatel
Samozrejme, ze i z hardwaroveho zarizeni jde privatni klic teoreticky ziskat - nicmene v tomto pripade obvykle plati, ze bez fyzickeho pristupu k onomu hardware se neobejdes. Coz je samo o sobe dalsi a znacne komplikujici faktor (v porovnani se souborem, ktery se vali nekde na disku, ktery snadno prectes s opravnenim uzivatele - tedy krome uzivatele si v nem bez obtizi pocte i bezici malware...)
-
Filip JirsákStříbrný podporovatel
Ochrana klíče heslem je takový kompromis. Můžu mít klíč na flash disku a použít ho prakticky odkudkoli, a zároveň vím, že když budu mít podezření na kompromitaci, mám nějaký čas na výměnu klíče.
Všechny ochrany něco jenom komplikují ale nikoli znemožňují. Pokud někdo klíč chráněný heslem nechce, tak heslo nepoužívá – třeba já na své pracovní stanici mám klíč také bez hesla. Podstatné je, že když tam ta ochrana heslem je, tak má fungovat tak, jak by člověk očekával, a ne že to bude jenom takové placebo.
-
DannyStříbrný podporovatel
Pokud je klic kompromitovan (tzn. privatni klic je v rukou nepovolane osoby, mel by byt zmeneny okamzite (stejne, jako se okamzite meni kompromitovate/prozrazene heslo). Naopak heslo u klice viditelne u mnohych vede k falesnemu pocitu bezpeci a domnivaji se, ze je mozne takovy ukon odkladat na pozdeji - coz je uvaha sama o sobe chybna, ta vymena tak jako tak musi probehnout tak ci onak ihned.
A samozrejme, ze i u privatnich klicu plati, ze pri pozadavcich na vetsi bezpecnost je dulezita take diverzita - tedy nepouzivat jeden klic vsude, stejne jako se nema pouzivat jedno heslo. S skutecny paranoik muze oddelit uzivatelske aplikace i od prostredi, ve kterem provadi administrativni ulohy. Idealne pak ty ulohy provadet z oddelenych stroju, ktere neslouzi k jinemu ucelu - nekde je to primo nutnost.
Ano, nejvetsim pruserem z pohledu bezpecnosti jsou kompromisy - a obzvlast ty, ktere jsou konany "z pohodlnosti" :-)
-
Filip JirsákStříbrný podporovatel
Pokud je privátní klíč zašifrován heslem a uložen do souboru, a tento soubor se dostane do rukou nepovolané osoby, neznamená to rovnou kompromitaci privátního klíče. Pokud vy ochranu privátního klíče nepoužíváte, je to v pořádku a nikdo vás k tomu nenutí. Ale nelze tvrdit, že nevadí, že ochrana heslem nefunguje, protože vy ji považujete za nedostatečnou.
Jinak předpokládám, že na spoustě míst také používáte hesla, takže to vaše tažení proti heslům těžko brát vážně.
-
Ondřej CaletkaZlatý podporovatel
Ten problém je hlavně jak zjistit, že ke kompromitaci došlo. Domnívám se, že každý běžný uživatel pravidelně provádí akce, které v konečném důsledku mohou vést k odcizení klíče. Já si třeba teď spustil proprietární aplikaci Spotify. Protože nemám SELinux ani jiný MAC, nemůžu si být jistý, jestli ta aplikace během přehrávání můj klíč neukradla. A takových činností dělá každý uživatel na počítači spoustu.
Paranoik by v takovém případě nemohl SSH klíče v souboru vůbec používat, protože nemůže mít jistotu, že ke kompromitaci nedošlo. Trochu menší paranoik proto raději klíč chrání poměrně silným heslem a počítá s tím, že toto heslo učiní zneužití klíče pro případného útočníka přinejmenším nepraktické.
Samozřejmě, pokud existují nějaké náznaky, že někdo z počítače skutečně odcizil jakákoli data, je na místě klíč okamžitě revokovat, o tom není sporu.
-
Já problém s klíči a přístupnost souborů, kde jsou uloženy, řeším tak, že je mám uloženy v zakryptovaném (dostatečně silně) samostatném oddílu (přes veracrypt), připojení jen na dobu potřeby dostatečně dlouhým a složitým heslem. Samozřejmě tam ukládám i další citlivá data včetně databáze hesel.
Je to samozřejmě jen jeden ze způsobů ochrany, ale myslím, že dost účinný. Další by byl mít klíče uložené na USB a to vložit jen v okamžiku potřeby, ale to je podle mě méně bezpečné, protože hrozí vyšší riziko ztráty. -
DannyStříbrný podporovatel
Za predpokladu, ze utocnik krome toho klice neziskal i to heslo. Pokud se bavime o nejakem hypotetickem malware bezicim na stanici uzivatele a ziskavajici privatni klice z disku, pak analogicky tam muze bezet i ten keylogger, zeano.
-
Ondra Satai NekolaZlatý podporovatelPak ti heslo nepomůže.
Pokud ti ten zašifrovaný klíč uteče jinak, tak to význam mít může...
-
aaa (neregistrovaný)
Ste si isti, ze cast o rychlosti prelomenia MD5 suvisi s ostatnym?
Ked tomu dobre rozumiem, tak je MD5 len funkcia na odvodenie kluca (KDF). Hash sa nikam neuklada. Takze rychlo ziskam kluc, skusim nim desifrovat privatny kluc - a dostanem nejaky vysledok. Potom treba stale zistit, ci ma vysledok strukturu privatneho kluca a aj ked ma, tak ci je to ten kluc ktory hladam.
MD5 by som v dnesnej dobe len tak nepouzival, ale AES by mal z dnesneho pohladu bezpecne zasifrovat text aj keby som heslo len rozsiril nulami a vobec nehashoval.
-
Ondřej CaletkaZlatý podporovatel
V článku se nepíše nic o prolamování MD5, ve smyslu hledání vstupu k existujícímu hashi, ani o rychlosti takového prolamování. Píše se tam o počtu MD5 operací za sekundu – to je určující faktor, který omezuje, kolik hesel je možné v určitém časovém období vyzkoušet. AES je rychlý algoritmus, takže moc nezáleží na tom, jestli máte k dispozici přímo MD5 hash, nebo musíte výsledným hashem nakrmit AES a teprve pak zjistit, jestli bylo heslo správné.
-
Ondřej CaletkaZlatý podporovatel
Serverové klíče nejsou šifrovány, takže novým formátem nic nezískáte. Nicméně můžete zkusit klíče smazat a zavolat
ssh-keygen -A -o. -
Proc se vracet k temer 5 let stare zalezitosti dostatecne popsane ve starych spisech z let 2013/2014: https://www.tedunangst.com/flak/post/new-openssh-key-format-and-bcrypt-pbkdf a https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html
Je docela na povazenou kolik ctenaru root.cz je prekvapeno tim, co ted "objevili"...
