it-swarm-eu.dev

Před použitím bcrypt předhypte heslo, aby nedošlo k omezení délky hesla

Dobrou praxí není zbytečné omezování délky hesla, takže lze použít přiměřeně dlouhé přístupové fráze (možná 35–45 znaků pro 6/7 dicewords). (Viz např. Mám mít maximální délku hesla? , kde je doporučeno maximum 1 kB, pro ochranu před DoS, aniž by byla omezena schopnost uživatelů nastavovat dlouhá hesla.)

bcrypt se také běžně doporučuje (viz např. Doporučují bezpečnostní experti bcrypt pro ukládání hesel? , http://chargen.matasano.com/chargen/2007/9/7/enough- with-the-Rainbow-tables-what-you-need-know-about-s.html )

Doporučuje se také použít sůl (náhodná a uložená s heslem hash) - věřím, že se často doporučuje 32 bitů (4 znaky). (Rozumím velikosti soli tak, že je „dost, že počet kombinací je mnohem větší než počet uživatelských záznamů A je dost, aby se Rainbow stoly nedaly neuvěřitelně velké“ - 16 bitů je dost pro druhou část, ale nemusí být dost na první.)

Ale AIUI bcrypt má pouze hashe 55 bajtů - se 4 znaky pro sůl, která ponechává 51 pro heslo.

Hádám, že bychom neměli jen zašifrovat (vlevo (heslo, 51)) a ignorovat poslední znaky.

Měli bychom omezit uživatele na 50 znaků v jejich hesle (dost pro téměř každého, ale ne rozhodně dost)?

Měli bychom místo toho použít něco jako bcrypt (sha256 (sůl + heslo)) a povolit až 1K znaků? Nebo snižuje přidání kroku sha256 (nebo sha512?) Celkovou bezpečnost nějak?

Mají scrypt nebo PBKDF2 podobná omezení délky?

(Poslední otázka je opravdu zajímavá, opravdu - uvědomuji si, že prostorová tvrdost/odolnost vůči FPGA a relativní novost scrypt a rezistence bcrypt vůči GPGPU ve srovnání s PBKDF2 jsou mnohem důležitějšími faktory při rozhodování, které hash použití.)

65
Misha

Použití zabezpečené hashovací funkce pro předběžné zpracování hesla je bezpečné; to může být ukázáno, že jestliže bcrypt (SHA-256 (heslo)) je rozbitý, pak buď heslo bylo uhádnuto, nebo byla některá bezpečnostní charakteristika SHA-256 prokázána jako nepravdivá. Není třeba se na této úrovni pohrávat se solí; prostě hash heslo, pak použijte bcrypt na výsledek (se solí, jako bcrypt mandáty). SHA-256 je považována za bezpečnou hashovací funkci.

Bod soli má být jedinečný - pokud možno jedinečný, takže žádná dvě hashovací hesla nepoužívají stejnou hodnotu soli. 32 bitů je za to trochu málo; měli byste použít delší sůl. Pokud máte n kousků soli, narazíte na kolize (dvě hashovací hesla používající stejnou sůl), jakmile máte více než asi 2)n/2 hashed hesla - to je asi 65000 s n = 32, což není příliš vysoká hodnota. Raději byste měli použít 64 bitů nebo více soli (použijte 128 bitů a můžete si s tím přestat dělat starosti).

39
Thomas Pornin

Bcrypt používá 128bitovou sůl a heslo pro 55 znaků (max). Nemusíte přidávat žádné další hodnoty solí; bcrypt to zvládne.

Návrháři bcrypt cítili, že limit 55 znaků v hesle nebyl problém, protože hash má 128bitový výstup. Pokud je vaše heslo větší než 55 znaků, návrháři předpokládali, že již poskytujete více než 128 bitů entropie, takže to není problém. Směrnice NIST by to naopak počítaly jako pouhých 77 kousků entropie. Pokyny NIST jsou založeny na skutečnosti, že přístupové fráze mají méně entropie na znak než náhodná hesla, a na předpokladu, že uživatelé budou používat hesla pro delší hesla. Abyste lépe zajistili, že získáte plných 128 bitů entropie, můžete povolit delší hesla a hashovat je pomocí SHA-256 nebo SHA-384 pro jejich komprimaci na přijatelnou délku. Věci můžete také zjednodušit pomocí scrypt nebo PBKDF2, které nemají omezení délky. Scrypt je navržen tak, aby byl „tvrdý na paměť“, kromě toho, že je výpočetně časově náročný; to by byl můj výběr algoritmů.

14
Steven Alexander