Session id met/zonder cookie?
Dus veel gaat net wat anders dan normaal...
Ik werk ook niet met gewone database, maar sla gegevens anders op.
Nu wil ik graag wat advies over een session.
Veelal worden voor sessions een session id gebruikt en een cookie.
Ik heb die sesssions alleen nodig op alle pagina's voor het herkennen of iemand lid is.
Want alleen zo kan er op de diverse items gereageerd worden.
Dat kan vanuit de sessie id.
Bezoekers kunnen wel lezen maar niet reageren.
Nu achterhaal ik al het ipv4 of ipv6 adres.
Ik heb nogal wat gelezen over maatregelen tegen hackers wat betreft sessions
En de cookies en sessions id.
ik hoef alleen te kunnen beschikken over het lidmaatschapsnr .
Dat zou ik kunnen verwerken in de session id. (En tijdelijk opslaan).
En dan nog alleen op de pagina's waar wat te reageren valt.
Hoe veilig is dat als ik die session ter controle ook vergelijk met het ipadres of ander vast gegeven (username?)
Dus zonder cookie.
Hans De Ridder op 13/08/2017 14:53:48:
Dus zonder cookie.
Een session maakt standaard zelf een cookie.
Quote:
http://php.net/manual/en/intro.session.php Session support in PHP consists of a way to preserve certain data across subsequent accesses.
A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.
A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.
Toevoeging op 13/08/2017 15:04:32:
IP is onbruikbaar omdat er scholen/bedrijven zijn die geheel achter 1 ip-nummer functioneren. Ook bij een mobieltje omdat daar het ip-adres nog al eens wijzigt.
Dan toch maar zo veilig mogelijk een session id en cookie aaanmaken.
Als ik voor de session id het al dan niet versleutelde lidmaatschapsnummer gebruik, is dat dan veilig?
Of zitten daar ook nadelen aan?
Moet alles nog op een rijtje zetten.
Maar bedankt voor je reactie.
Ben alles aan het omzetten van database naar alternatief.
En daar kwam ik ook de session tegen.
Gewijzigd op 13/08/2017 16:20:42 door Hans De Ridder
Quote:
IP is onbruikbaar omdat er scholen/bedrijven zijn die geheel achter 1 ip-nummer functioneren.
Dit lijkt mij geen probleem, omdat iedereen nog steeds moet inloggen neem ik aan? Het IP is enkel een extra controle om te kijken of een sessie wel van een (redelijk) betrouwbare gebruiker afkomstig is. Als je de school of het bedrijf niet echt kan vertrouwen (omdat anderen mogelijk netwerkverkeer afluisteren of dat je zelf laks bent met het gebruiken van (publieke?) machines omdat je bijvoorbeeld je browsercache niet opschoont na gebruik of dat dit niet automatisch gebeurt) wordt het een ander verhaal natuurlijk. Als je zorgt dat je website HTTPS gebruikt wordt afluisteren van netwerkverkeer nagenoeg onmogelijk.
Quote:
Ook bij een mobieltje omdat daar het ip-adres nog al eens wijzigt.
Als dit een issue is moet je hier voorzieningen voor treffen uiteraard.
Quote:
Als je daar dan een hash van maakt lijkt het mij wel veilig.
Nee want als iemand het sessie id op een of andere manier bemachtigt ben je nog steeds nat, aangenomen dat je geen andere voorzieningen treft. Sessie-data komt een gebruiker toch niet aan maar als een gebruiker toegang heeft tot het sessie-id dan heeft 'ie in principe de sleutel naar deze data. Het is dan zaak dat je additionele controles doet (zoals een IP-check) om de identiteit van een gebruiker
Gewijzigd op 13/08/2017 16:38:03 door Thomas van den Heuvel
Ik heb meerdere opties. Gaat mij vooral om gebruiksgemak.
In principe zal reageren gebeuren via een form (email naar email).
Bij een session kan ik het emailadres terugvinden van het reagerende lid.
Ik kan in de form wel vragen om gebruikersnaam en wachtwoord..
En dat checken.
Maar is niet zo gebruiksvriendelijk.
Dan is inloggen alleen noodzakelijk bij wijziging(en) in registratiegegegevens.
En het insturen van documenten en flyers.
Maar dat gaat via pagina's die los staan van de openbare pagina's.
Het enige wat je in principe hoeft te onthouden in een sessie is een user id, na een succesvolle login. De rest stop je in de database en vraag je elke page-access met een query op (inclusief controle op IP waarmee het meest recent is ingelogd, of een andere manier om te garanderen dat niemand de sessie heeft overgenomen).
De reden waarom je geen userdata bijhoudt in een sessie is omdat deze dan elke keer geupdate zou moeten worden als deze in de db verandert, of mogelijk is het dan moeilijker om mensen geforceerd uit te loggen als je ook privileges (die je dan niet makkelijk kunt intrekken) in de sessie opslaat. Dit soort informatie zou je gewoon elke page-access opnieuw moeten opvragen middels eerder genoemde user id. En hierbij voer je dus wat extra controles uit, je neemt niet klakkeloos aan dat iemand is wie die zegt te zijn enkel en alleen op grond van sessie id.
Gewijzigd op 13/08/2017 22:06:46 door Thomas van den Heuvel
Iets dergelijks was ik ook van plan.
Als ik zover ben, dan meld ik me wel meer mbt dit punt.
Ik stel me zo het volgende voor:
- inloggen
- controle gegevens (eventueel met ook ip, en inlogpogingen, en inlogvertraging 2 seconden)
- cookie aanmaken met hash
- cookie waarde in database. (Bij mij alternatief)
Bij pagina's waar ik info moet hebben van lid:
- cookie vergelijken met database.
- info ophalen
- inhoud cookie wijzigen in database en bij lid.
- instellen tijd cookie bij inactiviteit.
Wat zou hier dan nog het doel zijn van een session?
Gewijzigd op 17/08/2017 12:22:11 door Hans De Ridder
- inloggen
- controle gegevens (eventueel met ook ip, en inlogpogingen, en inlogvertraging 2 seconden)
- cookie aanmaken met hash
Cookies zijn immers client-side en sessions server-side
Als men de cookies lokaal verwijderd, ben je weer terug bij het inloggen, wat je dus met sessions kan opvangen.
Dus terug naar je laatste vraag: "Wat zou hier dan nog het doel zijn van een session?"
Waarom cookies gebruiken als het ook met sessions kan?
Misschien maak ik wel een denkfout bij gebrek aan kennis van PHP.
De site is in principe openbaar.
Maar reacties kunnen alleen door leden worden gegeven.
Gaat trouwens hoofdzakelijk dan om email die bekend moet zijn om reactie te versturen.
Documenten toevoegen, en flyers, youtubes, enz. daar moet wel voor ingelogd zijn.
Als ik met cookie werk, dan zijn de gegevens direct beschikbaar.
En hoeft men in principe niet in te loggen.
Of zie ik wat over het hoofd?
1. waarom wil je geen database gebruiken?
2. Of je nou een database gebruikt of niet, wat jij wil bereiken is altijd mogelijk.
Geeft eens duidelijk aan wat je echt daadwerkelijk wilt bereiken want deze 2 teksten geven mij het idee dat je verkeerd bezig bent:
"Misschien maak ik wel een denkfout bij gebrek aan kennis van PHP."
"Ik ben bezig met experimentele site.
Dus veel gaat net wat anders dan normaal...
Ik werk ook niet met gewone database, maar sla gegevens anders op."
Dat werkt prima via PHP.
Dus is wel een soort database, maar niet volgens de 'normale' begrippen.
En de problemen en oplossingen blijven ook grotendeels hetzelfde.
Het is een site voor promotie van artiesten, die zelf de gegevens aanleveren.
Het inloggen zal niet zoveel problemen geven.
Inloggen is nodig voor aanleveren (en wijzigen) van documenten, flyers, enz.
Het bekijken van de site is openbaar.
Maar als er vragen gesteld worden, dan kunnen alleen leden daarop reageren.
Dat reageren gaat via email van het ene lid naar het andere lid.
Dus van het reagerende lid moet ik wat gegevens hebben (naam, email).
Die kan ik krijgen via inloggen, maar ook via een cookie.
Het is wat onpraktisch als lid gewoon wat bladert op de site.
En dan ergens reactie wil geven, en daarvoor moet inloggen.
Vandaar dat ik aan cookie denk.
Lijkt me wel veilig, wanneer steeds de inhoud van de cookie wordt gewijzigd.
Na het inloggen werden beiden in zowel de cookie als de database opgeslagen, en als ze overeenkwamen, dan waren ze ingelogd. Natuurlijk speelde er ook de mogelijkheid dat iemand een cookie zou stelen, maar dat heb ik toen tegengegaan met een IP-lock die een gebruiker bij het inloggen aan kon zetten waarmee de inlogsessie alleen als extra veiligheid op een bepaald IP geldig is.
Nu gebruik ik gewoon een PHP-session. En het is ook aan te raden om session_regenerate_id te gebruiken tegen session hijacking of session fixation. Dit doe je dan direct na het inloggen. Op die manier is de eerder aangemaakte sessieID ongeldig en vervangen door een nieuwe. Dus als iemand van te voren je SessionID heeft gevonden, dan is die niet meer geldig zodra jij inlogt. Dit kan je natuurlijk ook uitvoeren op je gehele site.
Leuk leesvoer ervoer staat hier:
https://stackoverflow.com/questions/22965067/when-and-why-i-should-use-session-regenerate-id
Gewijzigd op 17/08/2017 13:52:29 door - Ariën -
Heb snel de link doorgelezen.
Maar ook daar is het wikken en wegen over gebruik van de sessions.
Of je geeft zowel een hacker als de klant de mogelijkeid om zich aan te melden.
Of je hebt de mogelijkheid om de klant buiten spel te zetten in bepaalde situaties.
Het is natuurlijk een promotiesite.
Dus veel gegevens zijn te lezen.
Meeste problemen zouden veroorzaakt kunnen worden door jatten van adres, email.
Dat adres is ook niet verplicht bij registratie.
Men heeft daarbij de keuze uit niets, postcode, volledig adres.
Wel makkelijk vanwege zoektocht in de embedded googlemaps.
De verschillende pagina's zijn ook al klaar.
Gaat nu vooral nog om het inloggen, en het vragen om de gegevens bij een reactie.
Dat inloggen lukt wel.
Maar ik twijfel nog over inloggen voor reactie geven.
Als dat automatisch kan met PHP, heel graag...
Zou mijn methode met cookie anders een groot veiligheidsprobleem kunnen opleveren?
Het enige voordeel als enkel cookies gebruik is dat je controle de sessies hebt. Zo kan een gebruiker zijn inlogsessie die hij gemaakt heeft op zijn werk weer thuis uitloggen. Met normale sessies in PHP is deze na een kleine 30 minuten inactiviteit weer uitgelogd.
Gewijzigd op 17/08/2017 14:15:25 door - Ariën -
Ik heb nu de mogelijkheid dat leden na inloggen op andere locatie een mail ontvangen.
En via de mail worden verwezen naar pagina om dit extra ip-adres te kunnen toevoegen. (moet ik nog uitwerken)
Is ook nodig bij GSM als IPadres wijzigt of je gebruikt regelmatig meerdere locaties (GSM, PC, Ipad, Werk)
Ik denk nu toch in de richting van de cookie.