hash

Dobry den,
chcel by som sa opytat, aky hash je momentalne asi najlepsie pouzivat z hladiska bezpecnosti. sha1 je uz na prelome ak uz nieje, viete poradit nieco ine? dakujem
Jednoduchá otázka, ale složitá odpověď. Záleží k čemu jej chceš používat?!

Pokud k jednoduchému ukládání hesel uživatelů, tak je lepší zvolit obvyklé sha-1 (které relativně dostačuje - pro tuto úroveň ochrany, pro ověření identity (například serveru, osoby) je však v dnešní době již nevhodná). Případně se podívat, jaké jsou možnosti pro použítí ve funkci hash() - zdaleka ne všechny instalace php obsahují i věci typu haval160, sha-256 apod..

Každý způsob užití vyžaduje jinou úrověň zabezpečení (mezi bruteforce útoky prakticky nejsou rozdíly, jen v některých algoritmech byly nalezeny slabiny - md4).

Na druhou stranu, při solení hesel (pokud neznáš, použij google) lze dosáhnout velmi dobrých výsledků i s relativně "zastaralými" algoritmy typu md5. (Třeba md5 a solení používá většina linuxových distribucí i v dnešní době a rozhodně v další desetiletce neplánují změnu, bezpečné je to dost ;))
"solenie" zviknem pouzivat, ako kombinaciu zretazenia hesla a soli.
Ide mi momentalne hlavne o pristup pouzivatelov, a podobne..
Tak pokud jde jen o přístupová hesla uživatelů (k malému projektu), tak stačí použití i klasické sha-1. U velkých projektů (kde se změna v kódu do budoucna moc nepřepokládá bude asi lepší použít sha-256 (bude to mít jen výrazně větší odolnosti proti bruteforce útokům).

K použití přihlašování si dovolím jednu poznámku. Často se jako velmi dobré řešení doporučuje přidat do přihlašovacích skriptů counter (který počítá počet přihlášení). Při špatně zadaném hesle se zvýší, při správně zadaném se vynuluje. A pokud dosáhne například hodnoty 5, tak se účet na 5 minut zablokuje.

Stále však platí, že pokud se najdou v algoritmu (časem, třeba za rok) slabiny, bude potřeba skripty předělat.

___
Malý projekt je myšleno tak, že se nepočítá s tím, že bude funkční i za 5 let.
<HTML>Každý hash má slabinu - bruteforce a slovníkový útok (v dnešní době distribuovaný). A pokud existují databáze... Takže IMHO je celkem jedno, jaký algoritmus se použije, důležité je zabezpečit vlastní uložená data proti jejich vyzrazení a útok pomocí hledání v databázi hashů ošálit použitím soli (tu možno případně z části vygenerovat z hesla např. pomocí rot13). Takže s klidem md5, sha-1, je to fuk. Zásadní slabina hashovacího algoritmu je jen a pouze v rozsahu znalostí hashů...

A ještě větším nebezpečím než vyzrazený hash samotný je heslo zachycené někde při cestě v čisté textové podobě nebo vyzrazené blbostí uživatele. Chtělo by to https...

Co se týče Freezova návrhu na 5 krát a na chvíli dost, to není řešení proti louskání vyzrazeného hashe. Každopádně jako zabezpečení proti hádání skrze různá přihlašovací okna je to dobré, bohužel ale i zneužitelné.</HTML>
Freeze: Dovedu si představit, že mi někdo úmyslně zablokuje účet tím, že dá 5x chybně heslo. Když to zopakuje několikrát denně, služba se pro mne stane nepoužitelnou. Zejména pokud bych pokaždé musel otravovat admina.

Přijatelnější je pro mne prodlužování timeoutů pro další možné přihlášení v případě zadání chybného hesla.
Kit: Zablokování účtu nebylo myšleno tak, že nebudeš moct nic udělat. Jen, že se dalších x minut (předtím jsem psal 5) nebudeš moci přihlásit - pokud už ale přihlášen jsi, neovlivní tě to.

Otravování admina je zbytečnost - všechno lze řešit přes timeouty (už proto, že bych nechtěl být adminem, kterého všichni otravují kvůli blbostem)..
<HTML>Většinou ale přihlášen nejsi a potřebuješ se přihlásit ;) A pokud ti nějaký kretén svými pokusy blokuje účet, tak admin asi nebude příliš nadšený, až se mu ozveš ;)</HTML>
Tak co třeba dočasná blokace podle IP adresy? Sice to není účinné, ale útočníka to aspoň zbrzdí a skutečný uživatel nebude omezen.
Tomík: Všechno záleží na tom, jak se to napíše.. je to zajímavý nápad, ale určitě má své nevýhody (často za NATem je více než jeden uživatel a pod.)..

Nípal: Na druhou stranu, neznám moc lidí, kteří se budou pokoušet přihlásit na cizí účet více než parkrát (možná se pletu?) - ale i toto lze omezit jinak..
a) k identifikaci uživatele použít třeba kromě nicku také e-mail (a zadat 2 věci správně a třetí tipovat je ještě složitější)
b) místo pětiminutového blokování blokovat na deset vteřin po každém špatném hesle (jako většina unixů - i když je tam mezera jen vteřinová :) )

Toto nezabrání použití ukradeného hashe. Na druhou stranu, pokud bude útok (ať už bruteforce nebo slovníkový) na hash trvat déle než pár let (a nebude existovat žádný způsob, jak použít hash místo hesla - třeba hashování v javascriptu u uživatele), nevidím v ukradeném hashi nebezpečí. Tím nechci ochranu databází podceňovat - všechno má svou cenu.
<HTML>Hashování v JS u uživatele je no-no. Problém se totiž zjednoduší na "zjisti hash a použij ho"</HTML>
To uz se resilo. hash se vygeneruje vuci casu, ip, nahodnemu slovu a cemukoliv dalsimu. Tim se stava jedinecny pro danou session a treba po 10 minutach se zmeni. Proste, kdo chce, tak si to umi zabezpecit. Jako, ze vetsinou se nechce, takze schopni lide, jako my, by dokazali vykrast bankovni uctu, kdyby o to stali :) Jenze pro nas to neni dost zajimava vyzva.
<HTML>To není o zajímavosti výzvy, ale o jisté slušnosti - nekrademe.</HTML>
Nípal (moderátor) To taky :) Ale ti spatni to samozrejme nechapou, tak jim to treba obkecat jinak.
Tak ohánět se dneska slušností se už asi ani nedá.. stačí podržet dveře a už vypadáte jak nějaký úchyl/idiot/buzerant/pedofil (vybrat podle toho, komu dveře podržíte).
Pravidlo č.1: Nikdy nepodceňujte sílu útočníka. (S. H. Huseby: Zranitelný kód - dobrá kniha, doporučuji)