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í"?
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é.