https voor inloggen zonder https
Door Rudie dirkx, 22 jaar geleden, 13.526x bekeken
Je wil data veilig oversturen, maar zonder https? Makkelijk!
Gesponsorde koppelingen
Inhoudsopgave
Er zijn 36 reacties op 'Https voor inloggen zonder https'
0 
-0 
-0
Ik ben niet zo geweldig met encryption, ook omdat ik nog een beginner ben, maar leuk uitgelegd, en voor iedereen interessant denk ik!
(ik weet zowieso niet eens hoe je een https protocol gebruikt ;P)
Groet,
Barry
(lol: 'op enter ramt')
(ik weet zowieso niet eens hoe je een https protocol gebruikt ;P)
Groet,
Barry
(lol: 'op enter ramt')
0 -0
-0
Hoe je https gebruikt is niet moeilijk. Gewoon je html paginas maken in https omgeving :) Hoe het precies werkt weet ik ook niet.
Heb iig nooit zin gehad om https paginas te maken (moet in andere dirs he) enzo...
Denk ook niet dat veel mensen met spelletjes ofzo last hebben van man-in-the-middle attacks, maar weten wat het is en dat je er iets aan kan doen is al iets...
Heb iig nooit zin gehad om https paginas te maken (moet in andere dirs he) enzo...
Denk ook niet dat veel mensen met spelletjes ofzo last hebben van man-in-the-middle attacks, maar weten wat het is en dat je er iets aan kan doen is al iets...
0 -0
-0
Ik ben nogal lui atm, dus lees maar half, als ik onzin type, zeg het dan maar :P
Man-in-the-middle zou de salt wel kunnen weten als hij zijn criminele zaakjes op orde heeft en niet alleen de uitgaande data snifft?
Quote:
Als een man-in-the-middle DIE string als passphrase zou stelen, kan ie m nog niet gebruiken! Waarom niet? Omdat ie niet weet welke salt erbij hoort... Omdat de salt die erbij hoort op de server staat en niet meegestuurd wordt of als cookie is opgeslagen.
Quote:
var salt = '< ? php echo $_SESSION['js_enc_login']['salt']; ? >';
Man-in-the-middle zou de salt wel kunnen weten als hij zijn criminele zaakjes op orde heeft en niet alleen de uitgaande data snifft?
0 -0
-0
Https is denk ik toch gewoon wat simpeler.
Maar als je op deze manier gaat beveiligingen is het misschien sneller/beter/veiliger om met KeyGens (die kleine dingen die sommige aan de sleutelhanger hebben hangen), TAN lijsten of ander sinds SMS gaan werken.
Daarnaast is er gewoon ??n regel log alleen in via vertrouwde netwerken.
Maar als je op deze manier gaat beveiligingen is het misschien sneller/beter/veiliger om met KeyGens (die kleine dingen die sommige aan de sleutelhanger hebben hangen), TAN lijsten of ander sinds SMS gaan werken.
Daarnaast is er gewoon ??n regel log alleen in via vertrouwde netwerken.
0 -0
-0
Met dit script zit je volgens mij nog steeds met een probleem. De hacker kan mensen zonder JavaScript (en dat zijn er nog best veel) nog steeds hun wachtwoord ontfutselen.
En wat nog vervelender is: Mensen zonder JavaScript kunnen zoiezo helemaal niet inloggen. Om de reden dat hun username+wachtwoord niet client-side wordt geencrypt. En dus komt het verkeerd aan bij de server:(
Of zie ik dit nu helemaal verkeerd?
En wat nog vervelender is: Mensen zonder JavaScript kunnen zoiezo helemaal niet inloggen. Om de reden dat hun username+wachtwoord niet client-side wordt geencrypt. En dus komt het verkeerd aan bij de server:(
Of zie ik dit nu helemaal verkeerd?
0 -0
-0
Goed, heb dit ff doorgelezen en denk dat je toch een paar dingen mist:
Het is compleet nutteloos zonder Javascript aan toch? Werkt dus niet. Oplossing: Ajax!
Ik maak voor mijn weblog systeem gebruik van een auto_save systeem. Dat stuurt je data naar een PHP script. Voor mijn login systeem op het blog had ik de volgende techniek ontwikkelt:
1. Geheim 1 (hidden)
2. Geheim 2. (hidden)
3. Username (input)
4. Password (password
Vervolgens ga ik, alles samen voegen. Ongeveer deze code:
SHA1(MD5(geheim1,username,password,geheim2));
Dit alles gebeurd uiteraard in PHP zodat onze man ook geen idee heeft wat er gebeurd. Het enige wat hij kan achterhalen is dat ik link naar het script: login_secure.php die als je hem direct aanroept echo?t: Flikker op Hacker. En vervolgens een IP aan de banlijst toevoegd.
Bij de verwerking heb ik in de DB 3 velden voor de inlog staan:
Username
Password
String
de array van de verstuurde data ziet er zo uit:
Reffefer
Username
Password
String
Vervolgens komt het inlog proces, simpel.
Mijn sleutelwoorden zijn dus: Ajax in combo met PHP.
// EDIT:
Of dit nu echt 100% veilig is weet ik niet, maar het leek me redelijk veilig. Aanmerkingen zijn altijd welkom hoor :)
// EDIT 2:
De geheim velden zijn waardes in PHP overigens, hij weet ze NIET te achterhalen.
Het is compleet nutteloos zonder Javascript aan toch? Werkt dus niet. Oplossing: Ajax!
Ik maak voor mijn weblog systeem gebruik van een auto_save systeem. Dat stuurt je data naar een PHP script. Voor mijn login systeem op het blog had ik de volgende techniek ontwikkelt:
1. Geheim 1 (hidden)
2. Geheim 2. (hidden)
3. Username (input)
4. Password (password
Vervolgens ga ik, alles samen voegen. Ongeveer deze code:
SHA1(MD5(geheim1,username,password,geheim2));
Dit alles gebeurd uiteraard in PHP zodat onze man ook geen idee heeft wat er gebeurd. Het enige wat hij kan achterhalen is dat ik link naar het script: login_secure.php die als je hem direct aanroept echo?t: Flikker op Hacker. En vervolgens een IP aan de banlijst toevoegd.
Bij de verwerking heb ik in de DB 3 velden voor de inlog staan:
Username
Password
String
de array van de verstuurde data ziet er zo uit:
Reffefer
Username
Password
String
Vervolgens komt het inlog proces, simpel.
Mijn sleutelwoorden zijn dus: Ajax in combo met PHP.
// EDIT:
Of dit nu echt 100% veilig is weet ik niet, maar het leek me redelijk veilig. Aanmerkingen zijn altijd welkom hoor :)
// EDIT 2:
De geheim velden zijn waardes in PHP overigens, hij weet ze NIET te achterhalen.
0 -0
-0
Euhm: weet je eigenlijk wel wat Ajax is, naast een wasmiddel, een voetbalclub en een Griekse held? Jep, het is een methode die je kan toepassen met behulp van Javascript. Zonder Javascript helemaal geen Ajax.
Maar even dit bovenstaande (nog niet zo goed doordachte?) idee aan de kant geschoven, mijn grootste bezwaar is dat dit niet werkt zonder Javascript en een enorme lading aan externe bestanden. Prototype is zwaar, maar die md5 en sha1 implementatie in PHP zijn ook niet moeders mooiste qua bestandsgrootte. Als je echt gaat voor beveiliging is dat geen probleem. (al kan je ook gewoon 1 hash gebruiken, scheelt snelheid en een extern bestand inladen, dubbele hash met verschillende methoden heeft hier namelijk geen enkele zin)
Maar dan, dan is de gebruiker geheel beveiligd ingelogd, maar de gegevens die hij alleen via de ingelogde pagina's kan bekijken gaan nog wel over een onbeveiligde verbinding en zijn dus prima leesbaar voor the man in the middle.
Maar even dit bovenstaande (nog niet zo goed doordachte?) idee aan de kant geschoven, mijn grootste bezwaar is dat dit niet werkt zonder Javascript en een enorme lading aan externe bestanden. Prototype is zwaar, maar die md5 en sha1 implementatie in PHP zijn ook niet moeders mooiste qua bestandsgrootte. Als je echt gaat voor beveiliging is dat geen probleem. (al kan je ook gewoon 1 hash gebruiken, scheelt snelheid en een extern bestand inladen, dubbele hash met verschillende methoden heeft hier namelijk geen enkele zin)
Maar dan, dan is de gebruiker geheel beveiligd ingelogd, maar de gegevens die hij alleen via de ingelogde pagina's kan bekijken gaan nog wel over een onbeveiligde verbinding en zijn dus prima leesbaar voor the man in the middle.
0 -0
-0
Ik zou gewoon een SHA-1 implementatie gebruiken van Javascript.
Een cli?nt heeft (bij mij) altijd een session_id (SHA1 string) deze veranderd als je de browser sluit (of als optie zelfs per pagina/request).
Voor het inloggen met JS encryptie gebruik je dan een tweede formulier (zonder plain wachtwoord). In dit formulier zit de gebruikersnaam (die uniek is) en een hash die er ongeveer zo uit ziet:
sha1(sha1(wachtwoord) + lowercase(gebruikersnaam) + session_id)
Een "man in the middle" kan deze gegevens wel opvangen en gebruiken alleen wordt het voor hem/haar wat lastig omdat de session_id niet bekend is.
Ofwel hij/zij heeft niet het juiste session_id als cookie. Dus de "man in the middle" kan niet inloggen met deze gegevens.
Als je de session_id (van client/gebruiker) nu ook nog aan IP-adres en/of browser (automatisch?) vergrendeld dan wordt het nog wat lastiger voor de "man in the middle" om die formulier gegevens succesvol te gebruiken.
edit:
Ideetje voor niet JS gebruikers:
Als een cli?nt nu geen JS heeft zou je ook nog een versleutelde versie van zijn/haar session_id mee kunnen sturen. Uiteraard versleuteld door PHP en in een hidden field gezet ofzo.
Weet de "man in the middle" de manier van versleuteling niet dan kan er ook niet worden ingelogd met gebruikersnaam/wachtwoord omdat er (hopelijk) geen geldig versleuteld session_id wordt opgegeven in het hidden field.
Een cli?nt heeft (bij mij) altijd een session_id (SHA1 string) deze veranderd als je de browser sluit (of als optie zelfs per pagina/request).
Voor het inloggen met JS encryptie gebruik je dan een tweede formulier (zonder plain wachtwoord). In dit formulier zit de gebruikersnaam (die uniek is) en een hash die er ongeveer zo uit ziet:
sha1(sha1(wachtwoord) + lowercase(gebruikersnaam) + session_id)
Een "man in the middle" kan deze gegevens wel opvangen en gebruiken alleen wordt het voor hem/haar wat lastig omdat de session_id niet bekend is.
Ofwel hij/zij heeft niet het juiste session_id als cookie. Dus de "man in the middle" kan niet inloggen met deze gegevens.
Als je de session_id (van client/gebruiker) nu ook nog aan IP-adres en/of browser (automatisch?) vergrendeld dan wordt het nog wat lastiger voor de "man in the middle" om die formulier gegevens succesvol te gebruiken.
edit:
Ideetje voor niet JS gebruikers:
Als een cli?nt nu geen JS heeft zou je ook nog een versleutelde versie van zijn/haar session_id mee kunnen sturen. Uiteraard versleuteld door PHP en in een hidden field gezet ofzo.
Weet de "man in the middle" de manier van versleuteling niet dan kan er ook niet worden ingelogd met gebruikersnaam/wachtwoord omdat er (hopelijk) geen geldig versleuteld session_id wordt opgegeven in het hidden field.
0 -0
-0
Voor een goed beveiligde website heb je gewoon ssl nodig. Zodra iemand jouw dataverkeer kan afluisteren, kun je er op wachten dat de boel wordt gekraakt en hackers kunnen inloggen met gegevens van jouw gebruikers. Met dit soort scriptjes kun je het misschien een paar dagen/weken/maanden uitstellen, maar vroeg of laat ben je aan de beurt.
In vergelijking met ssl zijn dit toepassingen gewoon schijnveiligheid. Nee dankje, daar heb ik niet zo'n trek in.
In vergelijking met ssl zijn dit toepassingen gewoon schijnveiligheid. Nee dankje, daar heb ik niet zo'n trek in.
0 -0
-0
@Frank:
Denk dat SSL wel het makkelijkst is idd. Alleen heb je daar dan ook een certificaat voor nodig?
Denk dat SSL wel het makkelijkst is idd. Alleen heb je daar dan ook een certificaat voor nodig?
0 -0
-0
Het zal ongetwijfeld allemaal te kraken zijn. als je echter geen zin hebt in een certificaat vind ik dit een leuke oplossing. En ik vind de tutorial prachtig (qua stijl) geschreven
Klaasjan
Klaasjan
0 -0
-0
@Martijn: M?t certificaat zal de browser van de bezoeker niet gaan piepen dat er geen certificaat wordt gebruikt. Deze melding kan overigens eenvoudig (voorgoed) worden weggeklikt, maar gebruikersvriendelijk en vertrouwenswekkend is het natuurlijk niet.
Wanneer je een certificaat koopt, heb je tevens een soort van verzekering. Word de boel toch gekraakt en blijkt het ssl-certificaat de boosdoener te zijn, dan zal de uitgever van het certificaat jou een schadevergoeding betalen. Dit kan, afhankelijk van het door jou gekochte certificaat, oplopen tot vele miljoenen euro's.
Je hebt al goede certificaten vanaf zo'n 70 euro. Voor dat geld ga ik echt niet lopen kloten met ??n of ander onveilig stukje Javascript wat mij gegarandeerd veel meer geld (tijd!) gaat kosten, geen enkele garantie geeft en gewoon bewezen onveilig is.
Wanneer je een certificaat koopt, heb je tevens een soort van verzekering. Word de boel toch gekraakt en blijkt het ssl-certificaat de boosdoener te zijn, dan zal de uitgever van het certificaat jou een schadevergoeding betalen. Dit kan, afhankelijk van het door jou gekochte certificaat, oplopen tot vele miljoenen euro's.
Je hebt al goede certificaten vanaf zo'n 70 euro. Voor dat geld ga ik echt niet lopen kloten met ??n of ander onveilig stukje Javascript wat mij gegarandeerd veel meer geld (tijd!) gaat kosten, geen enkele garantie geeft en gewoon bewezen onveilig is.
0 -0
-0
Quote:
Om dit enigszins te relativeren: het ligt er natuurlijk ook wel aan wat voor website je hebt. Een bank of verzekeringsbedrijf heeft meer kans (op pogingen) om gekraakt te worden en dient zich daar dan ook naar aan te passen. Een simpele webgame/criminals of iets dergelijks zal met een goed inlogsysteem geen SSL nodig hebben; wanneer het kraken te ingewikkeld worden haken de meesten al af, en voor de rest is het naar alle waarschijnlijkheid weinig interessant om inloggegevens te bemachtigen. Met dit soort scriptjes kun je het misschien een paar dagen/weken/maanden uitstellen, maar vroeg of laat ben je aan de beurt.
Desalniettemin: mocht je het geld ervoor over hebben en prijs stellen op beveiliging of het vertrouwen wat bezoekers van je website in jou moeten stellen, neem dan een certificaat en gebruik SSL.
0 -0
-0
goede oplossing als net zo als bij mij je provieder geen https ondersteunt
0 -0
-0
Frank
Vroeg of laat ben je idd aan de beurt. Zoals Kasper al zei, als je website maar gewild genoeg is, kom je wel aan de beurt. Dus eigenlijk kan je er nooit iets aan doen. Laten we heel het fenomeen inloggen dan maar gewoon afschaffen!!
Wat je zegt is echter niet waar:
Zoals je in mijn voorbeeld ziet kan je 500 keer inloggen met precies dezelfde userinfo (de gebruiker weet maar 2 dingen: plain username, plain password) en er zal 500 keer iets anders over de lijn gaan. Het enige dat steeds hetzelde is, is de gebruikersnaam (die plain over de lijn gaat) en zelfs die is nog wel weg te werken. The man in the middle, die verkeer naar de server afluistert ziet 500 keer iets anders langskomen. ALLES was langskomt kan maar 1 keer gebruikt worden. Het is steeds anders dus kan er niets herhaald worden. Je kan 100duizend keer afluisteren en nog steeds geen patroon :) Dus wat je zegt is niet helemaal waar...
Dit script is duizenden keren veiliger dan userdata plain of steeds hetzelfde over de lijn en het behoudt 100% gebruikersvriendelijkheid!
Klaasjan Boven
Dankje :) Maar dat was niet helemaal het punt ;)
Quote:
Voor een goed beveiligde website heb je gewoon ssl nodig. Zodra iemand jouw dataverkeer kan afluisteren, kun je er op wachten dat de boel wordt gekraakt en hackers kunnen inloggen met gegevens van jouw gebruikers. Met dit soort scriptjes kun je het misschien een paar dagen/weken/maanden uitstellen, maar vroeg of laat ben je aan de beurt.
Vroeg of laat ben je idd aan de beurt. Zoals Kasper al zei, als je website maar gewild genoeg is, kom je wel aan de beurt. Dus eigenlijk kan je er nooit iets aan doen. Laten we heel het fenomeen inloggen dan maar gewoon afschaffen!!
Wat je zegt is echter niet waar:
Quote:
Zodra iemand jouw dataverkeer kan afluisteren, kun je er op wachten dat de boel wordt gekraakt en hackers kunnen inloggen met gegevens van jouw gebruikers.
Zoals je in mijn voorbeeld ziet kan je 500 keer inloggen met precies dezelfde userinfo (de gebruiker weet maar 2 dingen: plain username, plain password) en er zal 500 keer iets anders over de lijn gaan. Het enige dat steeds hetzelde is, is de gebruikersnaam (die plain over de lijn gaat) en zelfs die is nog wel weg te werken. The man in the middle, die verkeer naar de server afluistert ziet 500 keer iets anders langskomen. ALLES was langskomt kan maar 1 keer gebruikt worden. Het is steeds anders dus kan er niets herhaald worden. Je kan 100duizend keer afluisteren en nog steeds geen patroon :) Dus wat je zegt is niet helemaal waar...
Dit script is duizenden keren veiliger dan userdata plain of steeds hetzelfde over de lijn en het behoudt 100% gebruikersvriendelijkheid!
Klaasjan Boven
Quote:
En ik vind de tutorial prachtig (qua stijl) geschreven
Dankje :) Maar dat was niet helemaal het punt ;)
0 -0
-0
Heej,
Ik vind het een goede tutorial maar.
Maar als ik mijn wachtwoord op wil slaan(aanmelden) met:
md5(sha1(concat(`username`,':',PLAIN_PWD)))
krijg ik:
Fatal error: Call to undefined function concat() in C:\Program Files\xampp\htdocs\vrienden\aanmelden.php on line 93
Maar ik vond deze tutorial heel erg leuk om te lezen.
Je hebt veel humor!
Groetjes Peter
Ik vind het een goede tutorial maar.
Maar als ik mijn wachtwoord op wil slaan(aanmelden) met:
md5(sha1(concat(`username`,':',PLAIN_PWD)))
krijg ik:
Fatal error: Call to undefined function concat() in C:\Program Files\xampp\htdocs\vrienden\aanmelden.php on line 93
Maar ik vond deze tutorial heel erg leuk om te lezen.
Je hebt veel humor!
Groetjes Peter
0 -0
-0
CONCAT is een SQL functie, geen PHP functie. Concatineren in PHP gaat gewoon met een punt, dus zonder functie.
Dus sla je wachtwoord zo op:
Zoiets?
Dus sla je wachtwoord zo op:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
// Dit is dus registratie?
// Dan is er geregistreerd met 'username' en 'password'
$szSqlPwd = md5(sha1($_POST['username'].':'.$_POST['password']));
mysql_query("insert into users (username,password) values ('".$_POST['username']."', '".$szSqlPwd."');");
?>
// Dit is dus registratie?
// Dan is er geregistreerd met 'username' en 'password'
$szSqlPwd = md5(sha1($_POST['username'].':'.$_POST['password']));
mysql_query("insert into users (username,password) values ('".$_POST['username']."', '".$szSqlPwd."');");
?>
Zoiets?
0 -0
-0
Hey,
ik snap er nog niet heel erg veel van denk ik.
Daarom heb ik een vraag:
Hoe kan de server het password toch controleren zonder dat het password word opgestuurd? Je blijft toch houden dat de 'hacker' kan terug coderen?
En wat ik me ook afvraag hij echt https werkt. https stuurt gegevens gecodeerd op en de browser decodeerd ze dan weer? (zover als ik kan begrijpen :p)
Maar waarom kan iemand die de gecodeerde dingen heeft onderschept ze niet coderen? Die heeft toch ook een browser?
(Ik weet wel dat het wel werkt :o maar ik snap alleen niet waarom het werkt ...)
ik snap er nog niet heel erg veel van denk ik.
Daarom heb ik een vraag:
Hoe kan de server het password toch controleren zonder dat het password word opgestuurd? Je blijft toch houden dat de 'hacker' kan terug coderen?
En wat ik me ook afvraag hij echt https werkt. https stuurt gegevens gecodeerd op en de browser decodeerd ze dan weer? (zover als ik kan begrijpen :p)
Maar waarom kan iemand die de gecodeerde dingen heeft onderschept ze niet coderen? Die heeft toch ook een browser?
(Ik weet wel dat het wel werkt :o maar ik snap alleen niet waarom het werkt ...)
0 -0
-0
Het is geen HTTPS, dat is het hele punt :) Het kan ook secure zonder HTTPS. HTTPS is wel een stuk geavanceerder en validate echt twee kanten van de lijn, maar daar gaat het hier niet om.
Dacht eigenlijk dat het verhaal redelijk duidelijk was, maar niet genoeg misschien.
Ik wil tegen gaan dat er steeds hetzelfde username-wachtwoord wordt opgestuurd.
Waarom?
Omdat het steeds hetzelfde is.
Waarom is dat slecht?
Omdat Eve (die tussen client en server aan t luisteren is) zo login data kan onderscheppen en op een later tijdstip (WANNEER ze maar wil!!) in kan loggen met gejatte logininfo.
Het keyword in mijn verhaal is "hetzelfde", niet "encrypted" of "hash". Het heeft namelijk geen zin om een gehasht username password combi (of alleen gehasht password) op te sturen. Dat is namelijk ook elke keer hetzelfde en dus ook nog geldig volgende keer (voor Eve om in te loggen).
Met keyword "hetzelfde" is de oplossing dus: "anders". Dus je moet iets maken dat elke keer anders is en maar 1 keer geldig is. Hoe!? Met een salt :)
Het princiepe moge duidelijk zijn... Elke keer wordt iets anders opgestuurd, waar de servert maar 1 keer iets mee kan. Wat de gebruiker invult is echter steeds hetzelfde (en meer hoeft ie ook niet te weten).
De combinatie van salt, username en password wordt een hash (niet terug te berekenen) en die wordt opgestuurd. De salt wordt natuurlijk niet apart opgestuurd :) De salt is al bekend bij de server (Leve sessions). Aan de serverkant wordt een hash gemaakt op dezelfde manier als aan de client kant, maar dan met pwd en username uit de database. Als er een match is: voila. Ingelogd.
Het is natuurlijk geen HTTPS en er zijn nog steeds manieren om deze hele techniek onderuit te halen. De pagina die het inlogformulier en javascript code naar de client stuurt is niet beveiligd (zoals HTTPS wel zou doen!!), dus daar kan mee geknoeid worden, zonder dat de gebruiker het weet. Het javascript kan bijvoorbeeld weggehaald of veranderd worden, of het formulier kan veranderd worden (zodat de logindata unencrypted naar de site van de hacker wordt gestuurd).
Daar is met mijn methode absoluut niets tegen te doen :)
HTTPS zorgt dat alles dat zowel ontvangen als verstuurd wordt, bekend is. Niet perse encrypted, maar wat wel heel belangrijk is, is dat de client en de server van elkaar weten wie en wat ze zijn. Hoe https PRECIES werkt, weet ik ook niet, maar het werkt met PKI, symmetric cipher en hashes. Een interessant artikel erover (SSL/TLS => HTTPS) staat op http://en.wikipedia.org/wiki/Transport_Layer_Security. Pittig leesvoer ;) Maar wel interessant en duidelijk. De nederlandse versie is onzin en niet de moeite waard.
Als je echt wilt weten hoe het werkt moet je ook stukken lezen over Diffie-Hellman, RSA, AES, het hash princiepe, priemgetallen en natuurlijk (pseudo-)randomness.
Heb vandaag echter gehoord dat 'de eerste quantum computer' waarheid geworden is, dus encryptie is zojuist zijn voorsprong verloren.
Dacht eigenlijk dat het verhaal redelijk duidelijk was, maar niet genoeg misschien.
Ik wil tegen gaan dat er steeds hetzelfde username-wachtwoord wordt opgestuurd.
Waarom?
Omdat het steeds hetzelfde is.
Waarom is dat slecht?
Omdat Eve (die tussen client en server aan t luisteren is) zo login data kan onderscheppen en op een later tijdstip (WANNEER ze maar wil!!) in kan loggen met gejatte logininfo.
Het keyword in mijn verhaal is "hetzelfde", niet "encrypted" of "hash". Het heeft namelijk geen zin om een gehasht username password combi (of alleen gehasht password) op te sturen. Dat is namelijk ook elke keer hetzelfde en dus ook nog geldig volgende keer (voor Eve om in te loggen).
Met keyword "hetzelfde" is de oplossing dus: "anders". Dus je moet iets maken dat elke keer anders is en maar 1 keer geldig is. Hoe!? Met een salt :)
Het princiepe moge duidelijk zijn... Elke keer wordt iets anders opgestuurd, waar de servert maar 1 keer iets mee kan. Wat de gebruiker invult is echter steeds hetzelfde (en meer hoeft ie ook niet te weten).
De combinatie van salt, username en password wordt een hash (niet terug te berekenen) en die wordt opgestuurd. De salt wordt natuurlijk niet apart opgestuurd :) De salt is al bekend bij de server (Leve sessions). Aan de serverkant wordt een hash gemaakt op dezelfde manier als aan de client kant, maar dan met pwd en username uit de database. Als er een match is: voila. Ingelogd.
Het is natuurlijk geen HTTPS en er zijn nog steeds manieren om deze hele techniek onderuit te halen. De pagina die het inlogformulier en javascript code naar de client stuurt is niet beveiligd (zoals HTTPS wel zou doen!!), dus daar kan mee geknoeid worden, zonder dat de gebruiker het weet. Het javascript kan bijvoorbeeld weggehaald of veranderd worden, of het formulier kan veranderd worden (zodat de logindata unencrypted naar de site van de hacker wordt gestuurd).
Daar is met mijn methode absoluut niets tegen te doen :)
HTTPS zorgt dat alles dat zowel ontvangen als verstuurd wordt, bekend is. Niet perse encrypted, maar wat wel heel belangrijk is, is dat de client en de server van elkaar weten wie en wat ze zijn. Hoe https PRECIES werkt, weet ik ook niet, maar het werkt met PKI, symmetric cipher en hashes. Een interessant artikel erover (SSL/TLS => HTTPS) staat op http://en.wikipedia.org/wiki/Transport_Layer_Security. Pittig leesvoer ;) Maar wel interessant en duidelijk. De nederlandse versie is onzin en niet de moeite waard.
Als je echt wilt weten hoe het werkt moet je ook stukken lezen over Diffie-Hellman, RSA, AES, het hash princiepe, priemgetallen en natuurlijk (pseudo-)randomness.
Heb vandaag echter gehoord dat 'de eerste quantum computer' waarheid geworden is, dus encryptie is zojuist zijn voorsprong verloren.
Edit:
En lees over het avalanche effect (http://en.wikipedia.org/wiki/Avalanche_effect)! Niet te verwarren met het wereldberoemde snowball effect :)
0 -0
-0
@jeroen
IP's bannen is leuk, maar daar heb je altijd no proxy's voor. Hoe dan ook. je zou een clientside encryptie kunnen bouwen en je dir's waar je js files staan dichtgooien dmv .HTACCESS dan is dit toch niet meer te achterhalen? dus een veel simpelere oplossing?
IP's bannen is leuk, maar daar heb je altijd no proxy's voor. Hoe dan ook. je zou een clientside encryptie kunnen bouwen en je dir's waar je js files staan dichtgooien dmv .HTACCESS dan is dit toch niet meer te achterhalen? dus een veel simpelere oplossing?
0 -0
-0
@cervetti
Dankje wel cervetti :) ALs ik je goed begrijp kan the man in the middle dus wel hacken als hij de salt weet? Dus als hij beide kanten afluisterd?
Dankje wel cervetti :) ALs ik je goed begrijp kan the man in the middle dus wel hacken als hij de salt weet? Dus als hij beide kanten afluisterd?
0 -0
-0
Quote:
Als je niet bij de JS kan, dan kan je wachtwoord dus ook niet ge-encrypt worden he ;-)je zou een clientside encryptie kunnen bouwen en je dir's waar je js files staan dichtgooien dmv .HTACCESS dan is dit toch niet meer te achterhalen? dus een veel simpelere oplossing?
0 -0
-0
Hey
ik heb nu deze beveiliging bij inloggen en hij werkt bijna goed.
ALs je normaal inlogd lukt het. Maar als je inlogd nadat je bent uitgelogd lukt het niet meer. Dan zegt hij dat de code fout is.
Word WEL geechoed dus ik zou niet weten wat de fout kan zijn ...
ik heb nu deze beveiliging bij inloggen en hij werkt bijna goed.
ALs je normaal inlogd lukt het. Maar als je inlogd nadat je bent uitgelogd lukt het niet meer. Dan zegt hij dat de code fout is.
Word WEL geechoed dus ik zou niet weten wat de fout kan zijn ...
0 -0
-0
Wauw, wat een geweldige tip, want ik heb het meteen in mijn systeem gebruikt, en nog wel met succes! Nu vraag ik me af, waarom elke wachtwoord TWEE keer ge?ncrypt wordt (d.i. eerst SHA1 en daarna MD5). Waarom niet eenvoudig EEN keer MD5?
Omdat mijn hostserver (nog) geen SHA1 bij haar PHPMyAdmin gesupported wordt, vraag ik me af, of EEN keer MD5 voldoende zou zijn. Of liever TWEE keer MD5? Zo ja, waarom?
Met vriendelijke groeten.
Omdat mijn hostserver (nog) geen SHA1 bij haar PHPMyAdmin gesupported wordt, vraag ik me af, of EEN keer MD5 voldoende zou zijn. Of liever TWEE keer MD5? Zo ja, waarom?
Met vriendelijke groeten.
0 -0
-0
Quote:
Als een man-in-the-middle DIE string als passphrase zou stelen, kan ie m nog niet gebruiken! Waarom niet? Omdat ie niet weet welke salt erbij hoort... Omdat de salt die erbij hoort op de server staat en niet meegestuurd wordt of als cookie is opgeslagen.
De man-in-the-middle hoeft de salt ook niet te weten. Zolang er niks met de session is gebeurd, kan de man-in-the-middle jouw session id onderscheppen en die in combinatie met jouw username en 'passphrase' gebruiken om in te loggen.
Staat ook allemaal hier:
http://nl2.php.net/manual/nl/ref.session.php
0 -0
-0
@Jan (half jaar later reageer ik haha)
2x md5 is elke keer precies hetzelfde ;) dat werkt dus niet..
md5 is altijd hetzelfde.. dat veranderd niet..
2x md5 is elke keer precies hetzelfde ;) dat werkt dus niet..
md5 is altijd hetzelfde.. dat veranderd niet..
0 -0
-0
Tim, de man in the middle kan sowieso je huidige session stelen. 100% encryptie is onmogelijk. De enige manier om je website zo veilig te maken, is IEDEREEN negeren. Je wil echter sommige mensen toelaten, dus iedereen die de juiste spullen levert, vertrouw je.
Als je als gebruiker de juiste spullen opstuurt en ze worden gejat, is je session gehijacked. Is zo en doe je niks aan.
Het doel van de tutorial en het script is echter niet om dat tegen te gaan, maar inloggegevens herbruiken tegengaan. Het moraal is dus dat je noooit twee keer dezelfde spullen levert om precies hetzelfde in te loggen. Dus een man in the middle kan nooit je login data jatten en de volgende dag ermee in loggen.
Als je session gehijacked wordt, merk je dat en log je opnieuw in -> session van man in the middle is dan invalid geworden.
Als je nog meer beveiliging wil, moet je aan HTTPS :) Hoe dat werkt mag je uitzoeken op Wiki.
Marvin, 2 keer MD5 is wel anders dan 1 keer MD5 hoor :) Maar SHA1 over MD5 is niet om veiligheid maar puur persoonlijk. Je kan ook gewoon 1 keer MD5 (maar liever 1 keer SHA1). De meer tekens er uit je hash komen (32 voor MD5 en 40 voor SHA1), de veiliger en unieker je hash is. Over t algemeen ;)
MD5 en SHA1 zitten al vanaf hele lage versies in MySQL!! Heel laag zelfs!
Als je als gebruiker de juiste spullen opstuurt en ze worden gejat, is je session gehijacked. Is zo en doe je niks aan.
Het doel van de tutorial en het script is echter niet om dat tegen te gaan, maar inloggegevens herbruiken tegengaan. Het moraal is dus dat je noooit twee keer dezelfde spullen levert om precies hetzelfde in te loggen. Dus een man in the middle kan nooit je login data jatten en de volgende dag ermee in loggen.
Als je session gehijacked wordt, merk je dat en log je opnieuw in -> session van man in the middle is dan invalid geworden.
Als je nog meer beveiliging wil, moet je aan HTTPS :) Hoe dat werkt mag je uitzoeken op Wiki.
Marvin, 2 keer MD5 is wel anders dan 1 keer MD5 hoor :) Maar SHA1 over MD5 is niet om veiligheid maar puur persoonlijk. Je kan ook gewoon 1 keer MD5 (maar liever 1 keer SHA1). De meer tekens er uit je hash komen (32 voor MD5 en 40 voor SHA1), de veiliger en unieker je hash is. Over t algemeen ;)
MD5 en SHA1 zitten al vanaf hele lage versies in MySQL!! Heel laag zelfs!
0 -0
-0
Ik slaag er niet in om de script te doen werken. De link naar http://jouwmoeder.nl/projects/js_enc_login/source.php werkt niet (meer) kan je deze herstellen? Aan de hand van de php-source kan ik eens nazien wat ik verkeerd doe.
Dank
Dank
0 -0
-0
Maar hoe gaat dat https nou in z'n werk dan? Hoe verwerk je dat in je php script, en hoe zit dat met linken naar andere https pagina's enzo? Staat daar ergens een tutorial voor?
Nieuwsgierig XD
Nieuwsgierig XD
0 -0
-0
https speelt zich voornamelijk buiten PHP af. Je kunt desgewenst $_SERVER['HTTPS'] bevragen, bevat deze sleutel de waarde 'on', dan verloopt de verbinding over SSL.
Een SSL-verbinding kun je beschouwen als een tunnel. De certificaten zorgen ervoor dat je ook nog eens de eindpunten van die tunnel kunt vertrouwen. De gegevens die je over die verbinding verstuurt, hoef je niet heel zwaar te vercijferen--ik betwijfel of het uberhaupt nodig is.
Een SSL-verbinding kun je beschouwen als een tunnel. De certificaten zorgen ervoor dat je ook nog eens de eindpunten van die tunnel kunt vertrouwen. De gegevens die je over die verbinding verstuurt, hoef je niet heel zwaar te vercijferen--ik betwijfel of het uberhaupt nodig is.
0 -0
-0
Leuke tutorial, maar zoals eerder gezegd, https:// is veel veiliger want dat encrypt en beveiligd beide kanten van de lijn dus data kan niet worden onderschept. En dat is bij dit script wel de vraag.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu