https voor inloggen zonder https

Door Rudie dirkx, 16 jaar geleden, 10.674x bekeken

Je wil data veilig oversturen, maar zonder https? Makkelijk!

Gesponsorde koppelingen

Inhoudsopgave

  1. Wat je wil...
  2. Fokken met the man-in-the-middle
  3. The man is niet dom en ook een client
  4. De oplossing

 

Er zijn 36 reacties op 'Https voor inloggen zonder https'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Barry
Barry
16 jaar geleden
 
0 +1 -0 -1
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')
Rudie dirkx
rudie dirkx
16 jaar geleden
 
0 +1 -0 -1
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...
Mitch X
Mitch X
16 jaar geleden
 
0 +1 -0 -1
Ik ben nogal lui atm, dus lees maar half, als ik onzin type, zeg het dan maar :P

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?


16 jaar geleden
 
0 +1 -0 -1
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.
Lasse
Lasse
16 jaar geleden
 
0 +1 -0 -1
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?
Jeroen Langenberg
Jeroen Langenberg
16 jaar geleden
 
0 +1 -0 -1
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.
Jelmer -
Jelmer -
16 jaar geleden
 
0 +1 -0 -1
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.


16 jaar geleden
 
0 +1 -0 -1
Denk trouwens dat er meer keyloggers zijn dan man in the middle's.
Martijn B
Martijn B
16 jaar geleden
 
0 +1 -0 -1
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.
Frank -
Frank -
16 jaar geleden
 
0 +1 -0 -1
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.
Martijn B
Martijn B
16 jaar geleden
 
0 +1 -0 -1
@Frank:

Denk dat SSL wel het makkelijkst is idd. Alleen heb je daar dan ook een certificaat voor nodig?
Klaasjan Boven
Klaasjan Boven
16 jaar geleden
 
0 +1 -0 -1
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
Frank -
Frank -
16 jaar geleden
 
0 +1 -0 -1
@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.
Lissy Pixel
Lissy Pixel
16 jaar geleden
 
0 +1 -0 -1
@ Frank : dus samenvattend goedkoop wordt dan duurkoop.
Andreas Warnaar
Andreas Warnaar
16 jaar geleden
 
0 +1 -0 -1
Dat is het idd Lissy. Groot gemaakte fout in de development!
Winston Smith
Winston Smith
16 jaar geleden
 
0 +1 -0 -1
Quote:
Met dit soort scriptjes kun je het misschien een paar dagen/weken/maanden uitstellen, maar vroeg of laat ben je aan de beurt.
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.

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.
Rudie dirkx
rudie dirkx
16 jaar geleden
 
0 +1 -0 -1
mensen zonder javascript hebben idd pech :)
Remco van Lent
Remco van Lent
16 jaar geleden
 
0 +1 -0 -1
goede oplossing als net zo als bij mij je provieder geen https ondersteunt
Rudie dirkx
rudie dirkx
16 jaar geleden
 
0 +1 -0 -1
Frank
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 ;)
Peter Wessels
Peter Wessels
16 jaar geleden
 
0 +1 -0 -1
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
Rudie dirkx
rudie dirkx
16 jaar geleden
 
0 +1 -0 -1
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:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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."');");

?>


Zoiets?
Koen B
Koen B
16 jaar geleden
 
0 +1 -0 -1
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 ...)
Rudie dirkx
rudie dirkx
16 jaar geleden
 
0 +1 -0 -1
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.

Edit:
En lees over het avalanche effect (http://en.wikipedia.org/wiki/Avalanche_effect)! Niet te verwarren met het wereldberoemde snowball effect :)
Jurgen assaasas
Jurgen assaasas
16 jaar geleden
 
0 +1 -0 -1
@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?
Koen B
Koen B
16 jaar geleden
 
0 +1 -0 -1
@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?
K i p
K i p
16 jaar geleden
 
0 +1 -0 -1
Quote:
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?
Als je niet bij de JS kan, dan kan je wachtwoord dus ook niet ge-encrypt worden he ;-)
Koen B
Koen B
16 jaar geleden
 
0 +1 -0 -1
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.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
var salt = '<?php echo $_SESSION['js_enc_login']['salt']; ?>';

Word WEL geechoed dus ik zou niet weten wat de fout kan zijn ...
Jan de Vrije
Jan de Vrije
16 jaar geleden
 
0 +1 -0 -1
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.
Tim Verweij
Tim Verweij
15 jaar geleden
 
0 +1 -0 -1
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
Marvin S
Marvin S
15 jaar geleden
 
0 +1 -0 -1
@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..
Rudie dirkx
rudie dirkx
15 jaar geleden
 
0 +1 -0 -1
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!
Ivan
Ivan
15 jaar geleden
 
0 +1 -0 -1
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
Tammetje
Tammetje
15 jaar geleden
 
0 +1 -0 -1
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
Bas Cost Budde
Bas Cost Budde
14 jaar geleden
 
0 +1 -0 -1
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.
- SanThe -
- SanThe -
14 jaar geleden
 
0 +1 -0 -1
Even voor de duidelijkheid: Dit is GEEN https.
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Justin S
Justin S
14 jaar geleden
 
0 +1 -0 -1
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.

Inhoudsopgave

  1. Wat je wil...
  2. Fokken met the man-in-the-middle
  3. The man is niet dom en ook een client
  4. De oplossing

Labels

  • Geen tags toegevoegd.

PHP tutorial opties

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.