Vlákno názorů k článku Co se stalo LastPass a jak vytvářet silná a zapamatovatel­ná hesla od erik80 - 1.co si myslite o pouzivani hesiel ktore maju...

Jop, taky mám nejraději OpenID a kde je možnost tam ho používám… dele­gované přes vlastní web.

Největší problém spatřuji v tom, že je nějaký prostředník, který ví na které weby se přihlašuji, kdy se tam přihlašuji a podobně. Raději bych si takový seznam nechával jen pro sebe.

Ad 2 – mělo, ale v praxi se to skoro nepoužívá. Takže by si to heslo musel zahashovat uživatel sám a vůči serveru pak jako heslo používat až ten hash.

Ad 3 – pokud jsou ty kódy na kartě vytištěné, stačí si jí přece okopírovat. Ale to opravdu dneska někdo používá? Já jsme popisoval dvoufaktorovou autentizaci na základě sdíleného klíče, např. TOTP nebo HOTP, která se dnes používá nejčastěji.

2) Hesla u klienta rozhodně… nejlepší způsob, pak si člověk může být i jistý, že heslo nezmizí po cestě (další lidi na stejné nezabezpečené síti, všichni ISP, …).

Zase ale na stránkách hashování javascriptem je naprostý unikát a je to na jedné z tisíců a zároveň může být javascript podvržený, takže by si ho měl klient sám prověřit (těžko představitelné že by to fakt někdo dělal, to je asi jako kontrola technického stavu vozidla před jízdou). Nebo v ideálním případě si musí uživatel hashovat sám svým vlastním programem (hrozná nuda a zdržení).

2) Sice nezmizí původní heslo, ale pokud se útočník dostane k hashi,tak může použít ten hash pro přihlášení. JavaScript navíc zrovna neumí nejlíp hashovat, trvá to příliš dlouho a WebCryptoAPI je teprve v přípravě, takže se pro přenos spíš používá HTTPS, které chrání nejenom přenos hesla, ale i session id a dalších celkem důležitých věcí. NAvíc je potřeba hashovat stejně zase na serveru, nehledě na to, jestli se hashuje na klientu nebo ne.

Na klientu se pak hashuje spíš jen ve speciálních případech, jako třeba LastPass.

Jasné, javascriptové hashe jsou vždycky pomalejší než stejný hash v jiném jazyce. Ale dají se nají i docela použitelné… třeba i BCrypt https://github.com/dcodeIO/bcrypt.js

Tomu aby se ale útočník se odchytnutým hashem mohl přihlásit se dá ale docela pěkně zabránit server vegeneruje pokaždé jiný náhodný token a ten pošle na klienta, ten provede hash(token+hash(hes­lo)) a tohle vrátí místo hesla serveru k tomu samozřejmně i uživatelské jméno a ten token. Server pak napřed zkontroluje jestli je to ten token co vygeneroval, a až pak jestli sedí heslo. No a zneplatní token, aby ho nebylo možné použít znovu.
Díky tomu bude ten hash co se posílá místo hesla pokaždé jiný a odchytnutá komunikace už takhle k přihlášení nepomůže. Útočník by musel mít dopředný přístup ke komunikaci server klient, ještě v průběhu přihlašování, pak nejsnáze upraví javascript tak, aby hash vůbec nedělal a heslo si normálně přečte, na tohle je popisovaný postup krátký.

Ad 1 – pokud někdo bude útočit přímo na vás, ty informace si snadno zjistí a takovéhle heslo určitě zařadí na seznam žhavých kandidátů.

Ad 2 – dnes se bohužel při registraci a prakticky při každém přihlášení předává heslo serveru v otevřeném tvaru. Tedy musíte počítat s tím, že správce serveru to vaše heslo zná. Správce serveru eBay, který uvidí heslo %wyt.| ZEX~ebay, si velice snadno domyslí, že má na GMailu zkusit %wyt.| ZEX~gmail.

Ad 3 – to přece nesouvisí s vícefaktorovou autentizací, ale se způsobem, jak se řeší ztracené přístupové údaje. Pokud se používají jednorázová hesla, bývá to vyřešené tak, že při registraci klíče dostanete několik kódů, které můžete použít v případě, že nedokážete získat jednorázové heslo. Tyhle klíče byste měl uchovat někde na bezpečném místě (buď v té obálce s master heslem popisované v článku, nebo – pokud chcete využít té dvoufaktorovosti – v jiné obálce umístěné stejným způsobem – tedy např. master heslo v trezoru a kódy u rodičů). V případě ztráty klíče pro generování jednorázových hesel se přihlásíte tím vygenerovaným kódem uchovávaným v obálce a klíč změníte.

Např. pro Android existuje aplikace Authenticator Plus, která slouží právě pro generování jednorázových hesel, a umí klíče synchronizovat např. přes Dropbox. Ovšem pozor na to, že pak zase bezpečnost závisí na tom, zda je dostatečně silné heslo, kterým jsou ta data chráněná.

Ad 4 – myslím, že tohle vědí všichni, kteří to s bezpečností myslí opravdu vážně. Vynucování změn hesla má zřejmě „vyřešit“ situace, kdy by někdo získal vaše heslo a vy se o tom nedozvíte – určitou dobu ho bude moci zneužívat, ale po změně hesla bude mít smůlu. Už samotný fakt, že bude mít nějakou dobu přístup k vašemu účtu a nezjistí se to, je obrovský průšvih. Ale hlavně, když se to nezjistilo, je velice pravděpodobné, že útočník dokáže stejným způsobem získat i nové heslo. Případně to heslo odvodí z toho předchozího stejným způsobem, jako to dělá uživatel. Takže bezpečnostní přínos je velmi malý (funguje to vlastně jen pro málo pravděpodobný případ, že někdo to heslo zjistí omylem), za to je velmi velké riziko, že taková politika povede k používání slabých hesel (bez ohledu na to, že jiná politika může vyžadovat formálně složitá hesla).