Názory k článku USB token: pamatuje si hesla a šifruje. Útok zabere dvě a půl minuty

Má to jednu nevýhodu: Pokud někdo ten algoritmus zjistí, tak jsou okamžitě prolomena všechna hesla (kromě těch "hesel pro speciální účely"). Třeba u řešení pomocí bookmarkletu v browseru tohle riziko reálně hrozí - kdo z nás odmítne kamaráda nebo příbuzného pustit k počítači "na dvě minuty, abych si mohl zkontrolovat poštu"?

No tak když mě někdo blízký žádá o přístup k počítači, že si chce vybrat poštu, tak neváhám ani minutu a přehlásím se do jiného a omezeného účtu, než ho k tomu pustím.
A totéž bych doporučil všem ostatním.
Nicméně je fakt, že když mě požádá o přístup k počítači, že si chce jenom přečíst zprávy, nebo najít dopravní spojení, tak ho často pustím do svého účtu a ne vždy mu stojím za zadkem.

pokud na zobrazení těch hesel použijete jinou abecedu než je latinka (nějaký ten rozsypaný čaj) tak je lístek vedle monitoru celkem bezpečná alternativa xD

Nejsem v tokenech zběhlý, ale autor článku nejdřív popisuje spoustu hesel které mám k různým službám, ale jakmile hovoří o tokenu, popisuje jen podepsání elektronické pošty.

K el.podpisu a přihlášení do internetbankingu token znám, ale jak mi umožní uchovat moje hesla k dalším desítkám webů a služeb? Je k tokenu nějaký software? Jak je toto řešeno - to jsem v článku nenašel a tak vlastně vůbec nevím, jestli je pro mne token vhodnou alternativou.

Nebo měl článek říct něco úplně jiného?

alternativou neni, to s heslama byla jen takova omacka:)

Běžný token je pro uchovávání hesel k ničemu.

Pro služby, které ho podporují, je docela zajímavou hračkou Yubikey:
http://www.pepak.net/bezpecnost/yubikey-v2-0/

Alternativou je pro provozovatele sluzby, ktery muze namisto prihlaseni heslem implementovat prihlaseni certifikatem. Ten je technicky totozny s elektronickym podpisem. (Funguje tak ze server posle nahodny retezec, prohlizec uzivatele ho "podepise" a podpis posle jako odpoved)

Token mi prijde jako nespolehliva alternativa... a IB (internet banking) bych ho nepouzival... PIN vam odkoukne kde kdo a pak staci chvilka nepozornosti a je problem...

Nechapu ze vsechny IB transakce nejsou vazany alespon na potvrzovaci SMS... neni to sice vsehospasny nastroj ale omezi ruzne spy utoky (keyloggery atp.)

Co me ale desi ze vseho nejvice je jednoduchost s jakou prochazi platby kartou pres internet... jen zadate cislo karty jeji platnost a opisete par cisel ze zadni strany... divim se ze takovych utoku neni mnohem vice kdyz si vemete ze kartu si muze prohlednout kde kdo (treba kdyz platite na vlakovem nadrazi pani si dokonce bere kartu do okynka kde ani poradne nevidite co s ni dela) podle me by vsechny tyhle IB mely prave projit aspon autorizacni SMS

Úplně by stačilo to, co bylo v zákoně o platebním styku až do loňského listopadu: že za veškeré transakce, u kterých není přítomna karta nebo není použit PIN, odpovídá ten, kdo kartu vydal.

Dnes už to v zákoně není, ale víceméně to funguje i dobrovolně (banky obvykle škodu radši zaplatí ze svého než aby to nechaly příliš rozmazat v médiích).

Moje autorizacni sms chodi v sifrovany podobe, na simtoolkit a jsou chraneny dalsim pinem. Pocitam, ze nejaky usb utok by na to sel v zavislosti na typu telefonu, protoze mozny je (teoreticky) vsechno. Otazka zni, jestli by se vyplatil s ohledem na to, ze vysledkem bude jen moznost se prihlasit k uctu (pokud se ja neprihlasim driv), nebo potvrdit MOJI bankovni operaci, protoze ta autorizace je pomerne zavisla na castce a cisle protiuctu, a navic jednorazova, mam pocit (ale uznavam, jist si nejsem.

Těším se, až budeme všichni očipovaní, a nebude potřeba pamatovat si nějaká hesla.

Jen aby mi pak nějakej hacker neusekl ve spánku ruku...

Jaká je vlastně pointa? Autor popsal teoretické útoky na USB tokeny, ale prakticky nic konkrétního. A z toho si mám vyvodit, že USB tokeny nejsou bezpečné?
Takže když prohlásím, že na nějaký trezor BY se dalo zaútočit tak a tak, tak trezor není bezpečný?

Pokud někdo prokáže, že trezory X, Y a Z jde během sekund až minut otevřít, je to přinejmenším důvod k zamyšlení - pokud takový trezor máte, tak určitě, a i u ostatních byste měl přinejmenším popřemýšlet o tom, nakolik se liší od těch postižených modelů...

Většina trezorů, co máte doma, se s použitím nářadí otevře do 10 minut. Ostatně i bankovní trezory jsou certifikované na to, aby útoku vzdorovaly několik málo hodit. A vtip je v tom, že za pár desítek minut jsou na místě kukláči a útok zastavují starým dobrým násilím.

Na rozdíl toho u IT lidi očekávájí bůhvíproč zabezpečení, které samo o sobě útoku dokáže odolávat roky a stačí ho jednou zajistit a už se nemusím o nic starat. Nějak nám všem imponují čísla o tom, jak dlouho by trvalo vyzkoušet všechny klíče nebo faktorovat public key...

V reálném světě stejně jako v kybersvětě jsou potřeba všechny tři kroky: prevence útoku, detekce útoku a odpověď na útok.

V zivote by me nenapadlo, ze nekdo pouzije v tokenu externi I2C EEPROM. Spousta procesoru uz dnes ma EEPROM primo na cipu a nabouravat se dovnit nanometrove strukuty je preci jen neco jineho.
Predpokladam ze tento token je vyjimka.

Ani externi EEPROM neni problem. Pokud je vse spravne kryptograficky osetreno, tak moznost cist/zapisovat EEPROM jinym nastrojem nicemu nepomuze. Zjevne to maji vyreseno spatne.

Ale pomuze, minimalne muzu tu EEPROMku zalohovat. Jinak receno muzu mit tech napriklad 10 pokusu o uhadnuti hesla znovu a znovu.

Já používám KeePass (http://keepass.info/) databázi mám uloženou na 8GB MicroSDHC kartě. Tuto kartu navíc synchronizuji přes BT na identickou kartu v telefonu. V telefonu mám i Javovou aplikaci KeePass a tak mám hesla kdkoliv po ruce (pravda otvírání-rozšifrování souboru v telefonu trvá několik minut) Dále mám na těchto kartách důležité programy a data. Na klíčence mám redukci MicroSD->USB. Takže jsem kdykoliv a kdekoliv v pohodě a když například chcípne HDD na notebooku nemusím se strachovat, že moje citlivá data někdo zneužije. Kartu vždy vyndám ať si technici v opravně čmuchají :)

Jsem lehce podobného názoru – hesla mám stále při sobě, zamčená silným šifrováním (přes heslo, které nikdy nikde jinde nepoužívám), zároveň ale kdykoli mohu ověřit kterékoli z nich. Konkrétně mohu doporučit aplikaci SPB Wallet pro WinMobile a PC.

Pro základní ochranu stovek hesel (kdo ví k čemu všemu) to považuji za dostatečné. Ano, průmyslový standard to není (synchronizuji totiž zamčenou databázi s PC klientem, abych nikdy nezůstal na holičkách, bez hesel), ale než nosit USB, když stejně tahám mobil…

No sync přes BT je určitě úžasný, je to stejná zábava jak lámat WEP/WPA na wifi :-)), takže stále zastávám názor lepší pořádný token zalitý v epoxu a jinak tak i tak když s eněkdo bude chtít dostat k datum tak se dostane...je to asi jako zámková vložka za milion, která bránila v době kdy ještě zloději nešli po mechanismu okolo :-))) ale je fakt že privátní data pokud nekoho nepálí a není zájem tak se dají uchovat bezpečně :-)

nebudu hodnotit autorovy znalosti, ale pojmy s dojmy...
ad iKey2000) když už iKey, tak se rozhodně podívám po FIPS formátu tokenu a ne po pouťovém přívěšku jakým iKey2000/3000 je. Ten vznikl jako důsledek požadavku většinou právě bankovních domů jako levný autentizátor s kryptofunkcemi. Pokud vím ani se nenabízí ve FIPS verzi. K tomu jsou určeny deriváty 2032, nebo 4000. Tam je situace trochu jiná..
ad brutal force) jak chete použít brutal force útok na zařízení u kterého si můžete nastavit maximální možný počet neúspěšných pokusů? Pokud je někdo truhlík, tak to prostě nechá k volnému použití..
ad hesla) zcela jistě máte na mysli generátory OTP (tzv. One Time Password). No abych řekl pravdu tady je situace do značné míry omezena přístupem Microsoftu protože nedokáže implementovat jisté funkce do již existujících struktur svých systémů, ale dá se... dá se použít na perimetrech, web aplikacích apod. Ideálně ve funkci kdy jednu část kódu generuje samotný token a druhou část kódu zabezpečeá stanice nebo obyčejná SMS. Technologie jsou, ale zájem o ně moc není protože zkrátka něco stojí... a banky? Jste pro ně malé ryby, tohle pro Vás rozhodně nevemou.
ad keyloger a softataky) no každý svého štěstí strůjce. Pokud si někdo nedokáže ohlídat použití HW keylogeru, soft keylogeru, přítomnost škodlivého kódu ve své síti, asi by neměl dělat v IT. Tohle jsou základy bezpečnosti..

Co závěrem? Jaké jsou tedy možnosti? Zahodit schéma SC do koše? Já myslím že ne. Není ho čím nahradit. USN+PSW je prostě dávno mimo mísu, ale nutit uživatele aby se přihlašovali některou jinou metodou? Obtížně, protože prostě Microsoft (na Linďoura zapomeňte, ten je rád že to API pro iKey vůbec obslouží). Jaksi se totiž pozapomělo například na to jak autentizovat uživatele na mobilkách vůči exchange když vynutíte autentizaci by cokoliv. A takových drobných kolizí je velká řada. A Exchange 2010 to taky zazdil. Z toho plyne že ani biometrika není tou ideální volbou... Zkrátka dokud nepohne MS zadkem, asi budeme stále lézt po stromech.

Mimochodem správce hesel.... k důležitým aplikacím? Jedině v aktivce... představa že mi uživatel nosí na kartě společně přihlašovací certifikát, podpisový certifikát a ještě hesla do mých vitálních aplikací mně děsí... Hezky rozvrstvit.. Přihlašovací certifikát na kartu, podpisový do TPM a hesla pěkně do aktivky. A ještě tak aby uživatel vůbec nevěděl jaká hesla kam má...

Mno, jukněte sem a rozklikněte si "Co je to ALUCID"
https://www.kultura-evropa.eu/_layouts/login1.aspx

Těžko říct jak přesně to funguje, každopádně:

1. Je potřeba instalovat nebo spustit jejich proxy -> může být problém s právy + nebude fungovat na všech platformách.

2. Zdá se, že Alucid nejde použít kdekoliv - musí ho podporovat cílový server. To značně omezuje jeho uplatnění/rozšíření.

3. Z potřeby proxyny lze usuzovat, že součástí řešení je online ověření identity na serverech Alucid. To znamená, že jakmile vypadnou servery Alucidu, uživatel se nepřihlásí nikam; anebo jinak - identitu bude zřejmě možné ukrást buďto imitací serveru Alucid (DNS útok) nebo přímo nabouráním se do jejich systému (pokud by se to rozšířilo, tak není otázka *zda*, ale *kdy* k tomu dojde).
Poznámka: když už se musí implementovat podpora na straně serveru, ke kterému se přihlašuji, zdá se použití proxyny poněkud zbytečné...

4. Pokud se "identita" ukládá na fleshku, je otázka jak snadno je zcizitelná a jak lze řešit její případnou ztrátu/zničení (ztráta identity by nebyla optimálním řešením).

Věta, že iKey 3000 a vyšší fungují v Linuxu, není správná. Autor možná chtěl říct řada 3000. iKey 4000 nemá ovladač pro Linux.

Schopnosti řady 3000 končí na 1024b RSA. Což je nedostatečné pro kvalifikované podpisy.

Řada 4000 zase neumí SHA-2 (další zákonný požadavek). Pošta to tutlá přes emulaci v ovladači. Navíc emulace je jen v CryptoAPI ovladači. V PKCS#11 zřejmě není, protože přes toto rozhraní není možné certifikát s SHA-2 použít (zkoušeno s NSS z Firefoxu; 1024b RSA s SHA-1 stejným způsobem fungují).

Ano, autor je opravdu buď cestovatel v čase nebo naprostý šlendrián.
Článek popisuje tokeny staré 5-15 let, které jsou již minimálně 4 roky EOL - výrobcem určené jen k doprodeji (End of Life). Zároveň se odkazuje na staré výzkumy a testy.
Tokeny iKey 1000, iKey 2000 a iKey 3000 vždy podporovali jen RSA 1024bit a nejsou tudíž ani vhodné pro kvalifikovaný certifikát dle naší legislativy. Pro kvalifikovaný certifikát a tím pádem i pro autorem tolik zmiňovaný elektronický podpis se hodí iKey 2032 nebo iKey 4000. Ty jsou taktéž certifikované FIPS 140-2 úroveň 2 a úroveň 3. Fyzická bezpečnost je zajištěna novým "tělem" tokenu viz. www.askon.cz u všech modelů od roku 2007.
V dnešní době jsou tokeny preferovány právě pro svou dlouholetou výdrž a na rozdíl od čipových karet je není možné běžným způsobem poškodit (zlomit, ohnout, poškrábat).
Informace o podpoře OS jsou pak už úplný paskvil a doplňují autorovu neznalost.
Takhle bych se mohl rozepisovat dál a dál, téměř každá věta obsahuje nějaký nesmysl nebo nepřesnost. Chápu, že je třeba šířit počítačovou gramotnost, ale ne za každou cenu.