Aleksejs

Priekš kam tev to md5 vispār vajag šajā vietā? Izlasi šito: http://php.lv/f/topic/14308-dokumentipamacibas-par-php-un-web-aplikaciju-drosibu/page__view__findpost__p__111056

Izejot šos http://www.zend.com/en/services/training/ un nokārtojot šos http://www.zend.com/en/services/certification/ dabū Zend sertifikātu.

Pat ja tā. Vai tas kādam rada kādas problēmas?

Vai arī izmanto "prepared" vaicājumus: mysqli_prepare()

codez, tas izklausās pēc draudzenes-programmētājas-kikbokseres ... ;)

1) dabūjam pēdējo ievadīto laiku: SELECT laiks FROM statistikas_tabula WHERE user = $username 2) Salīdzinām ar tagadējo laiku 3) Ja starpība lielāka par 20 minūtēm pieņemam sūtīumu un veicam UPDATE statistikas_tabula SET laiks = now() Ja nav, tad sakām, ka jāgaida. Skriptu gan pats raksti.

http://php.lv/f/topic/14308-dokumentipamacibas-par-php-un-web-aplikaciju-drosibu/

Datubāzē nav definēta kārtība, kādā secībā atgriež datus, ja nav "ORDER BY". Ja svarīga secība, tad lieto ORDER BY. Viss :)

Nu pieliec galā ORDER BY ID DESC un būs Tev pēc ID. Cik esmu novērojis tad pašā DB dati attēlojas sašķiroti pēc primārās atslēgas. Bet varbūt, ka nav tik vienkārši.

Kur dabū mainīgo $ielogojies?

Vienīgi nomaini gan rindas, kurās teikts NOMAINĪT OBLIGĀTI! $key = pack('H*','86b6de905bbee18b3425f7e5974c1cad7e24ec06a707a2766c5988c20ebc7337');//šī ir slepenā šifrēšanas atslēga HEX formā, NOMAINĪT OBLIGĀTI!!!! $hmac_key = pack('H*','8412789462918462123861789234612378964123763412781273467252347564735');//šī ir slepenā HMAC atslēga. NOMAINĪT OBLIGĀTI!!!!

Kā jau ieeditēju - "variable scope" ;) Paskaties, kā ar to tiek galā funkcija check_token ;)

masīvs $user_data pēc būtības domāts kā tāds $_SESSION aizvietotājs. Ko tu tālāk savā aplikācijā ar to dari un kā izmanto jau ir tava bēda. :) To katru reizi iegūst no cookie - līdz ar to tas ir pieejams visur, kur tiek izmantots check_token(); $user_data[0] == lietotāja ID $user_data[1] == parole $user_data[2] == autorenew - vai katru reizi pagarināt derīguma termiņu $user_data[3] == derīguma termiņš - datums/laiks, līdz kuram derīgs šis autentifikators $user_data[4] == klienta IP adrese - vari izmantot, lai konstatētu, ka ir mainījusies IP adrese. $user_data[5] == info - serializēti dati, kuri tev vēl vajadzīgi, lai tiktu saglabāti / nav obligāts $user_data[6] == kontrolsumma iepriekšējiem 6 elementiem. edit: Savā skriptā Tu $user_data neredzi, jo tas ir ieslēpts funkcijā checkLogin(). Tev vajag to definēt kā globālo mainīgo, vai arī padot "by reference" checkLogin funkcijai.

$user_data[0] ir uid Tavā kodā 73. rindiņā: $data=$uid.','.bin2hex($parole) .','.intval($autorenew).','.intval($expire). ','.ip2long($_SERVER['REMOTE_ADDR']) . ',' . bin2hex($info);//info - papildus mainīgie utt, kas jāsaglabā no vienas lapas uz otru

Pēc uid

Pārbauda vai: cookie vērtību atšifrējot ar servera atslēgu izpildās nosacījums, ka pirmo sešu lauku kontrolsumma (HMAC ar servera atslēgu) sakrīt ar piestādīto kontrolsummu (septīto lauku). Kā arī vai nav mainījusies IP adrese $mas[4], nav beidzies temiņš $mas[3]. Edit: if(!check_pw($mas[0],pack('H*',mas[1])){ būtu jāstrādā.

Nu un vai lietotājam DB parole glabājas kā: 3934396130656433363861656433643833333534393739363933336534333139 ? Pamēģini šādi: if(!check_pw($mas[0],pack('H*',mas[1])){

$user_data bija domāts kā lauks, kuru var izmantot "sesijas" datu glabāšanai. Tas nav obligāts.

Nu uztaisi echo tam visam... pirms return 5... varbūt rodas idejas: print_r($mas);

"SELECT DISTINCT lietotajs, max(laiks) FROM ".PREFIX."apmekletaji WHERE lietotajs = '".$lietotajs['id']."' GROUP BY lietotajs ORDER BY laiks DESC LIMIT 30"

Nu, ja Tu tur glabā to pašu hashu, kuru DB, tad raksti vienkārši: if(!check_pw($mas[0],$mas[1])){

Nu, ņemot vērā, ka viss tiek šifrēts ar servera atslēgu, tad vari tās paroles nelikt nemaz tajā tokenā... Cik labi vai slikti tas sanāk, jāpadomā. Principā jau iespējams pietiek ar to, ka var veiksmīgi atšifrēt un nokonstatēt, ka kontrolsumma ir derīga un ka laika zīmoga lauka vērtība nav par mazu (beidzies derīguma termiņš).

Nu, mana pamatideja to visu taisot bija tieši tāda.

Nē, paroles veidošanas funkcija (kaut arī to es pārveidotu) šoreiz nav galvenais. Galvenais ir tas, ka cookijā vienmēr tiek ierakstīta fiksēta vērtība - un tas ir slikti.

Manuprāt galīgi nav ok ar drošību. Kas tad Tev tajā cookie glabājas? salt? Nē, tas ir galīgi aplami. Tad sanāk, ka vienmēr un visur lietotāju identificēs viena un tā pati vērtība un es uzzinot salt vērtību bez problēmām varu ielogoties. Salt izmanto pavisam citam mērķim: lai ja lietotājs A izvēlas paroli suns un lietotājs B izvēlas paroli suns tomēr db saglabātās hash vērtības: Piemēram: hash($salt . $password) būtu šiem lietotājiem atšķirīgas. Izlasi to rakstu par "Secure stateless session cookies"