Computers ain't that smart, Whatever man built could be taken apart
:strip_exif()/u/26181/Hunnypot-new60.gif?f=community)
Met sessies kan 't dus wel veilig, als je 't maar aan de serverkant opslaat:
- user logt in, server controleert password, indien correct krijgt user een sessie...
- server haalt aan de hand van username userlevel uit database
- user kan met sessie alleen die dingen doen die server aan de hand van userlevel leuk vind...
zo moeilijk is 't niet hoor... pak 's een goed boek ofzo...
Als iemand weet hoe jouw systeem in elkaar zit wel (makkelijk achter te komen door te kijken hoe de cookie eruit ziet) is het makkelijk te faken, dus het is veiliger om Msql te gebruiken 
PV: 9360 WP WZW/ONO | Warmtepomp: Toshiba Estia 8kW 3fase | A+++ | 2x Zappi v2.1 | Stevens Super Flight '25
:strip_icc():strip_exif()/u/37304/crop5de64bc2d6a38_cropped.jpeg?f=community)
session gebruiken met cookie bij bijvoorbeeld 5 minuten inactifiteit automatisch de sessie beindigen
en wat heeft dat verder voor veiligheidsnut?!:
session gebruiken met cookie bij bijvoorbeeld 5 minuten inactifiteit automatisch de sessie beindigen
Computers ain't that smart, Whatever man built could be taken apart
als de sessie is beindigt is het nie meer te faken is:
[...]
en wat heeft dat verder voor veiligheidsnut?!
hadden we bij ons op school ook
mensen hadden sites met inlog , en grote boze leraartjez gingen in logs kijken 
kenne ze zo je session id kopieeren, maar als die al afgesloten is dan heb je niks meer aan session id
:
[...]
Met sessies kan 't dus wel veilig, als je 't maar aan de serverkant opslaat:
- user logt in, server controleert password, indien correct krijgt user een sessie...
- server haalt aan de hand van username userlevel uit database
- user kan met sessie alleen die dingen doen die server aan de hand van userlevel leuk vind...
zo moeilijk is 't niet hoor... pak 's een goed boek ofzo...
Lees je wel, of snap ik je niet? Wat is er mis met mijn uitleg?
/u/10340/bender2.png?f=community)
:strip_exif()/u/9959/glimi.gif?f=community)
Volgens mij snap je niet hoe sessies werken en wat het verschil is met een cookie.
Cookies:
-Een bestand op de PC van de client die de informatie bevat. Hierin staan dan dus het userlevel, al dan niet gecodeerd.
Sessies:
-Er wordt een cookie op de pc van de client opgeslagen met een uniek nummer. Dit nummer komt overeen met een bestandsnaam in /tmp In dit bestand wordt dan het userlevel opgeslagen.
Wat je dus alleen met sessies op de clientkant opslaat is het 'unieke id'. De rest staat allemaal in het bestand in /tmp op je server. Men kan dus alleen het sessie-id veranderen, maar niet de variabeles die in het bestand op jouw server staan.
Duidelijk?
Cookies:
-Een bestand op de PC van de client die de informatie bevat. Hierin staan dan dus het userlevel, al dan niet gecodeerd.
Sessies:
-Er wordt een cookie op de pc van de client opgeslagen met een uniek nummer. Dit nummer komt overeen met een bestandsnaam in /tmp In dit bestand wordt dan het userlevel opgeslagen.
Wat je dus alleen met sessies op de clientkant opslaat is het 'unieke id'. De rest staat allemaal in het bestand in /tmp op je server. Men kan dus alleen het sessie-id veranderen, maar niet de variabeles die in het bestand op jouw server staan.
Duidelijk?
hehe ligt niet aan jou. Volgens mij wordt er niet goed gelezen:
[...]
[...]
Lees je wel, of snap ik je niet? Wat is er mis met mijn uitleg?
gewoon sessie aanmaken met inloggegevens en vervolgens sessie object in een cachemanager met een timer erop. Maare.. wellicht dat de topicstarter gewoon es ff een goed PHP boek moet kopen zoals deze, want je kan toch niet verwachten dat iemand hier een compleet stuk code gaat neerzetten met daarin de specifieke oplossing.
[ Voor 0% gewijzigd door bille op 04-09-2002 09:18 . Reden: klote bb ]
Ultra Pilammo 6666Mhz AMD, 4251Mbit/s RAM, Gefors V6666 MegaTurbo, 43" TFS, Ultra 80Gig Firewire netwerkkaart en 5D geluid met 66 speakers in 5 dimensies
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
lekker is dat
... Ik heb liever niet mijn wachtwoord in een cookie staan eigenlijk. Daarnaast lijkt het me een beetje onzinnig om het op deze manier te doen. Eigenlijk maak je nu ook gebruik van de sessie techniek. Je hebt bij de client een uniek identificerende info (user + pass) waarmee op de server de bijbehorende gegevens kunnen worden gezocht (userlevel in db).
Waneer je nu gebruik maakt van sessies wordt die uniek identificerende code niet user/pass, maar een unieke random code. de serverside gegevens worden niet uit de db gehaald, maar zitten in een klein bestandje.
Dat jij sessies als 'onveilig' beschouwt en daarom maar jouw systeem gebruikt slaat dus eigenlijk helemaal nergens op. Je eigen manier is 1 onveiliger (pass in cookie, fijn voor gedeelde pc's ed) en 2 trager (elke keer dat een pagina opgevraagd wordt, wordt er weer de hele inlog + info ophaal actie uitgevoerd) zonder dat het enige meerwaarde biedt.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
:strip_exif()/u/30931/crop69301fdbe9a3f_cropped.webp?f=community)
:strip_icc():strip_exif()/u/7418/the_hat_icon.jpg?f=community){kind=icon}
Erg vermakelijke kost
Data met Encryptie eroverheen is ook nog steeds data, dus is het ook nog steeds fraude gevoelig (aangezien je data erin staat)
Stel je voor dat iemand op het idee komt om een willekeurige string te maken van x karakters, die slaat hij op bij de "ingelogde" gebruikers, logt de gebruiker in zet je de random string in een cookie, waardoor je kan opzoeken wie die gebruiker is, geen encryptie van de data, niets alleen volkomen willekeurigheden.
Ah, laat ik mezelf niet voor de gek houden, niemand zal ooit zo iets bedenken.
Data met Encryptie eroverheen is ook nog steeds data, dus is het ook nog steeds fraude gevoelig (aangezien je data erin staat)
Stel je voor dat iemand op het idee komt om een willekeurige string te maken van x karakters, die slaat hij op bij de "ingelogde" gebruikers, logt de gebruiker in zet je de random string in een cookie, waardoor je kan opzoeken wie die gebruiker is, geen encryptie van de data, niets alleen volkomen willekeurigheden.
Ah, laat ik mezelf niet voor de gek houden, niemand zal ooit zo iets bedenken.
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
Hmmm, nieuw voorstel:
data -> md5 van maken
Data + md encrypten en in cookie zetten
Op het moment dat er dan bogus data binnen komt klopt de md5 dus niet meer en kun je dus alles discarden.
Verwijderd
zucht:
Als iemand weet hoe jouw systeem in elkaar zit wel (makkelijk achter te komen door te kijken hoe de cookie eruit ziet) is het makkelijk te faken, dus het is veiliger om Msql te gebruiken
lekker antwoord
cookies zijn niet veilig DUS -> Msql
net of Msql
per definitie veilig is? onzin! en er zijn ook nog andere databases en opslagmethodes hoor als je een antwoord geeft probeer dan een zinnig antwoord te geven en niet zomaar termen de lucht in te smijten waar je ooit eens over gedroomd hebt.
sorry maar dit moest ik even kwijt
p.s. je bedoelde zeker MSsql Server ipv miniSQL?
/u/63360/cyberjack_avatar.png?f=community){kind=avatar}
En dan verloopt je sessie en ben je je object dus wel kwijt. Hoe wil je dan de user weer opnieuw laten inloggen zonder dat ie username/password moet invoeren? Zeker door op de client in zijn cookie de laatst gebruikte sessie op te slaan, die in een logintabel bijhouden, etc?
Dat is dus geen oplossing als je de site ook toegankelijk wilt maken voor mensen die hun cookies uit hebben staan. Op het moment dat mijn setcookie niet lukt geef ik nl. het sessie_id mee in de url zodat ze wel van de site gebruik kunnen maken en sessies ondersteunen zonder cookies. Op dat moment kan iemand gewoon je http requests onderscheppen en die vervolgens dus in een cookie kwakken en je bent opeens een user die toegang heeft. Erg fraude gevoelig dus.
:strip_exif()/u/52709/firelogo_s.gif?f=community)
Een ander nadel van sessie id's in URL's is dat als je een link post of naar iemand emailt, je de sessie id mee stuurt. Een tijdje terug had iemand in een online artikel over een favorite vibrator een link opgenomen naar een pagina van de "Christine Le Duc" website met daarin een sessie id.:
[...]
Dat is dus geen oplossing als je de site ook toegankelijk wilt maken voor mensen die hun cookies uit hebben staan. Op het moment dat mijn setcookie niet lukt geef ik nl. het sessie_id mee in de url zodat ze wel van de site gebruik kunnen maken en sessies ondersteunen zonder cookies. Op dat moment kan iemand gewoon je http requests onderscheppen en die vervolgens dus in een cookie kwakken en je bent opeens een user die toegang heeft. Erg fraude gevoelig dus.
Je raad natuurlijk de gevolgen hiervan, vooral toen bleek dat de sessie id's makkelijk te raden waren.
PS: Als je http requests kan onderscheppen dan heb je toch ook de inhoud van de cookies omdat die dan meegestuurd worden?
That which doesn't kill us, makes us stranger - Trevor (AEon FLux)
When a finger points at the moon, the imbecile looks at the finger (Chinese Proverb)
:strip_icc():strip_exif()/u/1000/Foto%252060x60.jpg?f=community)
Pagina: 1