PHP login security

Naravno da ne stavis samo username. Poena je da se stavi i jos nesto sto ce korisnika "odvojiti" od drugih. Recimo, neki ID ili tako nesto. Na kraju krajeva, ako bas hoces sigurnost, koristis i kriptovanje, MD5 ili DES. Ima mnogo tehnika za takve stvari...

Kako bi ti to uradio???

hmmmm
pa dobro recimo da napravi jedan cookie u koji stavis username i nalpravis drugi cooki u koji stavis neki random dugachak number... e sad kako, mislim ono kako da s eproverava taj random number ??? uh moram priznati da sam slab sa kukijima

uspori malo...
ako je potreban visok nivo sigurnosti, normalno je da ces dodati jos detalja - na primer, prilikom svakog logovanja dodas cookie sa nekim random id-em (nalik na session_id) koji istovremeno upises u bazu za tog korisnika. posto sve (u tom slucaju) ide preko ssl-a, male su sanse da ce neko da "pokupi" taj broj, a ti ga koristis umesto passworda... mada to nije toliko bitno jer ako koristis ssl mozes i password da mu stavis u cookie, na kraju krajeva...
s druge strane, pogledaj cookie koji ti je "zalepio" elitesecurity.org. jasno je - bezbednost nije esencijalna, pa je ustupila mesto komforu...

Potpis

= come get some =

ja sam ga danas napravio sa md5 i ne diram vishe

Evo, ulećem i ja u diskusiju.

Palo mi je napamet da korisniku u cookie smestite dva podatka - njegov username i string koji sadrži krptovani (na samo vama znan način) username tog korisnika.
Znači, standardnom crypt funkcijom ili nekom vašom one-way crypt funkcijom.

Naravno. Ovo je idealno. Ili da svaki korisnik nema prost integer kao ID broj za njega, vec da ima ono sto SQL Server zove "unique ID" tj. string od 32 karaktera koji se nasumicno bira za svakog korisnika. Pa neka macam pogadja do prekosutra...

ja samnapravio da ovako:

jedan cookie -- username
drugi cookie --- cr_pass=md5 password
treci cookie --- random $temp_id

i onda u member.php poredi if isset($username) and $cr_pass== sa criptovanim passwordom iz baze and temp_id=tempid(iz baze). ako sve ovo prodje onda ga pusti,inache ne.

Moze i samo sa jednim jedinim kolacicem.

$sessionstr = $username . crypt($password) . microtime();
$cookiesession = md5($sessionstr);

Ovaj $cookiesession se smesta u bazu u polje session (or something) kad se korisnik uloguje, i kasnije se provera da li je ulogovan korisnik vrsi po tome.

Provera je krajnje jednostavna:

- proveri se da li postoji cookie, i ako ne postoji korisnik nije ulogovan..
- ako postoji, proveri se da li postoji korisnik sa istim session-om u bazi, ako ne postoji, znaci da nije autenticni cookie session
- ako postoji, korisnik iz rezultata provere u bazi je taj ulogovan korisnik.


Veoma efektivno - vec sam ovo predlozio Gojku da implementira u ES forum proveru. Ja ovakvu proveru koristim za skoro sve Web aplikacije koje radim, i verujem da ne postoji nacin da se prevari
ovakva provera.. Naravno, cookie je moguce prosiriti prilepljivanjem jos jednog microtime()-a na kraj stringa kriptovanog md5 funkcijom (cisto ako ste paranoik)..

Uz to, krajnje je jednostavno.

Poz, alex.

Potpis

Alex: My favorite site is http://localhost/
R.J. Oppenheimer: "I am become death, destroyer of worlds" (1945 AD)
tweet.13x ||
linkedin.13x

ovo gore sto sam napisao RADI, tako da......

Pazi, ima milion nacina. Ovaj sa bazom nije los, ali kako onda pravis "garbage collection", odnosno, kako radis brisanje iz baze??? Recimo, ako korisnik ode da jede sendvice i vrati se i uradi refresh?? Istekne cookie, to je OK, on se vraca nazad na stranu za logovanje, ali da li u tom trenutku se brise ono sto je u bazi ili ne??? :))

Sve ima svoje zasto... :)) I zato...

pri svakom logovanju se vrsi dodeljivanje novog temp_id , znachi overwriteuje ga

inache, stavis da cookie traje vechno i eto ti refresh.

hej a sta ce ti cookie sa pass-om (kriptovanim ili ne, whatever)
pretpostavka da ako je high security onda nema pamcenja sifre, tako da mi taj detaljcic izgleda kao cist visak... u protivnom (ako pamti sifru) visak je taj temp_id, posto nema logovanja, jel'.

Potpis

= come get some =

pa sifru mora da pamti i sifra mora da se kriptuje


jer ako nema sifre u cookiju onda bi neko mogao da napravi cookie u kome ce biti username nechiji i takodje da napravi cookie u koji ce da stavi neki temp_id, sta znas mozda bas i pogodi temp_id .

a kriptovani pass je jos korak vise ka sigurnosti, znachi nema sansi da neko pogodi bas kako glasi kriptovani password, tako da......

Ali mozes temp_id da napravis u nekom fazonu, recimo da bude ec pomenuti random string od 32 karaktera, slova i brojevi, i da zatim kriptujes username i eto ti lepote... :))

hehhehhe... interesting.
dakle mogao bi da pogodi temp_id od npr. 30 brojeva (ili karaktera, whatever), lakse nego da "nabode" sifru od tipicno 5-10?!?!?

a i nesto oko tog nabadanja - cuveni problem malih verovatnoca:
"koja je verovatnoca da ce sto majmuna sa pisacim masinama napisati encyclopedia britannica?"

dajmo, ljudi, uozbiljimo se...

Potpis

= come get some =

sifra je kriptovana....... a ko ce da pogodi kriptovanu sifru ??????!!!!!!!

pa dogovori se... jel' moze da pogodi ili ne?
kriptovanu sifru i temp_id mozes da posmatras kao jedno te isto...

Potpis

= come get some =

temp_id je jedan devetocifreni broj ili tako nesto, znachi samo brojevi

a kriptovana sifra je nesto tipa xfdsigf8b789789hb7b7gf897897ngfngnbklgj45436

znachi sadrzi i slova i brojeve tako da je teze pogoditi kriptovanu sifru nego temp_id

pa *ebo ga otac, gluvonemi bi se bolje sporazumeli od nas dvojice...
ko ti, naime, definise taj "temp_id"? ko ti brani, da ga generises sam, u obliku i po algoritmu koji najbolje odgovara nivou paranoidnosti koji zelis da primenis? sto ne bi bio varchar(128)?

a, u principu, samo pokusavam da ti dokazem da je nesto od ta dva (temp_id ili password) suvisno u cookie-u. inace se slazemo u metodu. a i razvodnili smo topic do bola. da ga batalimo?

Potpis

= come get some =

ajde