Ahoj, po delší době jsme natočili další screencast, tentokrát o tom, jak zlepšit zabezpečení aplikace pomocí přidání saltu k heslu.
(přepněte si na fullscreen)Ahoj, po delší době jsme natočili další screencast, tentokrát o tom, jak zlepšit zabezpečení aplikace pomocí přidání saltu k heslu.
(přepněte si na fullscreen)
ahoj,
diky za dalsi screencast.. uz jsem myslel ze diky studiu na VSE dalsi nebudou
jenom mam dotaz proc nepouzit k osoleni rovnou username..resp: substr(md5(email@email.cz),0,16)?
diky za info
Ahoj. Jsme rádi, že se líbí
Ona tomu střídavě bránila VŠE a TUL…
K tomu username mě nejdříve napadlo, že by jsi ho uživateli nemohl změnit a pak jsem ještě trochu pohledal:
Pokud by stejný algoritmus používalo více systémů, tak v případě nepoužití zvláštního hashe pro aplikaci bude mít daný uživatel všude stejný hash hesla (pokud používá stejná hesla). Zadruhé by stačilo vygenerovat rainbow tabulku pro často používané uživatelské účty typu admin, administrator a byli bychom skoro tam kde předtím.
(http://stackoverflow.com/…ashes/536756#…)
Jak říká Martin, ta sůl musí být náhodná. Resp. důležitější je, aby byla rovnoměrně náhodně rozložená mezi záznamy. Ten příspěvek na SO to celkem obšírně a důkladně popisuje :)
Pánové, díky za video a především za použití ZF. Teprve se do něj začínám dostávat a podobná videa mi v mnohém pomáhají. No a to získávání plaintext hesel z hashované podoby je jistě taky zajímavé :)
Diky za návod je to zajimave a k zamysleni asi udelam patch na aplikace co jsem psal. Forma screencastu je povedena. Fandim Vam pri dalsich.
supr screencast. už se těšim na další
Ahoj, můžu se zeptat proč solíte to heslo dvakrát?
$data[‚password‘] = sha1(self::SALT . $password . $salt);
nestačí ho osolit dynamickou solí?
čili jen
$data[‚password‘] = sha1($password . $salt);
@tom: Stačí – do jisté míry.
Ale bráno do důsledků jde o rozdělení rizika. Pokud se někde dostane k dumpu databáze, tak má jak sůl, tak hash. Což může a nemusí být bezpečnostní riziko. Tím, že zavedeme ještě sůl, která má jiný původ než databázi, tak přidáme další stupeň volnosti. Tzn. aby měl útočník všechny iformace, které používáme při přihlášení, musí získat přístup jak k DB tak ke kódu aplikace. A jak známo tak úniky DB bývají častější než úniky kódu. Ani to, že je aplikace SQLInjection-safe neznamená, že si admin posléze neudělá „maličkej skriptík na export emailů uživatelů do CSV“, který bude na injection náchylný a bude běžet na stejné DB a stejném uživateli.
Ale je to spíš taková „akademická“ debata… myslim, že pro běžné použití stačí hashnout a osolit ;) Ono po tom co sem už párkrát viděl, tak občas by i hasnutní samotné bylo vylepšení o 100%
Pro začátečníka sice dost nepochopitelná oblast, ale vám se povedlo ji dokonale vysvětlit. Díky hoši!
dík za screencast , napadlo mi ešte vylepšenie dynamickej zmeny salt po každom volaní akcie controlleru (pokial vaša app má niečo ako loger alebo app controller je to správne miesto na túto funkciu ) (používam cakephp tak vám to nenapíšem v zend jazyku ;D ) následným ukladaním do session a cookies by ste dosiahli akéhosi „tokenu“ pri ktorom by už nebolo možné sa prihlásiť z dvoch prehliadačov súčasne na jeden účet (ak by ste pri queste porovnávali posledne ulozený salt hash v cookies a db pred vykonaním akcie volaného controlleru ) a pokial sú útoky na db server častejšie ukladať salt na iný db server (aspon cake umoznuje menit nastavenie db za behu urcite aj zend ) trosku paranoidny príspevok ale snád som to napisal zrozumitelne ;P
ux37: Docela zajímavá myšlenka. Ale jedna věc mi není jasná – jak bys udržoval tu výslednou osaltovanou hodnotu – představme si, že by teoreticky ta salt byla v session/cookie (je to prakticky jedno). A touto solí osaltovaná hodnota by byla uložena v DB. Jakmile dotyčný provede jakoukoli akci, tak by se měla sůl přegenerovat. Jenže z čeho jí budem ten hash generovat, když nemáme původní heslo? (máme jen to osaltované tou session solí) Ledaže bysme někde měli uložené to heslo bez soli. A to by nám to celé saltování pak bylo k prdu, žejo :D Dále mi pak není jasné, co by se stalo, kdybychom přišli o session/cookie z nějakého důvodu. To už by se uživatel nikdy nemohl autentizovat, protože bychom neměli tu sůl, kterou jsme použili pro hashování hodnoty uložené v DB.
Veškeré periodické generování soli per-request IMO musí narazit na to, že buď nám musí uživatel to heslo poslat v plaintextu v rámci každého requestu (tj. praticky se znovu přihlašovat při každém kliknutí) nebo si to heslo v plaintextu musíme někam uložit a v tu chvíli je nechráněné, což je špatně. Úplně stačí, že teče nehashované (pokud ho nehashnem třeba javascriptem před odesláním) po přihlášení.
Tomáš Fejfar : ano súhlasím,píšem trošku narychlo , napadlo mi to skrz jedného projektu ktorý budem riešiť skor okrajovo som chcel použiť salt stlpček ale riešenie je nepoužiť sol ale cukor ;P
No keď tak nad tým uvažujem ajeď to moc nepatrí sem po auth musel by si mať v db ešte dva stlpce napr public_salt ktorý by si posielal uživatelovy do session a automaticky ho generoval a public_salt_hash coz by bolo vysledok generovaneho saltu a hashu hesla ulozeneho v db pri kazdom queste by si porovnal hash(usivatela_ulozeneho_v_session+hash_hesla) a public_salt_hash, pri strate session by sa musel znova prihlasit coz nevidim ako problem nakolko salt je ulozeny v db (aj ak je jeho povodna sol potrebna pre kombinaciu pri prihlaseni automaticky generovana )
uzivatelovy nemusis posielat plain text hesla staci si jeho heslo pri queste vytiahnut z db na zaklade session user id (predpokladam ze takto nejak je identifikovany )