DB pole typu timestamp vz. Nette

Mysteria:
A má to nejaký mod ktorý vracia presne to čo som zadal? Už tam mám tie heslá osolené tým originálnym reťazcom.

Editoval Čamo (3. 7. 2014 22:31)

@Čamo: Učko je počet sekund od roku 1970. Jinak interně si MySQL ukládá timestamp ve formátu YYYY-MM-DD HH:mm:ss.

@EIFEL: Předpokládám, že solil tím datumem, který si uložil do timestampu.

Mysteria napsal(a):

@Čamo: Učko je počet sekund od roku 1970. Jinak interně si MySQL ukládá timestamp ve formátu YYYY-MM-DD HH:mm:ss.

@EIFEL: Předpokládám, že solil tím datumem, který si uložil do timestampu.

Salt ale nemá co dělat v DB. To tam rovnou může dát plaintext.

Editoval Pavel Macháň (3. 7. 2014 23:32)

EIFEL:
Jeden salt sa pridáva z DB a druhý z php. Tak som sa to učil ja. Je na tom niečo zlé?

Mysteria:
Momentálne riešim inú vec a nejdem študovať ten github. Mám „len“ php 5.4

Editoval Čamo (3. 7. 2014 23:46)

Jan Endel
Prečo myslíš že sú k ničomu? Máš k tomu nejaké argumenty?
A tá trieda password má aj nejakú dokumentáciu, či ako mám k tomu pristupovať? V čom je jej výhoda? Môže mi to prosím vás niekto priblížiť. Tú vešteckú guľu v papierníctve nemali :)

Pokiaľ viem tak princíp soli je o tomto: http://www.it-joker.cz/…amatora.html a nie o tom aký sa použije reťazec.

Jinak na toto téma doporučuju alespoň prolítnout tuhle přednášku.

Skoro, nehashujeme, ale šifrujeme, páč jedeme se vším na https, sha1 heslo je skoro jako bys to ukládal do plaintextu, cracknutí jednoho průměrného hesla brutalforcem se dá udělat v řádů sekund až minut.

Editoval Jan Endel (4. 7. 2014 12:53)

Mysteria
Pretože ten algoritmus nepoznám a dokumentácia chýba.

A nieje to náhodou tak, že k tomu aby mohol byť úspešný bruteforce útok potrebuješ nielen poznať sol, ale aj algoritmus, ktorý sa použil? Takže ak sa už útočník dostal až tam a toto
všetko pozná, tak môže začať lámať heslá, inak asi sotva. Alebo mi niečo uniká? K tomu majú samozrejme prístup správcovia, čo je určite riziko.

Ale nie som si istý či v takom prípade bude stačiť aj ten password_hash().
Bude?

Algoritmus musí být vždycky považovaný za veřejný. Security through obscurity nefuguje moc dobře. (https://cs.wikipedia.org/…gh_obscurity). Ví ho vždycky až moc lidí aby se dal utajit (každý zaměstnanec, bývalý zaměstnanec, každej správce u hostingu, …). Správně bys ty hesla neměl být schopen cracknout ani ty.

Pokud použiješ password_hash tak používáš nejsilnější aktuálně známý hash algoritmus. Brute force útok na něj je téměř jistě mnohem složitější než cokoliv co si vymyslíš ty. Stačit by to mělo jednoduše proto, že ten algoritmus má správné vlastnosti. Nejsou v něm známé algoritmické chyby, které by pomáhaly zmenšit stavový prostor, je pomalý takže zkoušení všech možností bude řádově pomalejší, automaticky používá náhodnou sůl, …

Pokud chceš ještě více zvýšit zabezpečení tak ten hash ještě šifruj symetrickým klíčem, který je jen na serveru (ne ve zdrojácích). Potom by útočník musel získat nejen přístup k DB (SQL injection) ale i k file systému.

Máš to nejspíš od hodně špatného zdroje, protože funkce samotná slabá není, můžeš jí pouze vnutit slabý algoritmus, nebo slabý cost (všimni si v dokumentaci, že podporuje i md5).

password_hash a password_verify je jenom jednodušší api nad crypt. Jak sis určitě všiml, použít crypt správně není vůbec jednoduché, proto taky existuje v Nette třída Password která dělá to samé, obaluje funkci crypt, aby se dala lépe používat a nemohl jsi v tom udělat chybu (nebo alespoň hodně složitě). Funkce password_hash je v php od 5.5, ale Passwords můžeš používat díky Nette už od 5.3.

Pointa je taková, že v současnosti prostě neexistuje lepší hashovací funkce, než tu kterou vnitřně používá třída Passwords v Nette. Pokud chceš vědět víc o blowfish hasování, funkci crypt a věcech okolo víc, tak použij google, nemá smysl abychom ti sem do fóra přepisovali dokumentaci jednotlivých funkcí a nástrojů.

Stejně tak nemá smysl v novém projektu používat jakýkoliv jiný hashovací algoritmus, než ten co ti nabízí Nette.

A ještě perla na závěr, třída Passwords ti dokonce umí říct, pokud heslo potřebuje přehashovat, funkci crypt totiž jde předat „cost“ což znamená jak moc má být hashování drahé… Takže až za 5 let budou 100× rychlejší počítače, tak prostě zvedneš cost a aplikace ti postupně, jak se ti budou přihlašovat uživatelé, hesla přehashuje na „dražší“ hash (tedy pomalejší) a opět si v pohodě, protože nepůjdou v rozumném čase cracknout silou.

To stejné dělá i Passwords a defaultní cost je v součanosti 10, pokud ti to nevyhovuje, můžeš si ho přes $options zvednout.

A jak je vidět, i salt se ti generuje sama, takže opravdu stačí pouze

$hashed = Nette\Utils\Passwords::hash($password);

a pak

if ( ! Nette\Utils\Passwords::verify($password, $hashed)) {
	throw new SecurityException("hesla se nerovnají");
}

Však nemusíš zasahovat do zdrojáku Nette. Cost si můžeš nastavit sám. Možná, kdyby sese podíval na api, tak už si to dávno zjistil!

Nicméně automatická detekce dle výkonu serveru je opravdu blbost! Jednou ti to hodí cost na 20, pak se server zpomalí, víc ho zatížíš, a cost je na 10… a máš problém.

Raději si detekuj výkon serveru sám a cost si nastav klidně na 31.

A pokud opravdu potřebuješ automatickou detekci, tak takto:

public static function countMeCost()
{
	$timeTarget = 0.2;

	$cost = 9;
	do {
 	  $cost++;
  	  $start = microtime(true);
  	  password_hash("test", PASSWORD_BCRYPT, ["cost" => $cost]);
  	  $end = microtime(true);
	} while (($end - $start) < $timeTarget);

	return $cost;
}

...
..
..

$hashed = Nette\Utils\Passwords::hash($password, array('cost' => self::countMeCost()));

Editoval MartinitCZ (5. 7. 2014 17:32)

Ale vždyť oni tam píšou, že si máš vyzkoušet jakou cost zvládá tvůj server v rozumném čase a tu pak hodit do nějakého configu a používat, nemáš to dělat při každé registraci. Uvědom si, že když když dáš cost moc vysokou a začne se ti přihlašovat 10 lidí, tak ti to vyžere kompletně všechen CPU výkon a ten poslední se může přihlašovat klidně i vteřiny… to nechceš.

spaze:
Zdravím, keď si taký rozbehnutý nevedel by si mi vysvetliť toto: https://forum.nette.org/…sulade-s-pdo
Mám na mysli ako to robí Doctrine?