Diskuze: PHP: Třída pro autorizaci a autentifikaci
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Vlastník
Zobrazeno 12 zpráv z 12.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Pokud by jsi chtel byt hodne paranoidni, tak pro zvyseni bezpecnosti hesel muzes jeste pridat salt hesla ke kazdymu uzivatelovi zvlast.
Kdyz ti nekdo ukradne db a tenhle jeden salt, co mas ted, tak pak vsechny hesla vlastne muze louskat najednou, ale kdyz ma jeste navic kazdej uzivatel svuj salt (treba nahodne vygenerovanej), tak musi uplne kazdyho uzivatele louskat zvlast.
takze fce passwordhash by pak vypadala treba takhle:
// Vrátí otisk (hash) hesla
private function passwordHash($password, $userSalt)
{
return hash('sha512', $password . self::SALT . $userSalt);
}
Jo, ja vim, na devbooku to je takto udelane a hash se jeste pocita iterativne, jsem hodne paranoidni Tutorial jsem tim vsak nechtel zatezovat.
Iterativní hash? To si nedovedu moc představit. Algoritmus pro výpočet hashe je iterativní a vylepšit se to nedá.
Náhodně vygenerovaný salt pro každého uživatele také musí být někde uložen. Bezpečnost to tedy nezvyšuje.
Bezpečnost musí být soustředěna pouze do klíče, tedy heslo+salt.
Pridelavam tak narok na vypocetni vykon k prolomeni hashe hrubou silou. Iter. hash je hash pocitany danym algoritmem nekolikrat (jako vstup je pouzity hash z minule iterace). Ac konstantne, tak velmi zvysim cas k vypoctu, ja to delam jednou, on si tak nevygeneruje rainbow tabulku, protoze by nad tim ztravil veku. To same plati pro dynamickou sul, ta rainbow tabulky eliminuje uplne.
Pár postřehů k programu:
id
Zvykni si na to, že u kvalitně udělaných databází není možné z tabulky vytáhnout heslo ani jeho hash a přizpůsob program tomuto požadavku.
Ale náhodně vygenerovaný salt pro každého uživatele celkovou
bezpečnost všech hesel opravdu zvyšuje.
To, že útočník získá i salt uživatele na tom nic nemění, pořád musí
lámat heslo každýho uživatele zvlášť.
Hádání hesla, když je salt jen globální:
Máš globální salt a tabulku users, kde každý uživatel nemá svůj
salt.
Vybereš si metodu - třeba bruteforce.
Seřadíš si hashe, aby se ti v nich dobře hledalo.
Postupně generuješ všechny kombinace znaků a pak u nich spočítáš hash
nějak takhle:
$hash = hash($globalSalt.$guessedPass)
teď ti stačí najít v seřazených hashích stejnou hodnotu, pokud tam je (binárním vyhledáváním, to je hned) jedním vypočítáním hashe jsi otestoval všechny uživatele, jestli někdo z nich používá tohle heslo.
Když má každý ještě svůj unikátní salt, tak musíš pro každýho usera generovat hashe všech možných hesel s jeho unikátním saltem, takže ve výsledku ti lámání zabere mnohem mnohem víc času.
Snad jsem to popsal nějak pochopitelně, kdyžtak to ještě rozepíšu.
"Zvykni si na to, že u kvalitně udělaných databází není možné z tabulky vytáhnout heslo ani jeho hash"
Nezapomínej na lidský faktor - jako že si třeba někdo z firmy odnese db domů apod.
Napsal jsi to správně. Uznávám to. Pokud však použiješ jako usersalt jeho username, poslouží to stejně dobře.
"Nezapomínej na lidský faktor - jako že si třeba někdo z firmy odnese db domů apod."
Tohle jsi pochopil nesprávně. U kvalitně udělané databáze nefunguje select na zjištění hesla nebo jeho hashe. Prostě DB takový dotaz odmítne.
Username pouzit muzes taky, to je pravda
S takovou DB jsem se jeste nesetkal, zatim jsem delal ve firmach, kdy bylo
nejvyssim levelem zabezpeceni to, ze se k hashovani pouzival salt, ale to je
mozna tim, ze nejsem moc webar.
Rozhodne to ale zni dobre, tyhle data (salt+hash hesla) se nikdy jinde nez
uvnitr v db zpracovavat nemusej.
Ono se v ceskych firmach na bezpecnost docela casto moc nehledi...
Takovou databází je například LDAP. Pro autentizaci i pro autorizaci se používá velmi často, protože je velmi rychlá. Nesrovnatelně rychlejší, než třeba MySQL.
Zobrazeno 12 zpráv z 12.