Sastavljam skriptu za registraciju na stranicu. HTTPS mi trenutno nije opcija, a opet volio bih da proces registracije i logina bude sto vise siguran.
Ok, mogu enkriptirati sifru pa ona nece biti vidljiva u izvornom obliku u Cookiu. Ipak, ako bi npr. zlonamjerna strana dosla u posjed Cookia, mogla bi otvoriti session.
Postoji li mogucnost enkripcije Cookia na nacin da ako bi treća strana pokusala pristupiti s istim cookijem, ona to ne bi uspjela? Ja trenutno koristim obicnu post metodu za registraciju i za login.
zašto opće spremati lozinku (U BILO KOJEM FORMATU -> hash, enkriptirana…) u cookie, to se tako ne radi i nikako se ne preporuča… ti spremaš neki random hash u cookie koji nema veze s lozinkom…
OK, ali ako je sifra u Cookiu enkriptirana kako ju netko moze otkriti? Jedini rizik koji ja tu vidim je da se sifra nalazi u nekom md5/hash dictionaryju. Ali zato bi korisnik trebao izabrati neku random sifru. Nisam stručnjak za security pa ne znam, mozda postoji jos neki razlog zasto se sifra u hash formatu ne bi trebao prenositi u Cookieu.
Nego… Bez obzira prenosi li se sifra ili rendom hash, opasnost od cookie hijackinga postoji… kako to spriječiti? A bez SSL-a.
enkripcija!=hashiranja
ti trebaš stvoriti neki random hash spremit ga u bazu i sljedeći put provjeravat taj hash, to je naravno samo za zapamti me, a inače imaš session i baš te briga što je u cookieju php vodi računa o tome…
Ma ne treba mu nikakvi random hash, dovoljan je bilo koji unique broj/string koji ga moze identificirati. Sve ostalo je bezveze kompliciranje koje ne povecava sigurnost.
da i s ovime bi onda lik mogao staviti npr id korisnika koji je primary key i autoincrement, pa onda lik samo promjeni broj u cookieju i ulogiran je pod bilo što, unique broj string svakako - ali ništa što netko može povezati i promjeniti da ukrade nekom session…
Kao i bilo koje otkrivanje unutrasnje strukture baze i podataka (direktno mapiranje djelova baze u djelove vanjskog prikaza), ta praksa nije dobra. Unique broj/string ne bi trebao imati nikakve direktne veze sa bazom i podacima u bazi (jedino bi se trebao/mogao cuvati u bazi), a trebao bi dovoljno “velik” i “rasprsen” da se ne moze pogoditi (takvi su uglavnom generatori random brojeva).