Autorizācijas drošība (sesijas)

[pilots]

Ļaujiet man jums jautāt par sesijām un login būšanām.

 

Man šobrīd ir uzprogrammēts tā, ka viss darbojas, tomēr man šķiet, ka vajadzētu drošāk uztaisīt (nojausma, kā manipulē ar sesijām man maza, bet tomēr..).

 

Šī brīža variants:

login.php

//$sql SELECT * FROM lietottaji WHERE email = ... AND password = ... mysql_fetch_assoc ...

if ($row){
$_SESSION['lietotajs']=$row['id'];
header('Location: index.php');
exit;
}
else{
header('Location: login.php');
exit;
}

 

index.php (un visās citās lapās):

$saved_session_id = $_SESSION['lietotajs'];

$sql = "SELECT * FROM lietotaji WHERE id = $saved_session_id";
$result = mysql_query($sql);
$user = mysql_fetch_assoc($result);

if (!$user){
header('Location: login.php');
exit;
}

 

Vai piekrītat, ka šis ir pārāk vienkārši un nedroši? Kā uzlabot?

 

Es nezinu vai šituācijā tas der, bet varbūt izmantot kaut ko no šī laacz skripta: http://paste.php.lv/1653?

Piemēram saglabāt papildus `user-info` = $ip un katrā lapā pārbaudīt.

[Aleksejs]

Sveiks!

Neko briesmīgi sliktu neredzu. Izņemot - nav skaidrs, vai lietotāja padotie dati tiek pienācīgi izfiltrēti padodot tos šim:

//$sql SELECT * FROM lietottaji WHERE email = ... AND password = ... mysql_fetch_assoc ...

Un tomēr nenāktu par ļaunu papildus arī pārliecināties, ka sesijā saglabātais mainīgais ir vesels skaitlis:

$saved_session_id = intval($_SESSION['lietotajs']);

It kā jau nevajadzētu sesijas mainīgajā būt kaut kam sliktam, bet tomēr drošs paliek drošs.

 

Par sesiju drošību kā tādu nesen piedalījos runāšanā sitepoint forumā.

Faktiski īsumā - šobrīd cilvēki, kam var droši ticēt, ka viņu piedāvātais (Hardened Stateless Session Cookies) ir pārdomāts, piedāvā:

Glabāt Datubāzē H(sāls | parole) Ntās iterācijas hashu v=H(aN) = H(H(aN-1 | parole)) un a0 = H(sāls | parole) un sāli (kam jābūt lielam -> ~256b).

Kad lietotājs iesūta lietotājvārdu un paroli, veikt autentifikācijas pārbaudi šādi:

1. Atrast sāli, kas atbilst konkrētajam lietotājam
   
2. Izmantojot sāli un iesūtīto paroli uzģenerē H(aN') un pārbauda vai tas sakrīt ar tabulā glabājamo
   
3. Ja sakrīt, tad lietotājam kukijā uzstāda šādus mainīgos:
   
   1. 
      
   2. exp - datumlaiks, kad sesijas derīgums beidzas. Tas nozīmē, ka ir stingrs sesijas beigu laiks, kurš netiek pagarināts.
      
   3. data - web-aplikācijas stāvokļi, kas ir jāuztur (piemēram lietotāja id)
      
   4. auth - autentifikators, kas vienāds ar aN
      
   5. digest - HMACk(exp||data||auth) daidžests ar serverim zināmu atslēgu k, kas nodrošina, ka lietotājs nevar manipulēt datus, jo manipulētie dati nedos šādu daidžestu.
      

[*] katru reizi tiek pārbaudīts, vai iesūtītais auth ir derīgais. Un vai dati atbilst daidžestam.

Vēl neesmu līdz galam uzrakstījis implementāciju.

[pilots]

Paldies par saturīgu komentāru.

 

^ iekš $sql dati tiek ievietoti ar mysql_real_escape_string, tur tad nu nevajadzētu būt problēmām.

 

^ lai būtu drošs, ka id ir skaitlis es tiku izmantojis ctype_digit, vēl zinu, ka ir is_numeric. vai šajā situācijā tomēr labāk ir intval?

 

^ tas HSSC man miglā tīts. Ja kādreiz kādu piemēru uzrakstīsi, kaut vai english valodā, tad ja ne uz šo tēmu, tad šepat forumā nopublicē. Metode ievērības cienīga.

[Aleksejs]

Pie realizācijas vēl notiek darbs, bet tikmēr vari apskatīt, kas sanācis ar hashu ģenerēšanu:

http://www.sitepoint.com/forums/showthread...566#post3843566

Tas pats kods tikai komentāri latviešu valodā:

http://paste.php.lv/7484?lang=php

[marrtins]

Sāls garāks par passwd - laps :)) Vispār interesants pdf`s.

 

Nevaru iebraukt - ja man kādā nebūt veidā ir lasīšanas tiesības uz useru db ar visiem hešiem un sāļiem un arī zināms šis paste.php.lv kods, kā tas mani atturēs/bremzēs no bruteforcēšanas? Ko esmu palaidis garām?

 

P.S.

Klau, bet ja savajag autorizēties no citurienes, ne tikai no PHP? Būs skarbi to realizēt, piemēram, MySQL storētā procedūrā.

[Aleksejs]

No brutforsēšanas neattur itin nekas - nav izdomāta lieta, kas atturētu no bruteforsēšanas :)

Toties tiek padarīta neiespējama rainbow tabulu izveidošana (jo sāls vērtību ir par daudz).

Brutefosēšana notiks tieši iterāciju skaitu reižu lēnāk.

 

Ja vajag autorizēties no citurienes, tad citurienē jāizmanto citurienē realizētās hash funkcijas - SHA512 arī Cobolā ir SHA512 :D

Katrā gadījumā hash funkciju var izvēlēties tādu, kādu vien vēlies (nu protams visās vietās vienu un to pašu). Piemēram, ja vajag to visu storētu MySQLā, var realizēt ar SHA() (kas gan nav ieteicams jaunveidojamām sistēmām).

 

P.S. Vakar pabeidzu +- darbu pie implementācijas - tagad jānoved līdz rādāmai stadijai ;)

[marrtins]

Brutefosēšana notiks tieši iterāciju skaitu reižu lēnāk.

Nu jā - logičano :)

[Aleksejs]

Nopietna problēma iepriekšējā realizācijā - nedrīkst katrā iterācijā likt klāt paroli, jo faktiski tas nozīmē, ka jāatlauž tikai pēdējā iterācija (protams, arī tas ir sarežģīti, tomēr nesalīdzināmi vienkāršāk kā visas ķēdītes atlaušana), tādēļ izmainīts kods:

http://paste.php.lv/7501?lang=php

Parole tiek pievienota tikai pirmajai iterācijai.

[CrAsh]

Sitepoint forumā runa bija par hehašotas paroles sūtīšanu no brouzera uz serveri, kas radīja galvenās bažas par drošību.

 

Ja tomēr sūta hešotu paroli, tad nav iespējams brouzerī mainīt lapas kodu un sūtīt paroles hešu, t.i. izlaist hešošanas soli?

Edited June 15, 2008 by CrAsh

[bubu]

Var izlaist. Visu, kas tiek darīts klienta pusē (browserī), var simulēt/emulēt/izlikties kā vien tik vajadzīgs.

[Aleksejs]

Sitepoint forumā runa bija par hehašotas paroles sūtīšanu no brouzera uz serveri, kas radīja galvenās bažas par drošību.

 

Ja tomēr sūta hešotu paroli, tad nav iespējams brouzerī mainīt lapas kodu un sūtīt paroles hešu, t.i. izlaist hešošanas soli?

 

Vismaz tajā tēmā netika apskatīta jau klienta pusē hashotas paroles sūtīšana.

 

Par kaut ko tādu tika runāts šajā tēmā:

Password encryption...

Kurā aprakstīts challenge-response autentifikācijas variants.

[CrAsh]

Skaidrs, tas ieviesa zināmu skaidrību.

 

Paldies!