Een veilig login systeem
Door - -, 21 jaar geleden, 23.825x bekeken
Uitleg over hoe je een veilig login syteem kan maken
Gesponsorde koppelingen
Inhoudsopgave
Er zijn 42 reacties op 'Een veilig login systeem'
0 
-0 
-0
en wat is de SQL tabel of is dat gewoon de tabel waarin je dit script gebruikt?
0 -0
-0
De tabel is zoals je het al zegt, de tabel die je gebruikt voor dit script. Een aantal velden moet je wel zoiezo hebben:
1. een veld met de user_id
2. een veld met de gebruikersnaam
3. een veld met het wachtwoord (in dit geval gehasht met sha1)
4. een veld voor de sessie id
1. een veld met de user_id
2. een veld met de gebruikersnaam
3. een veld met het wachtwoord (in dit geval gehasht met sha1)
4. een veld voor de sessie id
0 -0
-0
Ik doe vast iets verkeerd, maar zie niet wat.
Ik kan gewoon inloggen en krijg ook een bevestiging dat het inloggen geslaagd is.
Maar wanneer ik nu login.php zo aan pas dat hij me bij een succesvolle login doorstuurt naar bijvoorbeeld index.php en daarop include ik check.php, dan wordt ik weer vrolijk door verwezen naar login.php.
Wie o wie kan me verder helpen?
Het zal vast iets lulligs zijn, maar ik zie het niet.
----
edit: als je een waarde opvraagt waarvan je denkt dat het een md5 hash is, moet je die waarde ook zo ge hashed hebben natuurlijk
Ik kan gewoon inloggen en krijg ook een bevestiging dat het inloggen geslaagd is.
Maar wanneer ik nu login.php zo aan pas dat hij me bij een succesvolle login doorstuurt naar bijvoorbeeld index.php en daarop include ik check.php, dan wordt ik weer vrolijk door verwezen naar login.php.
Wie o wie kan me verder helpen?
Het zal vast iets lulligs zijn, maar ik zie het niet.
----
edit: als je een waarde opvraagt waarvan je denkt dat het een md5 hash is, moet je die waarde ook zo ge hashed hebben natuurlijk
0 -0
-0
Hoi Bas,
De reden dat het niet werkte heb ik ondertussen ontdekt. Wat ik deed was de waarde van de sessie_id mbv de sessie zelf in de DB gooien, wat dus niet goed blijkt te werken. De code moet dus op de volgende manier worden aangepast:
en wat betreft de hash, op de een of andere manier ben ik die vergeten in de code te zetten. Maar dat heb ik ondertussen ook verbeterd.
Het is trouwens geen md5 maar sha1 wat toch een stukje veiliger is. (sha1 zit standaard bij PHP vanaf versie 4.3.0)
De reden dat het niet werkte heb ik ondertussen ontdekt. Wat ik deed was de waarde van de sessie_id mbv de sessie zelf in de DB gooien, wat dus niet goed blijkt te werken. De code moet dus op de volgende manier worden aangepast:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
$rand_key = make_rand(50); // maak een random string voor sessie session_id mbv van functie
$_SESSION['session_id'] = $rand_key;
// zet de sessie id in de db zodat we hem later kunnen controleren
mysql_query("UPDATE users SET session_id = '" . $rand_key . "' WHERE user_id = '" . $_SESSION['user_id'] . "'");
?>
$rand_key = make_rand(50); // maak een random string voor sessie session_id mbv van functie
$_SESSION['session_id'] = $rand_key;
// zet de sessie id in de db zodat we hem later kunnen controleren
mysql_query("UPDATE users SET session_id = '" . $rand_key . "' WHERE user_id = '" . $_SESSION['user_id'] . "'");
?>
en wat betreft de hash, op de een of andere manier ben ik die vergeten in de code te zetten. Maar dat heb ik ondertussen ook verbeterd.
Het is trouwens geen md5 maar sha1 wat toch een stukje veiliger is. (sha1 zit standaard bij PHP vanaf versie 4.3.0)
0 -0
-0
- Als ik javascript uit heb staan werkt het dus niet meer?
- Waarom zoveel verschillende checks? gewoon:
SELECT id FROM users WHERE username = post_username AND wachtwoord = post_pass
Krijg je 1 rij terug, dan is het goed, krijg je 0 rijen terug, dan is de inlognaam of het wachtwoord verkeerd..
- Waarom vieze addslashes() gebruiken, terwijl we de mooie MySQL functie mysql_real_escape_string() hebben...
- Waarom zoveel verschillende checks? gewoon:
SELECT id FROM users WHERE username = post_username AND wachtwoord = post_pass
Krijg je 1 rij terug, dan is het goed, krijg je 0 rijen terug, dan is de inlognaam of het wachtwoord verkeerd..
- Waarom vieze addslashes() gebruiken, terwijl we de mooie MySQL functie mysql_real_escape_string() hebben...
0 -0
-0
Code (php)
1
if ($user->pass == sha1($_POST['password']))
Dat klopt volgens mij niet...
In de DB staat de sha1 gecodeerde password, dit ga je nu vergelijken met een gepost, daarna sha1, password. Dus het password was ongecodeerd opgestuurd wat niet zo is want het wordt gecodeerd opgestuurd.
Daar ging het toch over? veiligheid?
De regel moet zijn:
Code (php)
1
if ($user->pass == $_POST['password_encrypted'])
Of zit ik nu helemaal fout...
Harry
0 -0
-0
Je lult echt shit. Ik heb de rest niet gelezen, maar t gaat echt nergens over.
0 -0
-0
Sorry??? Wat is dat nu voor opmerking als je de rest niet gelezen hebt.
Houd je commentaar dan voor je...
Houd je commentaar dan voor je...
0 -0
-0
Ik zie net dat ze wel een sha1-javascript willen gebruiken, maar ik raad het af. Gevolg is dat je nu dus letterlijk de inhoud van de database over het netwerk stuurt, iets wat je normaal met de sha1-hash voorkomt. Dit is net zo onveilig als het wachtwoord in plaats van een hash van het wachtwoord opslaan in de database.
Het maakt niet uit of er nu het wachtwoord of de hash onderschept, in beide gevallen is het een kwestie van opnieuw opsturen en je bent binnen. Maar bij de hash is het zo dat je - stel dat je al in de database komt en een blik mag werpen in de gebruikerstabel - eerst nog moet uitvogelen waarvan die hash de hash is.
Daarnaast sluit je mensen zonder Javascript buiten. Niet meer inloggen vanaf je terminal (Linx) of je mobiele telefoon, of je Windows-pda.
0 -0
-0
Quote:
Ja, en? In je script gebruik je POST om de input te verwerken, een GET gaat dus nooit werken. Daarnaast begint je validator snel genoeg te piepen wanneer de method ontbreekt.Daardoor zal er dus automatisch de GET methode gebruikt worden, oftewel: iedereen die achter je staat zal in de browser je wachtwoord/gebruikersnaam kunnen lezen!
Wanneer een script niet werkt en de html-validator begint te piepen over ontbrekende gegevens, zou er toch een lichtje moeten gaan branden dat je ergens wat fout doet. Dat heeft dus niet zo veel met veiligheid te maken.
En JS voor beveiliging, dat lijkt mij niet al te handig. Iedereen kan zijn eigen JS schrijven, daar doe jij niets aan. Gebruikers kunnen dus zelf een sleutel maken om jouw database te openen... Het is maar waar je zin in hebt.
De enige manier om veilig verkeer tussen browser en server te hebben, is via SSL. Gebruik je dat niet, dan accepteer je dus het risico dat anderen toegangsgegevens onderscheppen.
Vraagje: Hoe beveilig jij de sessies?
0 -0
-0
het javascript stukje (dat je kan downloaden) moet je opslaan in een apparte file met als naam shal.js of...?
mss domme vraag maar die bestaan niet volgens een aantal mense dus... :)
mss domme vraag maar die bestaan niet volgens een aantal mense dus... :)
0 -0
-0
ik vind het vergezocht gaan.
en de enige veilige manier voor een verbinding tussen client en server is via SSL
daarnaast iis het net zo veilig en eenvoudig om
te gebruiken en simpeler.
en de enige veilige manier voor een verbinding tussen client en server is via SSL
daarnaast iis het net zo veilig en eenvoudig om
te gebruiken en simpeler.
0 -0
-0
wat wordt de code die ik bij mySQL moet invoeren?
en moet ik het formulier gewoon een naam geven en het verwerken login.php?
en moet ik het formulier gewoon een naam geven en het verwerken login.php?
0 -0
-0
Als je met javascript een wachtwoord hashed moet je nooit vergeten om ook het sessie_id er bij te hashen.
Zodoende moet iemand ook jou sessie hebben om in te loggen.
js:
Nu heeft iemand die het wachtwoord krijgt niet direct iets aan de hash.
Zodoende moet iemand ook jou sessie hebben om in te loggen.
js:
Code (php)
1
wachtwoord_gehashed = SHA1([wachtwoord][sessie_id]);
Nu heeft iemand die het wachtwoord krijgt niet direct iets aan de hash.
0 -0
-0
Dit zou het moeten doen:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
CREATE TABLE `users` (
`user_id` int(11) NOT NULL auto_increment,
`username` varchar(50) NOT NULL default '',
`password` varchar(50) NOT NULL default '',
`session_id` varchar(50) NOT NULL default '',
PRIMARY KEY (`user_id`)
) ENGINE=MyISAM ;
`user_id` int(11) NOT NULL auto_increment,
`username` varchar(50) NOT NULL default '',
`password` varchar(50) NOT NULL default '',
`session_id` varchar(50) NOT NULL default '',
PRIMARY KEY (`user_id`)
) ENGINE=MyISAM ;
0 -0
-0
@ roel, volgens mij login.php
@ ts... Mijn eerste opmerking is je taalgebruik. Maak alsjeblieft gebruik van volledige woorden en ABN.. t s nie zo moeilijk om da te doe.. Vind je dat niet erg rottig te lezen? Ik wel iig.. Het is hier geen MSN chat, je legt mensen iets uit. Doe het dan wel op een goede manier e.d.
Over de inhoud van je tutorial kan ik alleen zeggen dat ik niet snap waarom je er javascript in gebruikt. Als je namelijk JavaScript uitschakeld is het dus niet meer mogelijk om hier gebruik van te maken. En verder heb ik niet gezien dat je ook maar iets van een $_POST beveiligd. Ik kan je inlogformulier op deze manier zo hacken ;-)
@ ts... Mijn eerste opmerking is je taalgebruik. Maak alsjeblieft gebruik van volledige woorden en ABN.. t s nie zo moeilijk om da te doe.. Vind je dat niet erg rottig te lezen? Ik wel iig.. Het is hier geen MSN chat, je legt mensen iets uit. Doe het dan wel op een goede manier e.d.
Over de inhoud van je tutorial kan ik alleen zeggen dat ik niet snap waarom je er javascript in gebruikt. Als je namelijk JavaScript uitschakeld is het dus niet meer mogelijk om hier gebruik van te maken. En verder heb ik niet gezien dat je ook maar iets van een $_POST beveiligd. Ik kan je inlogformulier op deze manier zo hacken ;-)
0 -0
-0
Als ik mijn wachtwoord en gebruikersnaam invul, dan krijg ik een witte pagina.
Site: linkje
Gegevens: http://www.design-xtr.nl/media/database.png
Zou iemand kunnen probern?
Site: linkje
Gegevens: http://www.design-xtr.nl/media/database.png
Zou iemand kunnen probern?
0 -0
-0
$_SERVER['REMOTE_ADRESS'];
dat klopt niet volgens mij..
moet dat niet
$_SERVER['REMOTE_ADDRESS'];
of
$_SERVER['REMOTE_ADDR'];
zijn?
dat klopt niet volgens mij..
moet dat niet
$_SERVER['REMOTE_ADDRESS'];
of
$_SERVER['REMOTE_ADDR'];
zijn?
0 -0
-0
Allereerst bedankt voor deze uitleg, ik heb er veel aan gehad en heb het nu ook in gebruik. Ik heb nog 1 vraag over het uitloggen, is onderstaand scriptje voldoende of kan ik dit beter anders doen?
0 -0
-0
Hallo,
Een tutorial als dit is precies wat ik zocht.
het enige wat ik mis: is er een zip of tarretje waarin alles staat opdat ik niet de hele thread af hoeft te lopen en ieders verbeterregeltjes moet toevoegen?
Het zou mooi zijn als het eindresultaat vah deze thread is: een goed doordacht en veilig, direct toe te passen login systeem waarbij de verbeteringen die door diverse formumleden worden aangeleverd na toetsing wordt opgenomen in de broncode.
Verders: blij dat het eens goed wordt besproken! Dank allen!
Een tutorial als dit is precies wat ik zocht.
het enige wat ik mis: is er een zip of tarretje waarin alles staat opdat ik niet de hele thread af hoeft te lopen en ieders verbeterregeltjes moet toevoegen?
Het zou mooi zijn als het eindresultaat vah deze thread is: een goed doordacht en veilig, direct toe te passen login systeem waarbij de verbeteringen die door diverse formumleden worden aangeleverd na toetsing wordt opgenomen in de broncode.
Verders: blij dat het eens goed wordt besproken! Dank allen!
0 -0
-0
Ik ga dit script gebruiken voor mijn eigen site.
Ik zelf had reeds iets gebouwd, maar bij lange na niet zo degelijk als dit.
Ik had echter ook een registratie traject vooraf.
Dit was zo ongeveer hetzelfde als ik bij deze site moest doen: credentials opgeven, vervolgens wordt er een email verstuurd met linkje, en na klikken daarop wordt het account geactiveerd.
Mag ik bij deze vragen of julie ook hier iets over willen zeggen?
Al ik kijk welke beveiligings issues er allemaal bij komen kijken, vrees ik dat mijn gefr?bel zo lek is als een mandje.
Ik zelf had reeds iets gebouwd, maar bij lange na niet zo degelijk als dit.
Ik had echter ook een registratie traject vooraf.
Dit was zo ongeveer hetzelfde als ik bij deze site moest doen: credentials opgeven, vervolgens wordt er een email verstuurd met linkje, en na klikken daarop wordt het account geactiveerd.
Mag ik bij deze vragen of julie ook hier iets over willen zeggen?
Al ik kijk welke beveiligings issues er allemaal bij komen kijken, vrees ik dat mijn gefr?bel zo lek is als een mandje.
0 -0
-0
ik heb eens verder zitten speuren (er is altijd wel een alternatief); maar waarom zelf middels rand() een session id aanmaken? Deze is impliciet aanwezig middels session_id();
Dus bij het inloggen kan je net zo goed zeggen:
mysql_query("UPDATE users SET session_id = '" . session_id() . "' WHERE username = '" . $_SESSION['username'] . "'");
Mag ik weten waarom hier niet voor gekozen is?
Dus bij het inloggen kan je net zo goed zeggen:
mysql_query("UPDATE users SET session_id = '" . session_id() . "' WHERE username = '" . $_SESSION['username'] . "'");
Mag ik weten waarom hier niet voor gekozen is?
0 -0
-0
Het hashen van de wachtwoord heeft weinig nut nu, als iemand zo inlogd en die package komt bij een hacker aan, kan die hacker deze package toch nog een keer versturen toch?
En dan niet zeggen, nee want dan maakt hij een hash van een hash. die hash kun je uitzetten, je pakt gewoon een copy van de website en zorgt dat de JS gedeelte niet wordt uitgevoerd, zet de opgevangen hash in de wachtwoord vak en versturen zodat je binnen bent. hidden fields helpen hier ook niet, aangezien we ook de gehele formulier kunnen aanpassen (namen van velden).
Misschien een idee om een dynamic salt erbij te gooien?
En dan niet zeggen, nee want dan maakt hij een hash van een hash. die hash kun je uitzetten, je pakt gewoon een copy van de website en zorgt dat de JS gedeelte niet wordt uitgevoerd, zet de opgevangen hash in de wachtwoord vak en versturen zodat je binnen bent. hidden fields helpen hier ook niet, aangezien we ook de gehele formulier kunnen aanpassen (namen van velden).
Misschien een idee om een dynamic salt erbij te gooien?
0 -0
-0
is er ook een andere optie ipv javascript om het wachtwoord te hashen voordat het verstuurt wordt?? en is sha512 niet veiliger?
@riemer, wat is een dynamic salt?
@riemer, wat is een dynamic salt?
0 -0
-0
Quote:
is er ook een andere optie ipv javascript om het wachtwoord te hashe voordat het verstuurt wordt?? en is sha512 niet veiliger?
Zoek maar eens op Google naar: SSL.
0 -0
-0
Hallo,
Ik wil het script gaan gebruiken en krijg de volgende foutmelding:
Ongeldig wachtwoord/gebruikersnaam! PHP Notice: Undefined property: stdClass::$pass in E:\Domains\comtexgroep.nl\wwwroot\login.php on line 30
het is in deze regel:
if ($user->pass == sha1($_POST['password'])) { // als het wachtwoord klopt
weet iemand hier een oplossing voor?
Dank
Ik wil het script gaan gebruiken en krijg de volgende foutmelding:
Ongeldig wachtwoord/gebruikersnaam! PHP Notice: Undefined property: stdClass::$pass in E:\Domains\comtexgroep.nl\wwwroot\login.php on line 30
het is in deze regel:
if ($user->pass == sha1($_POST['password'])) { // als het wachtwoord klopt
weet iemand hier een oplossing voor?
Dank
0 -0
-0
Hoe kan ik een uitlog functie maken??
Is het sessie ID verwijderen genoeg om het te doen?
Is het sessie ID verwijderen genoeg om het te doen?
0 -0
-0
Wat al eerder genoemd wordt maakt het hashen van het wachtwoord (maakt niet uit welke) voor de submit niet het verschil. Ook voor SHA1 zijn er rainbow tables. Iemand die zou sniffen zou dan nog steeds je wachtwoord kunnen decrypten.
Je zou dus in Javascript zelf een encryptie moeten maken die je ook in PHP kan toepassen voor de controle na de post.
Daarnaast heb je ook niet zo heel veel aan een eigen encrypt/decrypt script, alles wat te decrypten is kan nooit lang veilig zijn.
Je zou een salt kunnen gebruiken voor het wachtwoord, maar die moet je dan zien te hashen met een wachtwoord op een andere manier dan met Javascript en voor de post, dat zou ik zo niet weten.
De enige methode waar je dat mee zou kunnen is met SSL.
Ik vraag me ook af waarom andere dit zo 'klakkeloos' overnemen zonder zelf een beetje na te denken in wat er gebeurt, hoe het gebeurt en wat andere hier vanaf buiten af mee kunnen.
Je zou dus in Javascript zelf een encryptie moeten maken die je ook in PHP kan toepassen voor de controle na de post.
Daarnaast heb je ook niet zo heel veel aan een eigen encrypt/decrypt script, alles wat te decrypten is kan nooit lang veilig zijn.
Je zou een salt kunnen gebruiken voor het wachtwoord, maar die moet je dan zien te hashen met een wachtwoord op een andere manier dan met Javascript en voor de post, dat zou ik zo niet weten.
De enige methode waar je dat mee zou kunnen is met SSL.
Ik vraag me ook af waarom andere dit zo 'klakkeloos' overnemen zonder zelf een beetje na te denken in wat er gebeurt, hoe het gebeurt en wat andere hier vanaf buiten af mee kunnen.
0 -0
-0
Echt nuttig, reageren op een script wat al drie jaar oud is en twee jaar terug voor het laatst een reactie heeft gehad.
Quote:
Ik vraag me ook af waarom andere dit zo 'klakkeloos' overnemen zonder zelf een beetje na te denken in wat er gebeurt,
Ik vraag me af waarom mensen nooit eerst goed lezen voordat ze posten..
0 -0
-0
Ondanks dat deze tut inmiddels 3 jaar oud is, toch nuttig! Wel nog even een paar vragen:
1 - Het hashen van het password is dus niet nuttig, een ssl verbinding is onontbeerlijk? Ik heb er voor gekozen om geen gebruik te maken van het JS, verzend nu ongecodeerd en doe een MD5 bij het verwerken / vergelijken met de waarde in de DB. Is dat verstandig? Kan dat ook anders? (Ik heb geen SSL tot mijn beschikking helaas!)
2- Is het verstandig om het volgende script toe te voegen:
1 - Het hashen van het password is dus niet nuttig, een ssl verbinding is onontbeerlijk? Ik heb er voor gekozen om geen gebruik te maken van het JS, verzend nu ongecodeerd en doe een MD5 bij het verwerken / vergelijken met de waarde in de DB. Is dat verstandig? Kan dat ook anders? (Ik heb geen SSL tot mijn beschikking helaas!)
2- Is het verstandig om het volgende script toe te voegen:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
// Met onderstaande PHP header code voorkom je dat browsers een webserver response cachen. Bijvoorbeeld bij het testen van dynamische of AJAX gegenereerde inhoud zijn dit soort PHP headers handig tot onmisbaar.
header('Expires: Mon, 26 Jul 1990 05:00:00 GMT'); // Datum in het verleden!
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Pragma: no-cache');
?>
// Met onderstaande PHP header code voorkom je dat browsers een webserver response cachen. Bijvoorbeeld bij het testen van dynamische of AJAX gegenereerde inhoud zijn dit soort PHP headers handig tot onmisbaar.
header('Expires: Mon, 26 Jul 1990 05:00:00 GMT'); // Datum in het verleden!
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Pragma: no-cache');
?>
0 -0
-0
Victor,
'Misschien' klinkt nogal vaag, eigenlijk eerder als een aanname... die had ik zelf ook kunnen doen. Kan je hierin iets concreter zijn? Enige inhoudelijke reactie op mijn vragen?
'Misschien' klinkt nogal vaag, eigenlijk eerder als een aanname... die had ik zelf ook kunnen doen. Kan je hierin iets concreter zijn? Enige inhoudelijke reactie op mijn vragen?
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu