[php] Challenge response

[Verwijderd]

Heb gegoogled en search al gebruikt, maar kom niet te weten wat ik wil weten.
Het gaat niet zozeer om de challenge response methode, maar over wat erna komt.

Ik ben bezig een (zo veilig mogelijk) loginscript te maken.
Dit doe ik met de Challenge response methode.
In het kort:
- random nummer wordt gegenereerd op basis van microtime()
- random nummer sla ik op in sessie
- random nummer zet ik ook in hidden field
- mbv javascript: md5password = md5 (password)
- mbv javascript: response = md5 (random nummer + md5password)

De uiteindelijke check die ik doe bij het inloggen is deze:

PHP:

if (md5($_SESSION['rndval'].$pass_uit_database) == $response) {
  $_SESSION['ingelogt'] = 1;
}

En vervolgens check ik op andere pagina's (achter de login) of mensen ingelogt zijn mbv
$_SESSION['ingelogt'] = 1;

Dit werkt inmiddels allemaal goed.
Maar nu zit ik met het volgende:
De loginprocedure lijkt me erg veilig, maar de check op de andere pagina's vind ik zo mager.

Als zo'n sessie gekaapt wordt, kan men zo inloggen, toch?

Mijn vragen:
Is dit ook mager, of is dit gewoon veilig?
Als dit te mager is, wat moet ik dan extra doen?
- Cookie?
- Session_id's?
- ip?
- een random hash?

[Altaphista]

lijkt mij best wel veilig. Of iemand moet een script hebben om binnen dezelfde seconde je pw te onderscheppen.
Grootste insecurity blijft toch dat mensen niet uitloggen, pw laten slingeren e.d.

_{btw het is ingelogd.}

[Verwijderd]

Altaphista schreef op 30 oktober 2003 @ 15:28:
...
Grootste insecurity blijft toch dat mensen niet uitloggen, pw laten slingeren e.d.
...

Zit idd ook nog te denken aan een timeout voor de sessie, maar dat komt later.

Maar ik heb dus geen session id's of iets dergelijks.

Is dus:

PHP:

if($_SESSION['ingelogt'] == 1) {
  toon pagina
}
else {
 die
}

genoeg?

[Verwijderd]

Wat is veilig?

werken met sessies heeft altijd voordelen. sessie id's heb je dan toch dus waarom niet even kijken of die nog gelijk zijn.

Als je multiple logins wil voorkomen kun je een ipcheck doen (verify met db ofzo) dan heb je wel kans dat mensen die achter een proxy hangen ten onrechte geblocked worden. Ook kan een wisselend ip worden afgegeven als mensen via een aantal proxies worden gestuurd (ik heb hier drie proxies en per aanvraag wordt ik naar een willekeurige proxie gestuurd)

hashen lijkt me overbodig na je md5's
en cookies zijn lastig, onvriendelijk en wat mij betreft nooit een optie....

[Verwijderd]

timeouts zijn ok..maar users die passwords laten slingeren blijf je houden...of hun pc niet locken als ze koffie of pizza gaan halen

[Verwijderd]

Verwijderd schreef op 30 oktober 2003 @ 15:43:
timeouts zijn ok..maar users die passwords laten slingeren blijf je houden...of hun pc niet locken als ze koffie of pizza gaan halen

Ik weet dat de gebruikers de zwakste schakel blijven, maar wil dus wel behoorlijk zeker zijn dat er van mijn kant iig geen grote beveiligingsgaten in zitten.

In principe is datgene wat beveiligd moet worden helemaal niet zo heel belangrijk, maar in de toekomst misschien wel. Ik wil het dus gewoon in 1 keer goed doen.

[Soultaker]

Prima systeem, alleen de hashcode van het wachtwoord nemen is overbodig. Direct MD5("challenge" + "password") berekenen en terugsturen is net zo goed.

[RupS]

Lijkt mij een prima opzet. Hiermee voorkom je in ieder geval dat een password plaintext over de lijn gaat (tenzij de client geen javascript ondersteunt).
Ik heb ongeveer hetzelfde gemaakt, maar er nog wel een timeout op gezet. Gebruiker mag drie maal proberen in te loggen, anders 5 minuten wachten.

Kunnen gebruikers die geen javascript ondersteunen ook inloggen?
Ik neem aan dat je nadat je het md5password form field hebt ingesteld wel het normale password form field leeg maakt? Zo detecteer ik of een gebruiker javascript ondersteunt.

Soultaker schreef op 30 oktober 2003 @ 15:55:
Prima systeem, alleen de hashcode van het wachtwoord nemen is overbodig. Direct MD5("challenge" + "password") berekenen en terugsturen is net zo goed.

Ik heb het wachtwoord md5 opgeslagen in mijn database. Dan moet je wel eerst md5 van het wachtwoord nemen...
dus:
md5(md5(password)+challenge) versturen...
of doe ik nou moeilijk?

[ Voor 30% gewijzigd door RupS op 30-10-2003 16:01 ]

[Soultaker]

RupS schreef op 30 oktober 2003 @ 15:59:
Ik heb het wachtwoord md5 opgeslagen in mijn database. Dan moet je wel eerst md5 van het wachtwoord nemen...
dus:
md5(md5(password)+challenge) versturen...
of doe ik nou moeilijk?

Nee, klopt. In dat geval heb je gewoon gelijk.

Nadeel van dat systeem is trouwens wel dat je de security van je MD5 hash kwijt bent; je hebt dan alleen nog het privacy-aspect over. Normaal gesproken ontvang je van de client een wachtwoord dat je hasht en vergelijkt met de hashcode in je database; op die manier kan het relatief weinig kwaad als de inhoud van je database bekend wordt (al wil je dat natuurlijk nog steeds voorkomen). Met jouw systeem gebruik je de hash code direct en heb je dus effectief weer een plaintext password in de database staan!

[ Voor 44% gewijzigd door Soultaker op 30-10-2003 16:04 ]

[Verwijderd]

RupS schreef op 30 oktober 2003 @ 15:59:
...
Ik heb ongeveer hetzelfde gemaakt, maar er nog wel een timeout op gezet. Gebruiker mag drie maal proberen in te loggen, anders 5 minuten wachten.

Bij mij wordt het account na x aantal keer foutief inloggen op rij geblokkeerd.

Kunnen gebruikers die geen javascript ondersteunen ook inloggen?
Ik neem aan dat je nadat je het md5password form field hebt ingesteld wel het normale password form field leeg maakt? Zo detecteer ik of een gebruiker javascript ondersteunt.

zonder javascript kunnen ze (nog) niet inloggen bij mij.
Het normale password form field maak ik idd ook leeg, wordt dus ook uberhaupt niet verstuurd (als ze javascript hebben)

Ik heb het wachtwoord md5 opgeslagen in mijn database. Dan moet je wel eerst md5 van het wachtwoord nemen...
dus:
md5(md5(password)+challenge) versturen...
of doe ik nou moeilijk?

Zo heb ik het ook ja

[Gerco]

Soultaker schreef op 30 oktober 2003 @ 16:02:
Met jouw systeem gebruik je de hash code direct en heb je dus effectief weer een plaintext password in de database staan!

De op de client gegenereerde hashcode gaat ook niet over de lijn en is dus niet te onderscheppen, ik zie zo vlug even niet hoe een cracker aan de md5() van het wachtwoord moet komen zonder een keylogger oid op de client te installeren.

[Spider.007]

Gerco schreef op 30 oktober 2003 @ 16:18:
[...]

De op de client gegenereerde hashcode gaat ook niet over de lijn en is dus niet te onderscheppen, ik zie zo vlug even niet hoe een cracker aan de md5() van het wachtwoord moet komen zonder een keylogger oid op de client te installeren.

Klopt, de redenering van Soultaker is dan ook onjuist. Het challenge response systeem werkt zo goed omdat de random code (mits onderschept) slechts gebruikt kan worden icm het wachtwoord (en ook maar 1 keer); en de MD5 over wachtwoord+random is dus ook telkens uniek. Het enige probleem zit hem hier in de sessie; die tijdens die sessie continue hetzelfde blijft.

Wellicht kan de TS eens gaan kijken naar het aanpassen van de SessieID adhv de door de client verstuurde hash Desnoods kun je hier ook telkens een random string aan toevoegen waardoor de sessieId per request veranderd. Ook kun je inderdaad kiezen voor een systeem op basis van IP adres.

[Janoz]

De redenering van Soultaker gaat niet over de client kant, maar over de server kant. Een reden om md5 hashes in de database te zetten is omdat een in te vullen wachtwoord dat over de lijn verstuurd wordt niet hetzelfde is als degene in de DB, maar wel in 1 richting af te leiden.

Door de md5 op de client te doen is hetgene dat wordt verstuurd ook datgene wat in de DB staat. Iemand die de hash weet kan zelf wel ff md5(hash+random code) doen en is dan ingelogd (iedereen kan immers gewoon een random code verkrijgen)

[FlowinG]

Maar als veilig zo belangrijk is, kan je dan niet gebruik maken van een beveiligde verbinding? (ssl dus)

[darkrain]

FlowinG schreef op 31 oktober 2003 @ 14:14:
Maar als veilig zo belangrijk is, kan je dan niet gebruik maken van een beveiligde verbinding? (ssl dus)

Waarschijnlijk kan dat wel, maar het is behoorlijk duur om zo'n certificaat te krijgen.