Kryptering av url

[grimjoey]

Akkurat ja. Så det er riktig å si:

jeg responderte til at mhbakke anbefalte session fordi cookies var enkle å endre med javascript. jeg mener det ikke spiller stor rolle. session er mer automatisert. det er fordelen.

 

om det er sikkert nok er det utvikler som avgjør.

 

Det var vel det som dro i gang diskusjonen.

Endret 15. april 2007 av grimjoey

[Ernie]

SID blir lagret på klient som en cookie. (hvis ikke server bruker GET/POST som nevnt tidligere). Lokalt lagrer serveren alle session variablene med referanse til SID.

 

Det samme kan gjøres uten å bruke "sessions".

 

Man kan legge så mange variabler man vil i en fil på serveren (fputcsv(), fwrite(), ...) med referanse til en dynamisk verdi man setter som cookie hos klient. Man kan lagre til en lokal database server. Det holder med at en referanse verdi finnes hos klient på samme måte som gjøres ved bruk av sessions.

8393596[/snapback]

I bunn og grunn altså lage din egen session-handler ...

 

Sessions er ikke noe sikrere en hva man kan få til ved bruk av PHP og cookies uten "session".

8393596[/snapback]

Nei, men å stå for det selv vil heller aldri være mer sikkert enn å bruke innebygget session i PHP siden man alltid kan definere egen session-handler som kobles opp mot $_SESSION.

 

Ernie: "Med mindre du separerer med et eller annet tegn skal det være komplett umulig." - kan du forklare?

8393596[/snapback]

Du hentydet at lagring i cookie vil være nøyaktig det samme som session. Dette er rivruskende galt siden man bare kan lagre en verdi pr. cookie. Det du tydligvis egentlig mente er at du kan bruke cookie til å eksakt det samme som PHPs session. Dog er det derimot unødvendig siden man lett kan lage egendefinert session-handler som fungerer mot $_SESSION. Ergo vil man aldri ha noen praktisk bruk for det.

[grimjoey]

Man lagrer en referanseverdi i en cookie som man bruker til å slå opp "session" verdier i en database. Det kan man gjøre med eller uten session. Ja, altså lage egen session handler. Poenget mitt var ikke at det skulle være veldig praktisk. Jeg sier at session ikke er sikrere en cookies dersom cookies brukes med fornuft. Og at det ikke kan bli sikrere ved å lage en egen session håndtering er litt situasjonsbetinget etter min mening.

 

Har man en javascript funksjon som lager en digest av et innskrevet passord og en nonce fra serveren og setter dette i en cookie lokalt (cookie blir ikke sendt over nettet), kan man få et sikrere session håndterings system. i PHP sessions er SID dynamisk i den forstand at den endres for hver innlogging. bruker man det jeg beskrev nå har man en challenge-response authentikasjon hver gang samme bruker gjør en side request. altså er SID dynamisk for hver request. da kan ikke eventuell sniffer bruke eventuell sniffet SID til å hijacke sessionen.