Předchozí stránka je věnována heslům z pohledu uživatele, na této stránce je několik stručných poznámek k heslům z pohledu administrátora a z pohledu tvůrce webových stránek.

Hesla z pohledu administrátora

K administrátorům mám jen jednu poznámku, hodně z nich má tendenci nastavovat až nesmyslně přísné podmínky pro uživatelská hesla. Podle mého názoru to ovšem nevede ke zvýšení bezpečnosti. Hezky to ilustruje jeden komentář u článku na Lupě, odkazovaného v perexu:

Admin: 6 znaku
user: qwerty
Admin: 6 znaku a cislo
user: qwerty1
Admin 6 znaku, cislo, velke pismeno
user: Qwerty1
Admin: 8 znaku, cislo, velke pismeno, ne pismeno
user: Qwerty1+
Admin: 8 znaku, cislo, velke pismeno, ne pismeno + menit kazdy mesic
user: napise si heslo na papirek a prilepi na monitor

Dost podobně to ve skutečnosti funguje. Ještě horší je, že to k tomu lepení papírku na monitor donutí i pokročilejší uživatele, kteří mají relativně bezpečné heslo, které ale z nějakého důvodu nevyhovuje administrátorem nastaveným podmínkám. Podle mých zkušeností je nejhorší kombinace nutnosti si relativně často měnit heslo a podmínky, že heslo nesmí být stejné jako určitý počet předchozích. To pak vede uživatele k tomu, že mají hesla třeba "leden2007", "únor2007", atd.

Co dělat s uživateli, kteří mají stále heslo typu qwerty, toť otázka, ale podle mého názoru neustálé zpřísňování podmínek situaci spíše zhoršuje než zlepšuje.

Hesla z pohledu tvůrce webových stránek

Téma ukládání hesel na webových stránkách by bylo na samostatný článek, zde zmíním jen základní rady:

• Nikdy neukládejte hesla uživatelů do databáze přímo. Zásadně se ukládá jen hash hesla (například md5, i když to už ta je už dnes prolomená).
• Ještě bezpečnější než hash je tzv. solený hash. Uživatel zadá heslo, k němu se připojí nějaký náhodný řetězec, tzv. sůl. Ze spojeného řetězce se vygeneruje hash a uloží se do databáze. Současně se uloží do databáze i sůl. Při kontrole hesla se z databáze přečte sůl, připojí k heslu, které zadal uživatel, vygeneruje hash a porovná s heslem v databázi. Příklad: uživatel zadá heslo "heslo", vygeneruje se sůl například "s8F", z řetězce "heslos8F" se vygeneruje hash, do databáze se uloží hash a sůl: "s8F". Při kontrole hesla uživatel zadá "heslo", z databáze se přečte "s8F", připojí k heslo, vygeneruje hash, porovná a přihlášení vyhodnotí jako úspěšné. Výhodou soleného hashe je, že pokud mají dva uživatelé stejné heslo, ale různou sůl, není z hashe poznat, že mají stejné heslo. Druhá výhoda je, že se ztíží prolomení hesla- i když útočník nějakým způsobem získá hash hesla a podle toho hashe získá kolizní řetězec, ten mu bude na nic, protože samotné zadávané heslo neodpovídá hashi uloženému v databázi.
• Většinou není třeba být přehnaně přísný v požadavcích na uživatelská hesla. Například pokud jde o přihlášení pro napsání příspěvku do knihy návštěv, je zcestné požadovat třeba 12 znakové heslo neobsahující pouze písmena a ještě kontrolované podle slovníku. Požadavky na bezpečnost hesla by měly odpovídat tomu, o jak kritickou aplikaci jde. Předpokládám, že například projektant Internetového bankovnictví nebude mít tento článek jako hlavní zdroj informací ohledně bezpečnosti hesel, to by bylo smutné.