„Je tedy potřeba se ptát, jak jsou tajné klíče chráněny proti odcizení. Odpověď je možná trochu překvapivá: Nijak zvlášť chráněny nejsou. V případě Google Authenticatoru pro Android jsou klíče uloženy v SQLite databázi, do které mají přístup přinejmenším všechny procesy s oprávněním roota:“
Jak lépe by šel klíč v telefonu zabezpečit? Když útočník získá roota, už nepomůže ani svěcená voda.
Protože to nijak nepomůže proti scénáři „někdo získal roota“. Když si to nevyčte z databáze, tak si to vyzobne z paměti. Neexistuje způsob, jak se taková aplikace může rootovi bránit.
Navíc, jak bylo zdůrazněno, jde o doplněk bezpečnosti. Pokud máte někoho cizího v počítači i v telefonu, tak máte větší problém, než jen vycucnutý vektor autentizátoru.
Pomůže. Pokud se potřebuji připojit např. v cizině v kavárně, bude tam keylogger a ještě mi pak ukradnou rootnutý telefon, mám smůlu. Pokud musím zadat další heslo pro přístup do aplikace autentifikátoru (podobně jako do keepass), ukradený telefon jim nepomůže (že by to zrovna bylo v paměti a uměli to z ní dostat je už dost scifi).
Snadno překonatelné v tomhle případě znamená „ukradnu ti telefon a ještě heslo“. Je to cílené proti dnes nejrozšířenějšímu útoku na dálku. Tedy proti úniku hesla. V takové situaci je mobil neprůstřelné řešení.
Pokud ztratíte mobil, není to riziko. Pokud vám někdo na internetu odcizí heslo, není to riziko. Takže je to velmi dobrá metoda. Proti cílenému fyzickému útoku na konkrétní osobu se brání obecně velmi špatně.
Tak urcite, ale proc to delat utocnikovi zbytecne lehke, kdyby se ty data do DB ukladali zasifrovane, tak by si krome precteni DB musel utocnik jeste dekodovat i aplikaci aby ho umel odkodovat. (mirne to zuzi skupinu lidi kteri se k tomu dostanou, i kdyz uprimne, kdo se dostane k cizimu rootu, tak uz asi zvladne i RE javovske aplikace, to neni jako v dobach 8bitu a odstranovani protikopirovacich ochran kde strojovy kod pouzival vsechny mozne HW triky aby rozpoznal pripadne pokusy o trasovani a u nekterych to slo rozumne prolomit jen na papire simulovanim s tuzkou v ruce a pocitanim taktu... :D, proti tomu je prohlizeni Javovskych .class skoro jako komentovany zdrojak :) )
No ale token se pouziva prave pro pripad kompromitace hesla. Tudiz, otazka neni jak ochrani ucet "heslo s tokenem" ale pouze jak ucet ochrani "samotny token".
Taky mi neni uplne jasne, proc chteji nejdriv heslo a pak, az teprve po jeho overeni, chteji token. Meli by chtit vsechno naraz. Tedy, zeptat se na jemeno/heslo, a potom, bez ohledu na to, jestli heslo sedi, se zeptat na token.
A jako spravny hnidopich bych tu mel drobnou vyhradu k vypoctu kodu.
v souboru: pam_google_authenticator.c:1007
1001 unsigned int truncatedHash = 0;
...
1007 truncatedHash &= 0x7FFFFFFF;
1008 truncatedHash %= 1000000;
return truncatedHash;
truncatedHash & 0x7FFFFFFF neni rozhodne delitelny 10^6, tudiz, nektere z generovanych kodu jsou vice pravdepodobne nez jine. Je to vada sice spise teoreticka, ale vada to je.
Take neni dobre si delat iluze nad nejakym zvysenym bezpecim v internetove kavarne. Keylogger vas sice neohrozi, ale gmail stejne pouziva cookie, kterou si drzi v sobe prohlizec. Ukrast tuhle cookie neni pro admina v takove kavarne zadny problem.
Možná mi něco uniklo, ale tímto Google získává spárování účtu s mobilem uživatele, tzn. další významný zdroj potenciálně zneužitelných informací. Netvrdím že už existuje propojení dat s mobilními operátory, ale ta možnost absolutní kontroly nad komunikací a polohou osoby se tu nabízí.
ě
Mimochodem, jediné oprávnění, které chce Google Authenticator, je řízení vibrací. Neříkám, že aplikace technicky nemá šanci data vyzradit:
* confused deputy (např. otevře se adresa v prohlížeči) - toho si uživatel může všimnout a Google se těžko do nečeho takového pustí
* komunikace s jinou aplikací (s dostatečným oprávněním) od stejného výrobce - pokud někdo používá Android, tak Googlu asi věří tak jako tak...
No to je vyborne, zrovna jsem sem chtel napsat neco v tomhle smyslu :-)
Zkracene: nefunguje to se SELinuxem, a nefunguje to se zapnutou RSA key autentizaci v sshd.
Co je horsi, ze treba na rozdil od ctecek otisku prstu si to uklada autentizacni udaje do $HOME, takze pokud utocnik ma moznost nejakym zpusobem napadnout muj domovsky adresar, ziskava moznost nastavit si klic pro to jednorazove heslo, a rozsirit tento prunik i na bezne autentizovane pristupy.
Diskutoval jsem to v bugzille Fedory, kde byl s vyse uvedenou namitkou souhlas, ale zaroven maintainer baliku psal, ze upstream prilis nekomunikuje, takze nadeje na zmenu bez vlastniho pricineni jsou docela male.
Zaverem: G-A je v soucasne podobe nepouzitelny.
-Y.
- nefunguje to se zapnutou RSA key autentizaci v sshd…
Jak by to mělo fungovat s RSA key autentizací? Při přihlášení SSH klíčem sshd celý PAM obchází, to je naprosto obecná vlastnost OpenSSH. Když SSH klíč nemám, přes keyboard-interactive se bez problému přihlásím i se dvěma hesly.
Navíc RSA login je dvoufaktorový už sám o sobě, pokud uživatel používá šifrovaný SSH klíč, a díky asymetrické povaze také mnohem bezpečnější než HOTP/TOTP.
Polohu řídicích souborů je možné změnit, na druhou stranu, pokud má mít uživatel možnost vygenerovat si kdykoli nový tajný klíč, je jedno kde řídicí soubor leží.
> Polohu řídicích souborů je možné změnit, na druhou stranu, pokud má mít uživatel
> možnost vygenerovat si kdykoli nový tajný klíč, je jedno kde řídicí soubor leží.
Zkuste se zamyslet, proč máte heslo v /etc/shadow (root:shadow 0400) a ne v home.
Pro OTP data platí podobné důvody.
-Yenya
Četl sem jen letmo, ale pochopil sem dobře, že se jedná prakticky jen o použití druhého sdíleného hesla se serverem soleného časem a pro pohodlnost a distribuci autentizačního procesu na víc zařízení (těžší kompromitovat než pouze počítač) k tomu google napsal aplikaci pro androida?
Je to ta hlavní myšlenka, nebo mi něco zásadního uteklo? Děkuji