Názory k článku Heslo není všelék: Zaútočte na hashe i dokumenty
-
Malý příklad na zaheslovaném .zipu...
Potřeboval jsem nedávno rozbalit jeden .zip, tak jsem na to poštval nějaký ten Archive Password Recovery (jiný než ten v článku zmiňovaný). Omezil jsem to tuším na ~10 znaků hesla, std. isalnum() != 0 znaky + '_', možná jako první nastoupil slovníkový útok. Na celkem starém nb pod wine to za necelou půlhodinu ze sebe vysoukalo dvanáctibytový hash.
V tu chvíli jsem na nějakou dobu skončil, protože prozrazení hesla k hashi je placená funkce toho softu. Pak mě ale napadlo kouknout do zdrojáků unzipu, jak to je uděláno; ten hash samozřejmě stačil, takže mírně upraveným unzipem jsem archiv nakonec rozbalil.
Možná by tedy v článku mohla být i zmínka o tom, že spoléhání na security through obscurity (zde konkrétně na neznalost algoritmu) jako na bezpečnostní prvek je zejména v případě opensource liché.
-
1) "s výhodou lze posílat nebo uchovávat heslo v podobě výsledného hash kódu a při autentizaci tento otisk porovnávat s otiskem uživatelova aktuálního vstupu. Na minimum se tak omezí použití nezabezpečené plain-text formy, která sama o sobě svádí ke všem variantám útoku man in the middle." - Mohl by prosím autor napsat, jak si představuje, že využití vlastnosti jednosměrnosti omezí útoky typu main-in-the-middle? Já bych řekl, že to útokům MITM nebrání vůbec, útočníkovi může být zcela lhostejné, jestli zachytává přímo heslo nebo nějaký jeho hash - co zachytí, to přepošle skutečnému serveru.
2) "Správný hash kód totiž díky bezkoliznosti mohl vzniknout pouze ze správného hesla." - Bezkoliznost je obvykle definována tak, že k zadanému plaintextu nedokážeme najít další plaintext se stejným heslem, ne že takový plaintext neexistuje.
3) "Nízká datová náročnost" - Jasně, místo pětiznakového hesla použijeme 16tibajtový (nebo i delší) hash a ušetříme. Fixní délku jako bonus beru, ale nazývat to "nízkou datovou náročností"?
