šifrování hesel

md5 je hash, už z jeho podstaty opakované hashování ničemu nepomůže :-)
beru zpět, nedomyslel jsem to

mezi sha1() a md5() IMHO žádný zvláštní rozdíl není (když ignoruji délku hashe), password() je sql funkce, v php moc užitečná nebude

s tím jednoduchým rozšifrováním to není až tak zlé :-) a kolizní klíč lze najít tak jako tak, jestli neděláš něco pro banku, tak bych to nekomplikoval, maximálně si vyhledej něco o

Od MD5 se upouští, protože byla před pár lety objevena výrazná slabina v jeho bezkoliznosti.

md5 je hash, už z jeho podstaty opakované hashování ničemu nepomůže
Právě z té podstaty pomůže. Zlomení bude vyžadovat trojnásobek času a taky se ztíží použití rainbow tables.

Používám hash("sha512",$heslo) ...nevim o kolik je to bezpečnější, ale hash je dlouhej, takže to vypadá kůl bezpečně:) ikdyž to asi takový terno nebude
Saltování asi pomůže víc než lepší algoritmus

Právě z té podstaty pomůže. Zlomení bude vyžadovat trojnásobek času a taky se ztíží použití rainbow tables.
když budu mít rainbow table, bude mi ukradené, kolikrát v ní budu hledat, až tak nepospíchám

trochu to ztíží, ale do jaké míry? proč se hesla neprohání md5() v cyklu?
rovnou můžete použít



PS: teď tak přemýšlím, asi máte pravdu, docela by mě zajímala odpověď na ty otázky :-)

Tak mě napadá - pokud to chce někdo prolomit, třeba nějaký logovací formulář, tak do toho posílá ty hesla na kontrolu?

Protože nebyla by pak nejjednodušší obrana limitovat třeba 3 pokusy o login pro 1 profil a pak by se profil zamknul?

Trocha čtení:
http://www.phpguru.cz/clanky/hashovani-hesel
http://www.phpguru.cz/clanky/soleni-hesel

Hesla se taky dají odposlouchávat. Když se posílají přes nešifrované spojení (tak tomu je na většině stránek), tak je to asi mnohem jedodušší než snažit se prolomit nějakou šifru.

Hesla se taky dají odposlouchávat. Když se posílají přes nešifrované spojení (tak tomu je na většině stránek), tak je to asi mnohem jedodušší než snažit se prolomit nějakou šifru.
Je tedy dobré hashovat heslo (např. pomocí SHA1) přímo u klienta pomocí Javascriptu?

Je tedy dobré hashovat heslo (např. pomocí SHA1) přímo u klienta pomocí Javascriptu?
lepší bude použít protokol HTTPS

Hesla se taky dají odposlouchávat. Když se posílají přes nešifrované spojení (tak tomu je na většině stránek), tak je to asi mnohem jedodušší než snažit se prolomit nějakou šifru.

Nemyslím, že jednodušší. Předpokládá to, že máš přístup k nějakému bodu trasy přenosu - to není moc samozřejmé.
Naopak hashe z databáze lze získat útokem na server nebo využitím nějaké chyby v aplikaci.

Hashovat v cyklu? Ufff.
Podle mého solený hash do databáze, šifrovaný přenos přes https, solidní admin, který ví, co dělá a můžete mít klidný spánek :)

Právě z té podstaty pomůže. Zlomení bude vyžadovat trojnásobek času a taky se ztíží použití rainbow tables.
Se ztížením použití rt souhlasím. Jinak ne. Opravdu pak platí kryptografická zásada, že opakované použití jednoho systému nevede ke zvýšení jeho bezpečí.
Uvažujme 548973 má stejný hash 3574832. Když jejich hash zahashuju tak opět dostanu stejný hash...

Jinak souhlasím, že sha1() + salt (i když osobně pochybuju o zvýšení bezpečnosti solí) je pro normální aplikaci dostatečným zajištěním.

Pánové, šifrování vůbec nerozumím, ale mám jen jednu prostou otázku:
Mají všechny tyto bezpečnostní opatření smysl, když klienti vetšinou používají jedno, max dvě hesla pro většinu aplikací a pak musí spoléhat na poskytovatele těchto služeb - na jejich zajištění bezpečnosti a na jejich důvěryhodnost? Kolik lidí využívá služeb stránek, o jejichž důvěryhodnosti nic neví? Neví nic o lidech, kteří zminovanou službu poskytují. Když někdo bude chtít vytvoří si přitažlivé stránky se zajímavým obsahem, nebude hesla šifrovat a může je třeba prodávat...

Radim24
Já mám třeba u skoro každé služby jiné heslo. Využívám http://supergenpass.com/

Harwen
(i když osobně pochybuju o zvýšení bezpečnosti solí)

Nemusíš pochybovat. Přidáním random saltu ke každému passu snižuješ razantně počet kolizních možností. Navíc salt většinou nepřidáváš přímo tak jak ho máš uloženej třeba v DB, ale nějakou logikou na úrovni aplikace. Útočník má tedy práci navíc.

1. Má snížené možnosti pro kolize.
2. Musí krom hashe a saltu zjistit jak vlastně ten salt používáš.

Pravda ovšem je, že pokud se v aplikaci de dostat k hashum a jiným věcem které by měli být nepřístupné tak se nejedná o bezpečnou aplikaci ad už sou hesla cháněné jak chtějí.

Radim24

Smysl to má rozumný člověk se snaží chránit cizí hesla stejně tak jako by chránil své vlastní heslo.

Tvrdíkovi:
No protože ty jsi počítačový odborník...

BetaCam:
Pokud to není zloděj :-)

Radim24
Ano tohle je problém, ale problém na straně uživatele. Nicméně správce údajů by měl udělat vše proto aby zůstali tajné.

BetaCam
Matematicky je snížení počtu kolizí nesmysl.
A ať už budeš dělat se solí co chceš, pořád to je záležitost nějakých funkcí. A dá se předpokládat, že když získá db, získá i přístup k aplikaci :-)

Harwen
Matematicky je snížení počtu kolizí nesmysl.

Ono sem se tak trochu špatně vyjádřil. Místo slova "snížit" mělo být použité slovo "ztížit".

A dá se předpokládat, že když získá db, získá i přístup k aplikaci.

V tomto tématu ani tak nejde o pokusy o ovládnutí aplikace, ale o přiměřenou ochranu hesel "normálních" uživatelů. Útočník, který chce ovládnout aplikaci chce buď přístup k DB nebo heslo administrátora. Čím více mu dá práce najít kolizi pro administrátorský účet tím více ho to odradí od hledání kolizí běžných uživatelů. Za administrátorské heslo si odpovědný ty sám je to tvoje věc jak si ho zabezpečíš, ale běžní uživatelé "nejsou" zodpovědní za bezpečnost svých hesel v tvé aplikaci. Za jejich hesla si zodpovědný zas jen ty a vzhledem k tomu, že si od nich dostal důvěru měl by se vždy snažit jejich citlivé data chránit.

BetaCam
Ono sem se tak trochu špatně vyjádřil. Místo slova "snížit" mělo být použité slovo "ztížit".

To je jedno a to samé. Pokud budu předpokládat, že jeden hash je společný řekněme 7 náhodným řetězcům ze všech možných tak přidáním soli jen změníme množinu při které se mu podaří dosáhnout úspěchu, ale počet prvků v množině zůstane stejný. Samozřejmě, může nastat případ, že náhodou posolením získáš hash, který je jedinečný pro daný řetězec (teoreticky, prakticky nemožný), ale stejně tak by se ti mohl podařit opak - tedy zvýšit počet kolizních řetězců a naopak usnadnit útočníkovi práci.
(omlouvám se, ale dělal jsem ročníkovou práci na téma šifrování včetně jednosměrných metod a matematika je vždy přesná)