[php] Stappenplan inlog script

[RSD]

Kan iemand hier een goed stappen plan plaatsen hoe je het beste een veilig login script kan maken met php.
Er moet tevens een "save password" met behulp van cookies inzitten.

Ik heb al tig login scripts gemaakt en ze werken allemaal, maar toch heb ik het idee dat ze niet geod werken of dat ik overbodige dingen doe. Met name het save password gebeuren. Hoe kan ik dit het beste met cookies doen. Ik vraag geen compleet script, maar meer een stappenplan, het script kan ik zelf wel maken. Op web dev had ik wel iets moois gevonden, dat was een class, nu ben ik niet zo thuis in classes, ik snap de bedoeling wel en kan er meewerken en aanpassen, maar om zelf classes te maken... nee liever niet. Ik vroeg me ook af of het gebruik van classes nu voordelen heeft of nadelen. Ik heb gelezen dat het wat trager is.

[T-MOB]

Een stappenplan ga ik niet voor je schrijven .

Wat betreft veiligheid denk ik dat je het veiligst bezig bent als je in het cookie dat je plaatst een cliënt specifieke code plaatst. Bijvoorbeeld een hash van het ip adres. Bij het inloggen plaats je dan een cookie met
1) een referentie naar het user_id (iig níet de gebruikersnaam)
2) een hash van het password
3) een hash van het ip-adres
Eventueel kun je 2 & 3 eerst samenvoegen en 1 hash uitvoeren.

Op deze manier kan iemand die het cookie "hijacked" nooit een username / password combinatie uit het cookie kraken. Tevens zal een gestolen cookie niet makkelijk leiden tot ingelogd zij door degene die hem steelt.
Probleem dat blijft is dat bij het inloggen zelf de boel onversleuteld wordt verstuurd.

Om het jezelf gemakkelijk te maken kun je het stuk script dat de login-status bepaalt natuurlijk in een aparte file zetten in deze in elke pagina includen. Op mijn eigen pagina levert dit stukje script 3 variabelen 1) een boolean var die wel / niet ingelogd aangeeft 2) De gebruikersnaam van iemand die ingelogd is en 3) het gebruikersid (met het oog op databeest-acties).

[gorgi_19]

Kijk eens naar het stukje over de beveiliging van websites uit de FAQ

Verder ben ik wel benieuwd wat jouw eigen ideeen zijn voor een stappenplan. Andere users kunnen dan makkelijker op- en aanmerkingen geven.

[Infinitive]

Ik denk dat inloggen met php en stappenplannen hier al wel wat vaker voorgekomen zijn. Aan de andere kant, zullen dat niet de meest toegankelijke topics zijn met informatie her en der.

Veilig is bovendien wat lastig in dit geval: je kan het jezelf zo moeilijk maken als je maar wilt. Zo zou je bijvoorbeeld willen dat je SSL gebruikt bij het inloggen zelf, maar dit kan soms wat lastig te realiseren zijn en in veel gevallen ook helemaal niet nodig. Daarvoor zou je een risico analyse moeten doen: welke zwakheden heeft je inlogproces en wat is daarvan acceptabel.

Maar goed, zomaar even wat punten op een rijtje:
- werk met sessies: als iemand inlogt, wijs diegene een groot, uniek en vooral random nummer toe en sla dat in het cookie op. Op de server houdt je vervolgens bij dat je dat nummer hebt toegewezen aan die persoon. Zodra je in een cookie dat nummer tegenkomt, dan weet je dat het die persoon is. Er zit een maximale levensduur op dit nummer die je eventueel ook nog regelmatig ververst. Het nummer moet groot en random zijn, want anders zou iemand dit mogelijk kunnen raden.

- Als iemand een onbekend sessie nummer gebruikt, wacht dan een random aantal seconden voordat je als antwoord geeft dat hij een ongeldig sessienummer gebruikt en je het cookie weggooid.

- login pagina met SSL waar gebruikers hun username en wachtwoord kunnen invullen als het cookie nog niet aanwezig is. Bij verkeerde username en wachtwoord weer een random aantal seconden wachten.

Gebruik eventueel een combinatie van: sessienummer via je links en hidden forms voor mensen die alle cookies rejecten. sessienummer in een tijdelijk cookie voor mensen die permanente cookies rejecten. sessienummer in een permanete cookie voor mensen die ook na afsluiten van het browserwindow nog ingelogd willen blijven.

[RSD]

Die had ik al doorgelezen, maar ik ben meer op zoek naar de acties die genomen moeten worden. Dus bijv:

1. Men klikt op inloggen en vult wachtwoord + username in en vinkt save password aan.

2. Check of combinatie klopt en of save password aangevinkt is

3. Zo ja, plaats cookie met een hash van inloggegevens en maak sessie aan

4. Zo nee, geef error

Stap 3 is voor mij dus een probleem, hoe kan ik dit het beste doen? Ik zou graag deze stap iets verder uitgewerkt zien. Dat inloggen ed lukt me wel, maar die combinatie met dat save password gebeuren daar zou ik wel eens wta meer over willen horen.

[RSD]

Eigenlijk kan ik het beste een user een unieke string van characters geven, die deze persoon toegewezen krijgt bij het aanmelden. Als deze user cookies accepteert en ingelogd wil blijven als de user zijn browser afsluit, deze string opgeslagen wordt in een cookie. Als deze later terug komt op de site en deze string staat in de database geregistreerd als zijnde een valid user, dan mag deze user door. Deze string is dus een extra kollom in de database.

Daarnaast kunnen users ook inloggen door het invullen van de juiste combinatie van password en username. Ik heb ooit geprobeerd eens zoiets te maken, maar het werd op een gegeven moment zo een rommeltje. Dat allerlei variabelen ed door elkaar heen liepen.

[T-MOB]

Stap 3 is toch een kwestie van de juiste duur van je cookie instellen?

If (save password) { $ttl = erg lang } else { $ttl = 0 }

Met een duur van 0 blijft je cookie staan totdat de browser wordt afgesloten, anders totdat $ttl is afgelopen.

edit:
Als je met sessies werkt kun je toch zowieso gebruik maken van session.cookie_lifetime

[ Voor 17% gewijzigd door T-MOB op 30-04-2004 11:11 ]

[RSD]

Maar goed dan zou ik dus helemaal geen sessies meer nodig hebben?

Ik kan dan alles met cookies doen.. wat volgens mij niet echt aan te raden is?

[Skaah]

Ik zet een md5hash (1) in een koekje op de client en in de database,
en een clientafhankelijke hash (2) in de datbase.
vervolgens vergelijk ik die elke keer met elkaar.
De laatste hash maak ik op elke pagina opnieuw en is afhankelijk van het ip, de browser, de taalinstelling.

Als je wilt kun je me mailen voor de hele class. (GPL)

[Roa]

Hmmm, nou, mijn systeem dan maar.

User logt in, password word gecodeerd in javascript en dan pas verzonden. Om ervoor te zorgen dat de verzonden data nutteloos is mocht het onderschept worden, wordt er een bepaalde hash gebruikt van username + password, zodat de verzonden informatie nooit alleen een gecodeerde versie van het wachtwoord is. Als men dan die hash onderschept, kan je er toch niets mee.

Dan wordt het gecontroleerd en als alles klopt maak ik in de database tabel sessions een rij aan voor die user. Hierin staat een session_id an random cijfers+letters in md5, + de user_id, om te voorkomen dat een session_id dubbel voorkomt (kans is klein, maar nu issie er helemaal niet. Naast een session_id sla ik user_id, user_name, user_status, naja, iig, dingen die ik op de site gebruik op. De session_id wordt opgeslagen in een sessie.

Bij iedere pagina wordt session.php geinclude. Daarin wordt gekeken of er een sessie is, en welke session-rij daaraan verbonden is. De informatie wordt opgeslagen in het object $user_gegevens. Is er geen session, dan wordt $user_gegevens false.

Als ik wil checken op inloggen doe ik gewoon

PHP:

if($uid != '')

Enzovoorts, enzovoorts.

Alle passwords staan gecodeerd in m'n database; er is geen textversie van. Als iemand z'n password vergeet kan hij z'n username invullen in een form. Hier wordt een nieuw random password gemaakt en een mailtje verzonden naar het e-mail adres van de gebruiker. Pas als hij de daarin gezette link opent wordt het newe password actief, tot die tijd is gewoon het oude password actief. Dit is om te voorkomen dat gebruikers de passwords van andere gebruikers zomaar resetten.

Voor altijd ingelogd gebruik ik cookies. Er wordt gewoon in het session.php script gekeken of altijd ingelogd aan of uit staat (dit staat in de database bij de usergegevens), zoja, zet een cookie met de session_id + een timestamp, zonee, doe nix. Als er een cookie wordt aangetroffen door het session.php script (en er is geen sessie aanwezig) dan wordt met de informatie uit het cookie een nieuwe sessions gemaakt, mits de oude nog bestond (dus de session_id een geldige rij teruggeeft).

Zo. Volgens mij klopt het nu wel. Nadeel van sessies is wel dat bij het openen van een newe browser (dus opnew ie.exe openen, wat genoeg users doen) de sessie leeg is, en dus de gebruiker uitgelogd zou zijn. Dat vang ik nu dus op en log de user automatisch in.

[Verwijderd]

kijk hier eens http://www.phpfreakz.nl/artikelen.php?aid=98 Een loginscript met sessies, cookies, en een MySQL database. Ik ben er net mee bezig in het kader van mijn eerste php projectje, en het stond binnen 20 mins op de server...
HTH

[crisp]

een md5( username + password) is nog altijd static en dus te bruteforcen als je die kan sniffen (username is meestal toch al bekend); een challenge meehashen is dus in mijn ogen de beste manier om sniffing uit te sluiten. Als je vervolgens serverside een sleep(1) (of meer) inbouwt na een foute inlogpoging is een brute-force attack al bijna onmogelijk via een login script.

[Marijn_S]

crisp schreef op 30 april 2004 @ 17:21:
Als je vervolgens serverside een sleep(1) (of meer) inbouwt na een foute inlogpoging is een brute-force attack al bijna onmogelijk via een login script.

Als je een sleep doet NA een foute inlogpoging is het inlogscript nog steeds te brute-forcen toch? Iemand kan dan blijven proberen omdat hij toch steeds dezelfde pagina opnieuw opvraagt, die sleep maakt dan weinig uit. Je zou die pauze dan altijd moeten uitvoeren, maar dat is weer irritant voor de gebruiker die wel goed inlogd.

Welke oplossing zou hier voor zijn?

[creative8500]

[rml][ php] User authenticatie veilig? "Hacker-proof"?[/rml]

[Shadowman]

Cerberus schreef op 30 april 2004 @ 23:00:
[...]


Als je een sleep doet NA een foute inlogpoging is het inlogscript nog steeds te brute-forcen toch? Iemand kan dan blijven proberen omdat hij toch steeds dezelfde pagina opnieuw opvraagt, die sleep maakt dan weinig uit. Je zou die pauze dan altijd moeten uitvoeren, maar dat is weer irritant voor de gebruiker die wel goed inlogd.

Welke oplossing zou hier voor zijn?

Als je per foute login dat ip voor een seconde banned dan is het probleem met bruteforcen al een stuk minder. (En je kunt makkelijk na een aantal pogingen zo'n ban wat langer laten duren).

Bruteforcen werkt ws door telkens door elkaar een nieuwe loginpoging te sturen en zodat het sleep(1) voor iedereen geen effect heeft. Verder zie ik ook niet waarvoor je het voor iedereen wilt doen terwijl je kunt checken of iemand goed inlogt of niet en aan de hand daarvan een sleep uit te voeren .

edit:
slee

[Marijn_S]

Shadowman schreef op 30 april 2004 @ 23:07:
[...]

Als je per foute login dat ip voor een seconde banned dan is het probleem met bruteforcen al een stuk minder. (En je kunt makkelijk na een aantal pogingen zo'n ban wat langer laten duren).

Zo'n IP-ban is dan een goede optie ja.

Verder zie ik ook niet waarvoor je het voor iedereen wilt doen terwijl je kunt checken of iemand goed inlogt of niet en aan de hand daarvan een sleep uit te voeren .

Omdat je dus gewoon dan lekker door kan brute-forcen. Zo'n sleep merk je toch niet meer als je de pagina opnieuw opvraagd. Al zou ik dus nooit de sleep ervoor uitvoeren omdat dat dus te irritant is.

[Shadowman]

Cerberus schreef op 30 april 2004 @ 23:19:
[...]

Zo'n IP-ban is dan een goede optie ja.


[...]

Omdat je dus gewoon dan lekker door kan brute-forcen. Zo'n sleep merk je toch niet meer als je de pagina opnieuw opvraagd. Al zou ik dus nooit de sleep ervoor uitvoeren omdat dat dus te irritant is.

Ervoor of erna maakt echt geen enkel verschil. Want een brute-force tool kan niet zien wanneer die sleep gebeurt.

[Marijn_S]

Shadowman schreef op 30 april 2004 @ 23:28:
[...]

Ervoor of erna maakt echt geen enkel verschil. Want een brute-force tool kan niet zien wanneer die sleep gebeurt.

Jawel, want uitgaande van dat je het op een snelle server probeert te brute-forcen zal je als je na bijvoorbeeld een halve seconde nog geen reactie hebt gehad (oftewel, je hackpoging is mislukt) gewoon doorgaan met de volgende brute-force poging.
Als je de sleep voor het testen van de informatie doet dan MOET de brute-force tool wel wachten altijd, voordat hij de volgende poging kan doen.

Edit: Het is ook makkelijk zelf te testen of aan te voelen of er een sleep gebeurt vóór het testen van de inloginfo. Dat merk je snel, en zeker goed merkbaar als je zelf al een account hebt in het systeem en je iemand anders' account wilt hacken.

[ Voor 17% gewijzigd door Marijn_S op 01-05-2004 00:03 ]

[Shadowman]

Cerberus schreef op 30 april 2004 @ 23:58:
[...]


Jawel, want uitgaande van dat je het op een snelle server probeert te brute-forcen zal je als je na bijvoorbeeld een halve seconde nog geen reactie hebt gehad (oftewel, je hackpoging is mislukt) gewoon doorgaan met de volgende brute-force poging.
Als je de sleep voor het testen van de informatie doet dan MOET de brute-force tool wel wachten altijd, voordat hij de volgende poging kan doen.

Edit: Het is ook makkelijk zelf te testen of aan te voelen of er een sleep gebeurt vóór het testen van de inloginfo. Dat merk je snel, en zeker goed merkbaar als je zelf al een account hebt in het systeem en je iemand anders' account wilt hacken.

Ik heb zo'n vaag vermoeden dat je met erna testen bedoelt dat je erna eerst iets naar de browser stuurt voor je de sleep uitvoert.

En daarnaast heeft een sleep ook niet zo veel zin met snelle servers en de modernere brute-forcetooltjes aangezien die zoveel mogelijk keer tegelijk proberen in te loggen en dan kijken welke thread goed gaat.

[mr_star]

En hoe regelen jullie het ingelogd blijven vanaf meerdere pc's?

Mijn situatie:

Wanneer de login pagina wordt opgevraagd, wordt er een random string gegenereerd die in de sessie wordt opgeslagen en in een javascriptje wordt geplaatst.

Na het invullen van login & pass wordt er dmv dat javascriptje een hash gegenereerd op basis van die random string en pass (md5(random_string + md5(pass))), diezelfde hash wordt serverside gemaakt op basis van de in de sessie opgeslagen random string en de geëncrypteerde pass in de database. Als de 2 hashen overeenkomen => ingelogd en de hash wordt opgeslagen in de database

Dan hash ik die hash nog eens met ip adres, browser type, taalinstellingen... en slaag deze op in de cookie. Die kan ik dan gemakkelijk elke keer controleren. En op deze manier kan men niet gewoon inloggen door de cookie te kopieren en op een andere pc te plaatsen.

Maar als een ingelogde persoon (op pc1) nu inlogd via een andere pc (pc2), veranderd de hash in de database en komt de hash op pc1 niet meer overeen => uitgelogd.

Lossen jullie dit op door een aparte tabel te maken met alle verschillende loginhashen van een bepaalde user? of hoe kan ik dit het beste aanpakken.

[Shadowman]

Ik zou dan idd een aparte tabel maken waarin je de met 2 velden (een veld voor het uid en een veld voor de sessie-hash) en dan zou ik de uid koppelen met de gebruiker die in de database staat.

Maar waarvoor je die hash ook nog is in de javascript gaat veranderen voor je het gaat vergelijken, dat zie ik even niet. (Trouwens waar was je van plan dat wachtwoord op de clientpc op te slaan. Elke keer als het over het internet moet gaan is het weer een potentieel gevaar.