Omezujete delku hesla pri registraci na svem webu?

Zdravim, hodne webu ma ruzna omezeni v delce zadavaneho hesla, nekdo ma maximalne 8 nebo 16 a nekdo jen 32 znaku, z cehoz nektere weby omezuji heslo pouze na VELKA a mala pismena a cislice, bez specialnich znaku.Delate to taky? Proc?A proc povolit heslo s libovolnym poctem znaku (a specialnimi znaky)?Jsme hloupi ze povolujeme napriklad i takove heslo, delka 120 libovolnych znaku?ï@ô#¨ºH#3ôÄκ×bü£yGé)æ+Ó¯8kvÊ,£ô#BEðâc-H77e¸P3V½5äo;;<+9ÅL!Aï<çé0hä[Tk°`ªç²ä´°BÄÒç:±f6Ýi÷·íËLeõÎ×ÕεÜ!¼dX~Uùp°¹1úe4.Ñf

Nealokuje to náhodou viac bytov v databáze?

Nevidim dovod to obmedzovate

snad nechceš ukládat heslo v databázi v plaintextu?! Nealokuje, hashe hesel mají pevnou délku.- hodně záleží na funkci, kterou heslo hashuješ. Bcrypt například odřezává ze vstupu prvních 55 znaků, zbytek ignoruje.- čím delší heslo, tím je výpočet kryptograficky vhodného hashe náročnější a vystavuješ server riziku DoS útoku (přetížení posíláním příliš dlouhých hesel na přihlašovací formulář)- každý uživatelský vstup, který zpracováváš, musí mít validaci na svojí délku, tj. nějakou mez musíš určit. PHP nedokáže zpracovat libovolně velký POST a jeho velikost je v configu, minimálně bys neměl tuhle hodnotu překročit a uživateli zobrazit lidskou hlášku než "IT error"V závislosti na zvolém způsobu hashování hesla bych volil něco mezi 32 až 64 znaky jako maximum.---------- Příspěvek doplněn 12.03.2016 v 22:45 ----------jinak v omezování znaků nevidím důvod, zpracování hesel musí být binary safe v každém případě. Je jediné riziko, že si uživatel zvolí heslo, které není v některých případech schopný zadat (cizí počítač, mobil), je dobré alespoň javascriptem upozornit, že používá speciální znaky, které neumožňují běžné třeba mobilní klávesnice zadávat. Pár takových případů na supportu máme a podobnou nápovědu jsme museli přidat.

vzhledem k tomu ze spravne se maji hesla saltovat a hashovat, pak je jakekoliv omezeni a to myslim jakekoliv, naprosty nesmysl... A tim myslim absolutni nesmysl... jedine omezeni ktere dava smysl je minimalni delka hesla, ale i to je diskutabilni, kdyz chce byt uzivatel debil, proc mu v tom mam zrovna ja branit? :) (nejde-li samozrejme o aplikaci kde se ukladaji citlive, zneuzitelne udaje... Typicky eshop a ulozena platebni karta)

tak znovu, bcrypt může brát třeba prvních 55 bajtů, blowfish 72 bitů, owasp doporučuje 160 znaků. To jsou vysokoúrovňové limity nastavené v konkrétní implementaci.Hlavní problém je s velikostí bloku u hashovacích funkcí, HMAC-SHA256 má 512 bitů, HMAC-SHA-384 512b, HMAC-SHA1 má 160 bitů. Velikost hesla nesmí překročit tuhle hodnotu a velikost soli by měla být menší nebo stejná jako velikost hesla, ale musí vyrovnat velikost bloku. Pokud tyhle zásady nedodržím, mám v aplikaci bezpečností díru a umožňuji útok tzv. block collisions.Vykašlete se na vlastní implementace, bcrypt v php (funkce password_hash) v současné době kvůli blowfishi bere prvních 72 znaků (viz dokumentace) ze vstupu na heslo, tj. pokud je heslo delší, je ten konec ignorovaný. Kryptograficky není snadné hashovat dlouhá heslo. Limit nastavujte ale nějak rozumně, ale rozhodně 8, 16 znaků je málo.

Samozrejme v plain textu zadna hesla neukladame :) Jen me zajima proc to nekdo omezuje, jestli to ma smysl nebo nema smysl, pripadne jak to resite vy.

block colission predpoklada ze ten hash uz mam, coz znamena ze tam mam nekde nejspis jeste mnohem horsi diru ktera dovolila ten hash vubec ziskat... Opravdu ma smysl tohle resit na foru nebo nejakem blogisku? :) jako jo, mas pravdu, ale jit tak strasne daleko ma smysl jen u bank nebo opravdu citlivejch aplikaci... ale u 99,9% webu to bude zbytecne reseni neceho co se nikdy nestane :)