Veilige manier om in te loggen...
enigzinds gerelateerd aan mijn andere topic maar toch om probleem / advies wat breeder te trekken.
Veel websites hebben een eigen "member"systeem. Hierbij dient ingelogd te worden. Sommige websites maken hierbij gebruik van HTTPS maar het overgrote deel koopt geen certificaat maar werkt dus met HTTP.
Je hebt naar mijn idee 2 beveilgingshoeken waar op gelet moet worden. Van client naar server versturen. En veilig opslaan van data.
Mijn eerste bevinding is dat veel systemen plain text de username en wachtwoord over de lijn sturen. Je ziet via snifferen gewoon de username en wachtwoord in de header staan.
Dit zou op te lossen zijn door bijv. het wachtwoord in sha256, sha1 of sha512 te versturen. Aan de serverkant kan een salt aan het ingevoerde wachtwoord worden gekoppeld en worden vergeleken met het wachtwoord in de database.
Een andere mogelijkheid is, wat ik nu gebruik, challenge/response authenticatie. Server maakt challenge aan en stuurt die naar formulier. Gebruiker vult gegevens in en wachtwoord wordt samen met challenge (in hash) teruggestuurd naar de server en daar vergeleken.
In het doorzoeken van het internet kom ik opties tegen dat men een salted wachtwoorden koppeld aan het challenge/response authenticatie. Alleen heb je een gebruikersnaam nodig om de salt op te halen van de gebruiker.
Mijn vraag aan jullie, hoe regelen jullie de login waarbij je GEEN gebruik maakt van HTTPS?
- plain text over de lijn?
- hashed wachtwoord en aan serverkant salt eraan plakken?
- hashed wachtwoord + challenge en aan serverkant dit vergelijken (wachtwoord enkel in hash opgeslagen in database)
- Andere opties?
Toevoeging: of is challenge/response authetnicatie genoeg (met hashed wachtwoord in db) in vergelijking met hashed wachtwoord en aan serverkant salt+password?
Gewijzigd op 01/07/2012 15:42:21 door Wim E
HTTPS is de enige manier om de man-in-the-middle (persoon tussen client en server) encrypted informatie te laten zien.
Er is geen andere mogelijkheid.
Hoe om te gaan met informatie in database
Zorgvuldig gegevens opslaan door ALLES te encrypte.
Zelfs gebruikersnaam en e-mailadres. Je kunt hiervoor ook een eigen unieke encrypt / decrypt scriptje ontwikkelen.
Stel dat een ongewenst persoon in jouw database kijkt, zou hij/zij flink moeten balen dat alles in 'geheime taal' staat die hij of zij niet kent of bekend voorkomt.
SQL-injectie preventief tegen gaan
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Extra controle op SQL-injectie
Wanneer bovenstaande preventie niet voldoende is, kun je ook str_replace gebruiken om speciale chars om te gooien naar unicodes etc.
Mod Rewrite
Externe Request kunnen tegen gegaan worden door .htaccess , zoek naar Mod Rewrite.
Gewijzigd op 01/07/2012 21:59:05 door B Polak
B Polak op 01/07/2012 20:09:56:
Extra controle op SQL-injectie
Wanneer bovenstaande preventie niet voldoende is, kun je ook str_replace gebruiken om speciale chars om te gooien naar unicodes etc.
Wanneer bovenstaande preventie niet voldoende is, kun je ook str_replace gebruiken om speciale chars om te gooien naar unicodes etc.
Kun je niet htmlspecialchars gebruiken?
En bij opslaan gebruik maken van mysql_real_escape_string?
B Polak op 01/07/2012 20:09:56:
SQL-injectie preventief tegen gaan
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Dit is natuurlijk geen goede tip! Javascript is client side. Dat betekent dat iemand die echt kwaad wil (en laten we er even vanuit gaan dat iemand die een SQL injectie probeert iets kwaads wil doen) gaat niet alleen in jouw eigen form klooien. Die schrijft natuurlijk zelf een simpel HTML formpje om zijn trucjes te proberen. Jouw javascript code is dus direct en compleet omzeild. NOOIT vertrouwen op javascript code om zo je beveiliging te regelen. Als je al met javascript iets controleert, wat voor normale gebruikers wel handig is, dan moet je dezelfde check ALTIJD nog een keer doen in php aan de server kant!
Gewijzigd op 01/07/2012 20:36:37 door Erwin H
Zoals ik aangaf maak ik op dit moment geen gebruik van HTTPS. Wellicht in de toekomst maar nu nog niet haalbaar.
Waar het mij om gaat is of je challenge/response authenticatie kunt mixen met salted wachtwoorden.
Indien dat niet kan, is challenge/response in combi met een hashed wachtwoord voldoende of kan er in dat geval beter gekozen worden voor salted wachtwoorden (waarbij mijn voorkeur is dat in hashed wachtwoorden over de lijn stuur en aan server kant de salt eraan plak :) )
Erwin H op 01/07/2012 20:34:56:
Dit is natuurlijk geen goede tip! Javascript is client side. Dat betekent dat iemand die echt kwaad wil (en laten we er even vanuit gaan dat iemand die een SQL injectie probeert iets kwaads wil doen) gaat niet alleen in jouw eigen form klooien. Die schrijft natuurlijk zelf een simpel HTML formpje om zijn trucjes te proberen. Jouw javascript code is dus direct en compleet omzeilt. NOOIT vertrouwen op javascript code om zo je beveiliging te regelen. Als je al met javascript iets controleert, wat voor normale gebruikers wel handig is, dan moet je dezelfde check ALTIJD nog een keer doen in php aan de server kant!
B Polak op 01/07/2012 20:09:56:
SQL-injectie preventief tegen gaan
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Dit is natuurlijk geen goede tip! Javascript is client side. Dat betekent dat iemand die echt kwaad wil (en laten we er even vanuit gaan dat iemand die een SQL injectie probeert iets kwaads wil doen) gaat niet alleen in jouw eigen form klooien. Die schrijft natuurlijk zelf een simpel HTML formpje om zijn trucjes te proberen. Jouw javascript code is dus direct en compleet omzeilt. NOOIT vertrouwen op javascript code om zo je beveiliging te regelen. Als je al met javascript iets controleert, wat voor normale gebruikers wel handig is, dan moet je dezelfde check ALTIJD nog een keer doen in php aan de server kant!
Correct, daarom is het ook noodzakelijk om de extra controle te gebruiken die ik erbij heb gezet.
De post moet een Server Request zijn in het vervolgscript. Wanneer ze toch een eigen form gebruiken zal het niet veel zin hebben bij isset server request. Een normale beveiliging moet dit ook bevatten en niet alleen $_POST['submit'] check.
B Polak op 01/07/2012 20:09:56:
SQL-injectie preventief tegen gaan
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox.
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox.
'uberhaupt niet mogelijk' is dus gewoon klinklare onzin. Het is nog steeds mogelijk. Een serieuze aanvaller heeft het waarschijnlijk niet eens door dat je dit hebt.
Toevoeging op 01/07/2012 20:46:38:
B Polak op 01/07/2012 20:39:13:
De post moet een Server Request zijn in het vervolgscript. Wanneer ze toch een eigen form gebruiken zal het niet veel zin hebben bij isset server request. Een normale beveiliging moet dit ook bevatten en niet alleen $_POST['submit'] check.
Dit is ook niet waar. Als iemand een html formpje op zijn eigen server heeft staan en via dat form een POST request doet, dan krijg je ook gewoon een normale request binnen. De referer kan ook zijn uitgezet, dus ook daar kan je niet op testen.
http://www.phphulp.nl/php/tutorial/beveiliging/https-voor-inloggen-zonder-https/452/
Fokken met de man in the middle!
De rest gewoon afhandelen met mysql_real_escape_string()
Toevoeging op 01/07/2012 22:17:30:
Daarbij heeft post niets te maken met de url
Gewijzigd op 01/07/2012 22:20:36 door Write Down
Jeroen vd op 01/07/2012 22:23:36:
Ja, maar als je niet OO programmeert, of een paar simpele queries, kun je beter gewoon mysql_real_escape_string() gebruiken. Lang niet alle servers ondersteunen PDO
Helemaal oneens. Je hele applicatie hoeft niet per definitie OO zijn, PDO mag én kan je gebruiken. Verder is het op de doorsnee host tegenwoordig perfect ondersteund. Maar normaal ook: de mysql_ functies zijn 'discouraged'. Dus, zelfs voor de kleine (simpele) queries is de overstap aangeraden. Uiteraard kan je ook altijd gaan voor een andere implementatie.
B Polak op 01/07/2012 21:59:50:
@Erwin, zie ook Mod Rewrite.
Duidelijk, je hebt geen idee waar je het over hebt.
Jeroen vd op 02/07/2012 00:06:13:
Oneens met jou. Of helemaal OO, of helemaal niet. Zo zie ik het. Mysql functies zijn inderdaad niet al te goed meer, maar ik vind het net zoiets als een heel framework inladen voor een kleine actie.
Als je geen PDO wilt gebruiken (OO of niet als reden), gebruik dan in elk geval de mysqli_ functies. Dat zijn de flat php vervangers van mysql_ en hebben wel support voor prepared statements. In dat opzicht ben ik het namelijk helemaal met Write Down eens, prepared statements zijn een goed, ingebouwd, middel voor het tegengaan van SQL injectie.
1. Kun je nu challenge/response samen met een salted wachtwoord in db combineren?
2. Is het dan slimmer om challenge/response te gebruiken + hashed password of kan er dan beter gebruik worden gemaakt van hashed+salt en stuur je het wachtwoord hashed over de lijn?
buiten dat vind ik
Quote:
maar ik vind het net zoiets als een heel framework inladen voor een kleine actie.
ook echte onzin. als ik jQuery wil gebruiken omdat het makkelijker is qua syntax dan raw JS en veel sneller te begrijpen als je snel door je site heen kijkt dan gebruik ik het ongeacht of ik er nou een iets kleins of groots mee doe. het hangt volledig van de webdeveloper af die de website maakt. als jij het liever in raw JS wilt doen. prima
Toevoeging op 03/07/2012 21:17:45:
En die opmerking over het framework? Overdrijven is ook een vak. Ik bedoelde meer dat de boel niet meer klopt in mijn ogen.
Wim E op 03/07/2012 20:34:34:
1. Kun je nu challenge/response samen met een salted wachtwoord in db combineren?
2. Is het dan slimmer om challenge/response te gebruiken + hashed password of kan er dan beter gebruik worden gemaakt van hashed+salt en stuur je het wachtwoord hashed over de lijn?
2. Is het dan slimmer om challenge/response te gebruiken + hashed password of kan er dan beter gebruik worden gemaakt van hashed+salt en stuur je het wachtwoord hashed over de lijn?
Een absoluut antwoord is in dit soort situaties vaak niet te geven. Al was het maar omdat veel zaken continu veranderen. Volgens mij zijn er echter twee punten van belang:
1) als je client side al het password hashed, moet je er rekening mee houden dat hash methode en eventuele salt ook al clientside beschikbaar moet zijn. Daarmee in javascript en dus ook leesbaar voor de aanvaller. Lijkt me dus nooit een volledig veilige methode
2) wat je ook doet client side, de echte authenticatie vindt plaats server side. Dus ofwel je moet het password zo hashen/encrypten/salten dat de uitkomst precies gelijk is aan de waarde in je database, ofwel je moet ervoor zorgen dat je wat je al gedaan hebt nog terug kunt draaien. Het eerste lijkt me niet wenselijk omdat je dan je hele beveiligingsmethode feitelijk prijs geeft, het tweede is in principe niet super veilig.
B Polak op 01/07/2012 20:09:56:
SQL-injectie preventief tegen gaan
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Extra controle op SQL-injectie
Wanneer bovenstaande preventie niet voldoende is, kun je ook str_replace gebruiken om speciale chars om te gooien naar unicodes etc.
Mod Rewrite
Externe Request kunnen tegen gegaan worden door .htaccess , zoek naar Mod Rewrite.
Je kunt met Javascript er al voor zorgen dat het uberhaupt niet mogelijk is om een SQL-injectie code te typen of te plakken in een textbox. Ongewenste speciale tekens worden direct onchange uit de textbox gewist.
Extra controle op SQL-injectie
Wanneer bovenstaande preventie niet voldoende is, kun je ook str_replace gebruiken om speciale chars om te gooien naar unicodes etc.
Mod Rewrite
Externe Request kunnen tegen gegaan worden door .htaccess , zoek naar Mod Rewrite.
Jammer dat iemand wiens avatar voor "Surf Secure" staat, zulke onzinnige dingen zegt..