Délka hesla - proč taková omezení?!

31.3.2007 14:57 | Software

Ze začátku jsem používal krátké heslo, ale po par přečtených článcích o tom že 7místné heslo není moc bezpečné, přešel jsem na delší.
Neměl jsem s tím nikde problémy, ale pak jsem narazil na servery které omezují délku hesla. Bohužel mezi nimi je i abclinuxu.cz.

Rozhodně jsem pro to aby si každý mohl nastavit heslo jaké chce(s všemi @#$%^&*() možnými znaky) a nebyl omezován délkou. Heslo které má například 20znaků (např: "xm_19#90.rwx.linuxro") nemám možnost ani použít! A hlavně, pokud člověk to xx místné heslo používá na více místech stejné, tak jenom kvůli těm pár serverům si musí pamatovat další heslo.


0K1AS        

Anketa

Komentáře

[Michal Kubeček]

U některých hashovacích algoritmů je délka hesla omezena z principu - např. pro DES na osm znaků (a z nich se ještě ořežou nejvyšší bity), u někerých jiných na šestnáct. Většinou systém delší heslo povolí, ale "přebytečné" znaky jsou ignorovány, takže pokud se v nich spletete, nepozná se to.

[David Heidelberg]

Dobře, ale proč není možné použít nějaký systém, který to neomezuje?

[Michal Kubeček]

Jednak může být problém ve škále dostupných hashovacích algoritmů, které nabízejí dostupné knihovny. Dále maximální (efektivní) délka hesla není jediným kritériem; celkem chápu, že je-li na výběr mezi MD5 (délka prakticky neomezená, John the Ripper 8671 hesel za sekundu) a Blowfish (efektivní délka hesla 16 znaků, John the Ripper 358 hesel za sekundu), dá leckdo přednost Blowfishi, protože těch 16 znaků považuje za více než dostatečnou délku.

Mimochodem, pokud je řeč o HTTP Basic Authentication, připadají mi podobné úvahy poněkud bezpředmětné…

[Tom K]

jak jsem psal dole, DES ani blowfish nejsou hashovaci, ale symetricke sifrovaci algoritmy. Jejich pouziti pro ulozeni hesla je velky historicky omyl. Bezne hash algoritmy (MD5, SHA1, SHA2 a dalsi) samozrejme nemaji omezeni pro delku vstupujicich dat.
Pokud se bavime o HTTP Basic over SSL, tak to porad jisty predmet ma.

[Jardík]

By nebylo špatné heslo enkódovat pomocí base64, spočítat md5 tohoto hesla a výsledek uložit jako "skutečné heslo". Až by se uživatel přihlašoval se zadaným heslem, zase by se na něj použilo base64, md5 a výsledky se porovnaly.

[Tom K]

ehm.
jen rypava poznamka. Od kdy patri DES mezi hash algoritmy ?

[Tom K]

A blowfish to same v blede modrem.

[Michal Kubeček]

AFAIK někdy od sedmdesátých let. Dnes už se ovšem u téměř žádných novějších systémů nepoužívá.

Když už si chcete hrát na chytrého, měl byste být schopen rozlišit mezi označením DES jako symetrické blokové šifry a označením DES coby algoritmu pro hashování hesel. Nebo si snad myslíte, že to, co se při hashování hesel označuje jako "MD5" je algoritmus MD5, tak, jak je popsán v RFC 1321?

[Tom K]

Ja si nehodlam hrat na chytreho. To, ze se DES a jine blokove sifry pouzivaji, pro bezpecne ulozeni hesla z nich HASH funkci proste neudela. Muzeme s tim nesouhlasit, muzeme proti tomu protestovat, ale to je asi tak vsechno, co s tim muzeme delat. To, co se pouziva pod nazvem MD5 aspon umoznuje jako vstup pouzit velmi malo omezeny retezec a je to zalozene na MD5 HASH algoritmu.

[mrzout]

Melo by te vic trapit, ze hesla jsou ukladana nazhashovana v notrmalni textove forme. Praxe ukazuje, ze vetsina uzivatelu pouziva stejne prihlasovaci udaje pro vice sluzeb, tedy timto utocnik ziska pristup k datum uzivatelu i na jinych sluzbach.

[David Heidelberg]

no ano, ovsem pokud budu registrovany na dejme tomu uz 20serverech, tak pro kazdy mit jine heslo(tedy spis si ho zapamatovat) je pomerne velky problem.

0K1AS

[Filip Jirsák]

To je proto, že ve většině síťových protokolů je jako základ pro výpočet hashe, který se přenáší po síti, použit otevřený tvar hesla, nikoli jeho hash, a už vůbec ne hash s volitelným parametrem (aby pro stejné heslo měl každý server jiný hash). V podstatě jediný používanější protokol, který v challenge-response nepoužívá přímo heslo, ale jeho hash, je NTLM. A ten ještě používá hash vytvořený jen z hesla, není tam žádný parametr serveru, takže hash uloupený z jednoho serveru můžete použít pro autentizaci ke kterémukoli jinému serveru.

[stativ]

Při použití challenge-response je ale pak problém vypočítat ten hash. Nevím o žádném jiném způsobu než pomocí java scriptu (osobně takový i používám). Pak ale stačí někdo s vyplým js a už se zase přenáší plain text heslo.

[Filip Jirsák]

Ten způsob je vypočítat to třeba v C, C++, Javě nebo čemkoli jiném – nebavíme se totiž pouze o HTTP V případě HTTP (ale i spousty jiných protokolů) by to znamenalo do standardu přidat nový způsob posílání autentizačních údajů, takže třeba u HTTP by k metodám Basic a Digest přibyla další.

[petr_p]

Nechci se hadat, ale proc pri HTTP metode Digest zasila server sul? Ze by proto, aby se zabranilo utokou prehranim? Aby autentizacni retezec byl pokazde jiny?

[Filip Jirsák]

Aby nebylo nutné ukládat heslo v otevřeném tvaru na serveru ani jej přenášet po síti, potřebujete 2 různé „soli“ – jednu pro uložení hesla na server (aby jedno heslo mělo na každém serveru jiný hash) a druhou pro on-line transakci (aby relace výzva–odpověď byla pokaždé jiná). HTTP Digest má pouze tu druhou složku (tedy výzva je pokaždé jiná), ale jako základ se bere heslo v otevřeném tvaru, nikoli jeho hash.

Nyní HTTP Digest vypadá zhruba takhle:

S spočítá si hash(heslo+salt) ← tady server potřebuje znát původní heslo
S→K: salt=123456
K→S: hash(heslo+salt)
Server zkontroluje, zda klientem poslaný hash odpovídá tomu, který si sám spočítal.

První možná změna (která už ale vyžaduje zásah do protokolu) by byla, že se místo hesla použije jeho hash – server si tak nebude muset pamatovat otevřený tvar hesla:

S spočítá si hash2(hash1(heslo)+salt) ← serveru stačí uložený hash1(heslo)
S→K: salt=123456
K→S: hash2(hash1(heslo)+salt)
Server zkontroluje, zda klientem poslaný hash odpovídá tomu, který si sám spočítal.

Ale pokud by uživatel použil stejné heslo na více serverech, bude uložený hash1(heslo) na těch serverech stejný, a jeho získání by vzhledem k těmto serverům bylo ekvivalentní získání hesla.

Takže by bylo potřeba použít třetí variantu

S spočítá si hash2(hash1(heslo+salt1)+salt2) ← serveru stačí uložený hash1(heslo+salt1) a salt1
S→K: salt1=123456, salt2= 789012 ← salt1 zůstává stále stejný (pro 1 serevr), salt2 se mění s každým požadavkem
K→S: hash2(hash1(heslo+salt1)+salt2)
Server zkontroluje, zda klientem poslaný hash odpovídá tomu, který si sám spočítal.

[petr_p]

Dekuji za vysvetleni. Spatne jsem vas pochopil. Samozrejme mate pravdu.

[Filip Jirsák]

Délka hesla bude vždy omezena – určitě např. kapacitou harddisku, daleko spíš ale třeba velikostí příslušného sloupce v databázi. 12 vám připadá málo – kolik znaků tedy bude stačit? 32? 255? 1024?

[Luboš Doležel (Doli)]

32 na MD5 hash.

[Leoš Literák]

Toz si to dejte do bugzilly, treba k te chybe, ze abicko uklada plain text hesla. Akorat to bude znamenat drobnou zmenu DB schematu.

[David Heidelberg]

+1

32 by melo 100procentne stacit... i kdyz nekdo by mohl uvitat i 255, ale to by psal heslo hooodne dlouho

[Ivanhoej]

Wow, to vazne abicko uklada plain hesla?

[Käyttäjä 11133]

Jo, nebo si snad vážně myslíš, že když zapomeneš heslo, tak že ho server začne crackovat z nějakého hashe, aby ti ho mohl poslat?

[Filip Jirsák]

Kdyby Abíčko zase někdy hodlalo být pomalé, svedeme to na to, že si někdo zrovna nechal zaslat svoje 12znakové heslo

[blogsm]

Spíš pošle nové heslo. staré (pouze hash) se nahradí novým

[Filip Jirsák]

Což znamená mimo jiné pamatovat si vyžádaná hesla (spíš jednorázové klíče pro změnu hesla), umožnit uživateli s takovým jednorázovým klíčem heslo opravdu změnit, nepoužité jednorázové klíče po nějaké době mazat, nedovolit zasílat jednorázový klíč moc často na stejnou adresu atd. To jen aby bylo zřejmé, že nejde jen o to nahradit heslo jeho hashem…

Nelze změnit přímo heslo uživatele v databázi, protože o zaslání hesla na váš e-mail může taky požádat někdo jiný, než vy – tím by se vám heslo změnilo, a vy byste musel do e-mailu, a heslo si nastavit zpátky (pokud by vás vůbec napadlo nové heslo hledat v e-mailech, když jste o žádné nežádal). Případně budete netrpělivý, e-mail s heslem nedorazí hned, nechá te si heslo vygenerovat ještě jednou – a mezi tím dorazí první e-mail, vy se zkusíte přihlásit novým heslem, ale to už neplatí, protože bylo vygenerováno nové heslo pro druhou žádost…

[otula]

To, že na tomto serveru nelze zadat dlouhá hesla, není podle mne nijak velký problém. V podstatě o nic nejde. Víc mne ale šokovalo, když jsem chtěl použít paranoidní heslo u Reiffeisen Bank a nepustilo mne to přes nějakých 14 znaků a nepovolilo mi to jiné znaky, než číslice a písmena

[David Heidelberg]

samozrejme nemluvim jenom o tomto serveru... jinak doporucuji CSOB ty to maji jen 5 cislic a to je maximum

[Tom K]

U bank je bezpecnost navic zajistena jeste poctem pokusu, ktere mate k dispozici. Pravdepodobnost, ze se pri 5-ti cislicich trefite v jednom ze tri pokusu neni zrovna velka a aspon je tu sance, ze si to lidi nebudou psat na papirek pod klavesnici (to muze byt jeste horsi). Ale osobne taky davam prednost delsimu heslu. Jinak 14 znaku, kdyz v nich jsou male pismena a cisla je 36^14 kombinaci, coz je cca 72 bitu, to bych hrubou silou opravdu lamat nechtel.

[otula]

No jo, jenže kdo si má pamatovat další heslo - chtěl jsem použít heslo, které mělo být dohromady na 3 zcela rozdílných a oddělených místech (a bankovnictví jediné na internetu), a takhle jsem musel vymýšlet něco kratšího. Jako silná hesla využívám první písmena + interpunkční znaménka, a tady mne to prostě zkrouhlo