Tijden veranderen
Veilige cookies
(2) Maar niemand vind het leuk als iemand anders op zijn/haar account gaat lopen prutsen.
Je wilt je bezoekers dus graag helpen met 1, maar 2 is minstens net zo belangrijk.
Vertel ons eens wat JIJ zou doen?
of een functie bouwen waarmee je de website kan locken :d.. maargoed uitloggen is net zo makkelijk
Mm. Met cookies heb ik wel een vreemd geval op me site, uitloggen kan ik wel, maar de volgende pagina ben ik weer ingelogt, maar als ik opnieuw op me site komt dan ben ik wel uitgelogt :D
IP in de cookie opslaan gecodeer
Unieke code opslaan in database + cookie (elke login actie nieuw genereren
IP opslaan in database
En als er maar in ding niet klopt
--> kill_login();
Er zal dus een controle moeten zijn om te zien of het echt het cookie is dat JIJ gemaakt hebt.
Edit: @Eris, als je toch het ip gebruikt ( DYNAMISCH bij sommige providers?! ) kun je net zo goed je sessies in je database regelen.
Dan KAN er niet mee geknoeid worden :)
Sebastiaan:
Ik zou gewoon voor 1 kiezen. Ik gebruik een BB parser die geen vreemde JavaScript codes toelaat.
Dat wil niet zeggen dat je geen ander lek hebt.
Dus is het wel degelijk een issue.
Gewijzigd op 04/01/2006 17:41:00 door Mitch X
@Sebastiaan: laten we PHPFreakz eens even gaan terroriseren >:)
Gewijzigd op 04/01/2006 17:47:00 door Jelmer -
Alleen met deze random code en vanaf dit ip-adres kan men inloggen. De unieke code wordt bij iedere login ververst.
Vanaf 1 (bekend!!!) ip-adres binnen 5 minuten meer dan 3 foutieve inlogpogingen? Dan een lock van x minuten. Brute-force hacking gaat dan een eeuwigheid duren, maar blijft altijd mogelijk. Daar doe je niets aan, dat hoort bij de functionaliteit van automatisch inloggen.
Dat zou jammer zijn niet?
Jelmer:
Ik heb al eens gedacht aan zoiets, zie hier mijn ontwerp :)
@Sebastiaan: laten we PHPFreakz eens even gaan terroriseren >:)
@Sebastiaan: laten we PHPFreakz eens even gaan terroriseren >:)
En jij denkt dat dan nog kan?
Mitch:
Hun idee is goed: SpampointsEen streng beleid is niet zozeer slecht, maar jaagt ook een deel van de doelgroep weg :(
Dat zou jammer zijn niet?
Dat zou jammer zijn niet?
Hun beleid niet: Je krijgt veel te snel spampoints
Hoe ze ermee omgaan ook niet: Bij iedere spampoint vertraagt de site x seconden. (dat hoeft hier niet :-D)
Toch wordt het wel tijd dat die spampoints ook hier ingevoerd gaan worden vind ik...
PHPhulp tegen PHPFreakz.......
Hun beleid niet: Je krijgt veel te snel spampoints
Hoe ze ermee omgaan ook niet: Bij iedere spampoint vertraagt de site x seconden. (dat hoeft hier niet :-D)
Toch wordt het wel tijd dat die spampoints ook hier ingevoerd gaan worden vind ik...[/quote]
Dan krijg jij je eerste 50? En wat schiet je er dan mee op 'spam points'.
Steffan:
En wat schiet je er dan mee op 'spam points'.
Als je er 500 hebt mag je gratis een kwartiertje spammen zoveel je wilt.
Quote:
Hoe dat zo? Ik ben hier niet degene met de meeste dubbelposts.Dan krijg jij je eerste 50?
Quote:
Bestraffing voor dubbelposts en spammen (van script, tuts, etc)En wat schiet je er dan mee op 'spam points'?
of je nou een code in de cookie zet en de daadwerkelijke info in de db, het geeft nog alle toegang, want dan heb je enkel de code nodig. Welk is dat een eerste stap want dan kun je de lifetime niet veranderen :).
Je wilt niet dat het zo is dat als de gebruiker z'n browser sluit en weer opent dat hij dan weer is uitgelogd, dan valt het idee weg...
Je kan wel aan een IP vast binden, maar dan zijn de dynamische gebruikers het slachtoffer :/.
Ik zou zeggen zorg dat de code in het cookie vaak genoeg vervangen wordt, zodat er geen tijd is voor misbruik? =S
Legolas:
ff denken over het probleem...
of je nou een code in de cookie zet en de daadwerkelijke info in de db, het geeft nog alle toegang, want dan heb je enkel de code nodig. Welk is dat een eerste stap want dan kun je de lifetime niet veranderen :).
Je wilt niet dat het zo is dat als de gebruiker z'n browser sluit en weer opent dat hij dan weer is uitgelogd, dan valt het idee weg...
Je kan wel aan een IP vast binden, maar dan zijn de dynamische gebruikers het slachtoffer :/.
Ik zou zeggen zorg dat de code in het cookie vaak genoeg vervangen wordt, zodat er geen tijd is voor misbruik? =S
of je nou een code in de cookie zet en de daadwerkelijke info in de db, het geeft nog alle toegang, want dan heb je enkel de code nodig. Welk is dat een eerste stap want dan kun je de lifetime niet veranderen :).
Je wilt niet dat het zo is dat als de gebruiker z'n browser sluit en weer opent dat hij dan weer is uitgelogd, dan valt het idee weg...
Je kan wel aan een IP vast binden, maar dan zijn de dynamische gebruikers het slachtoffer :/.
Ik zou zeggen zorg dat de code in het cookie vaak genoeg vervangen wordt, zodat er geen tijd is voor misbruik? =S
Het grote probleem met cookies is dat ze onderschept kunnen worden en op een slecht beveiligde pc via internet uitgelezen kunnen worden. Wanneer een ander over het cookie beschikt, kan hij dus inloggen. Welliswaar een beperkte tijd, maar het kan. De koppeling met het ip-adres is, volgens mij, de enige manier om met enige zekerheid te kunnen stellen dat de gebruiker ook de eigenaar van het cookie is. Alle andere manieren zijn per definitie onveilig omdat alle benodige gegevens in het cookie staan. Iedereen die over dit cookie beschikt, kan zo inloggen.
Al blijft de vraag welke veiligheidsrisico's je loopt en wat de financieele schade is. Overigens is ook reputatieschade in geld uit te drukken.