Autor Zpráva
Smajda
Profil
Zdravim pány programátory, chtěl bych poradit jaký je nejlepší šifrování na hesla
md5(), password(), sha1() ??
a jaky používáte vy? teď používám md5() ale přemýšlím že to lze jednoduše rozšifrovat a tak to asi budu při registraci šifrovat 3krát a pak to třeba bude už lepší...díky všem za názory
Alphard
Profil
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
salted hash
DoubleThink
Profil *
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.
Nox
Profil
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
Alphard
Profil
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

for ($i = 1; $i <= 1000000; $i++)
$hash = md5($hash);


PS: teď tak přemýšlím, asi máte pravdu, docela by mě zajímala odpověď na ty otázky :-)
Nox
Profil
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?
Jan Tvrdík
Profil
Trocha čtení:
http://www.phpguru.cz/clanky/hashovani-hesel
http://www.phpguru.cz/clanky/soleni-hesel
imploder
Profil
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.
karbon
Profil *
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?
nightfish
Profil
Je tedy dobré hashovat heslo (např. pomocí SHA1) přímo u klienta pomocí Javascriptu?
lepší bude použít protokol HTTPS
DoubleThink
Profil *
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.
Smajda
Profil
vidím, že se asi neshodneme každý používá něco jiného...docela se mi zalíbil ten cyklus to je asi nejlepší protože jinak nevim třeba to zahashovat v md5() a potom to md5() zaheslovat jeśtě v sha1() jenže potom se mi zdá že login by trval hrozně dlouho...
Aesir
Profil
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 :)
Harwen
Profil
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.
Radim24
Profil *
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...
Jan Tvrdík
Profil
Radim24
Já mám třeba u skoro každé služby jiné heslo. Využívám http://supergenpass.com/
BetaCam
Profil
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.
Radim24
Profil *
Tvrdíkovi:
No protože ty jsi počítačový odborník...

BetaCam:
Pokud to není zloděj :-)
Harwen
Profil
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 :-)
BetaCam
Profil
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.
Harwen
Profil
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á)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: