[Alg] Website beveiliging goed opzetten *

[Verwijderd]

Ik had hier net en discussie over het gebruik van MD5 of encryptie. Het geval is dus dat ik hier een applicatie moet beveiligen. Dat is verder geen probleem alleen de wijze waarop was een punt van discussie.

Op het moment dat er ingelogd wordt, wordt er een wachtwoord verstuurd die met md5 omgezet kan worden. Alleen volgens mij gebeurt dat aan de kant van de server dus zal deze toch onderschept kunnen worden worden voordat deze de server bereikt.
Nou vraag ik mij af of ik dat ook goed heb.
Ik heb hen verteld dat je dus beter SLL of ziets dergelijk toe kan passen op dat punt want dan encrypt je gewoon de gehele verbinding dus dat leek mij veiliger plus dat je de mogelijkheid hebt om de wachtwoorden van klanten nog op te vragen wat wel handig is.

Ik heb hier veel dingen gelezen over het beveiligen maar wat is nou stapsgewijs het beste aan te raden. Om toch een klantvriendelijk en zeer veilig inlogscherm te krijgen. En is SSL echt zo veilig of valt dat op een netwerk ook te sniffen of zoiets dergelijks.

[HunterPro]

Wat voor applicatie is het? Hoe mission-critical is het? En ben jij wel geschikt voor een dergelijk verantwoordelijke taak als je zulke vragen moet stellen?

[NMe]

SSL is hoe dan ook veiliger dan een gewone verbinding. MD5 is verder ook common practice, dus ik denk dat je gewoon goed bezig bent...

[Verwijderd]

Het is een applicatie die ze zelf opzetten voor klanten zoals onderwijs en dergelijke. Hiervoor gaat ook betaald worden en worden contracten aangekoppeld.
Ik zelf maak eiegenlijk gebruik van een eigen geschreven inlog functie waarbij ik wat verschillende gegevens opsla in een sessie.

Dit zijn een in het script met md5 omgezette vaste variable. Het ip van de gebruiker en een gebruiker_id.

Hierop vergelijk ik dan op in de scripts, voor mij heeft dit altijd gewerkt. En dit vind ik vrij veilig. Nu is hier dus het punt van discussie of dit voor hun ook veilig genoeg is. Ik wil dit best uitbreiden met wat verschillende zaken alleen moet het wel een meerwaarde bieden.

[curry684]

Gewoon even een stomme vraag, maar wat ben je in godesnaam aan het beveiligen: een website, intranet of extranet, een desktop app, een distributed mainframe?

MD5 en encryptie zijn verder volstrekt ongerelateerde dingen, dus een of/of vraag lijkt me irrelevant in dat kopje. En idd, als je dit soort vragen stelt ben je imho niet de correcte persoon om zoiets vitaals als security te regelen. Dat is nofi naar jou, maar bij veel applicaties gewoon te kritiek om te verneuken. Dan kun je beter een keer 'meekijken' met iemand die er meer kaas van gegeten heeft

[Sjeik]

Je kan ook met een javascriptje de te versturen gegevens md5-encrypten. Zo stuur je versleutelde informatie over een gewone verbinding.

edit:
Maar ik geef toe... Ik ben zeker geen expert op dit gebied!

[ Voor 22% gewijzigd door Sjeik op 18-10-2004 12:02 ]

[We Are Borg]

Sjeik schreef op 18 oktober 2004 @ 12:01:
Je kan ook met een javascriptje de te versturen gegevens md5-encrypten. Zo stuur je versleutelde informatie over een gewone verbinding.

edit:
Maar ik geef toe... Ik ben zeker geen expert op dit gebied!

Kan je op GoT ook doen wanneer je gaat inloggen

Mijn bijdrage (of eigenlijk die van ACM ) P&W FAQ - Hoe beveilig ik een website? .

[Verwijderd]

Dat is idd wel een idee, MD5 met javascripts... dat wordt verder wel door alle browsers ondersteund??
Ik zal het wel even nazoeken

[Verwijderd]

en dan hoeft iemand die aan het sniffen is alleen maar die md5 hash te pakken, en zelf daarna te versturen, en voila hij heeft ook de rechten.

[Andre-85]

Javascript wordt door de wat modernere browser wel ondersteund
Hier kan je informatie en een script vinden over het maken van een md5 hash met javascript.

[UltimateB]

md5 hash is toch niet echt beveiliging aangezien het zonder problemen gedecodeerd kan worden

[HunterPro]

Verwijderd schreef op 18 oktober 2004 @ 12:24:
en dan hoeft iemand die aan het sniffen is alleen maar die md5 hash te pakken, en zelf daarna te versturen, en voila hij heeft ook de rechten.

grin, inderdaad. En als hij het wachtwoord wil weten laat ie een nachtje een reverse draaien want MD5 is ontworpen voor high speed berekenten van een hash uit een waarde. Met andere woorden: erg on-slim om een pure MD5 te gebruiken om in te loggen. Het echte wachtwoord zal hij/zij niet kunnen achterhalen (of het zou echt toeval zijn) aangezien een md5 hash meer 'oplossingen' heeft.

[curry684]

Verwijderd schreef op 18 oktober 2004 @ 12:24:
en dan hoeft iemand die aan het sniffen is alleen maar die md5 hash te pakken, en zelf daarna te versturen, en voila hij heeft ook de rechten.

En daarom gebruikt een weldenkende devver dus challenge/response authenticatie.

Which brings back the fact dat we nog steeds niet weten wat voor applicatie het betreft en wat voor omgeving het om gaat

[ATS]

Je zou ook eens aan een challenge/response aanpak kunnen denken. Je loopt dan niet het risico dat WooTz aangeeft dat je md5 gehashde password gewoon wordt onderschept. Althans: je kan het wel onderscheppen, maar dat gaat je niet helpen. Een simpele (naïeve?) implementatie zou kunnen zijn dat je als challenge een gehashde versie van het IP adres van de client (+ een string ofzo) stuurt, en als response een hash van deze waarde + de md5 van het password verwacht.

[Verwijderd]

Het gaat om een helpdesksysteem waar een vrij groot bedrijf al zijn klanten onder wil gaan brengen die daar een contract voor hebben afgesloten. Afgehandelde zaken kunnen in een faq opgeslagen worden

Deze wordt gebaseerd op een intern gebruikte ERP applicatie. Hierop komt ook een webshop te draaien.
Facturen/offertes/opdrachten Online te bekijken en statussen te volgen.
RMA afhandeling moet online gebeuren.

Terugkoppeling naar de ERP-applicatie gaat dmv XML-attachments die via email binnen komen.

Best wel een bak werk, omdat de gegevens uit de ERP-applicatie online opgevraagd worden is het voor hun erg belangrijk dat dit dan ook goed beveiligd wordt

[HunterPro]

ATS schreef op 18 oktober 2004 @ 12:31:
Je zou ook eens aan een challenge/response aanpak kunnen denken. Je loopt dan niet het risico dat WooTz aangeeft dat je md5 gehashde password gewoon wordt onderschept. Althans: je kan het wel onderscheppen, maar dat gaat je niet helpen. Een simpele (naïeve?) implementatie zou kunnen zijn dat je als challenge een gehashde versie van het IP adres van de client (+ een string ofzo) stuurt, en als response een hash van deze waarde + de md5 van het password verwacht.

Dan kun je beter op het moment dat de client de challenge pullt, diezelfde challenge in de database op de server zetten, zodat je weet dat die aangevraagd is. Alleen responses naar aangevraagde challenges kunnen inloggen; zo voorkom je dat iemand elke seconde z'n zelf-gegenereerde (niet-legale) challenge laat meeroteren en het wachtwoord-deel dan kan laten varieëren, en op die manier een bruteforce attempt kan doen.

[Verwijderd]

Idd dat stuk over Challenge/Response lijkt mij ook wel erg veilig ga er gelijk mee bezig..

Voor bruteforce heb ik al wat. Ik sla het aantal mislukte logins al op in combinatie met timestamp ip. Als dit vaker dan 3 keer gebeurt mag er een 15 minuten niet meer ingelogd worden.
Thanx voor de respons

[curry684]

Verwijderd schreef op 18 oktober 2004 @ 12:36:
Het gaat om een helpdesksysteem waar een vrij groot bedrijf al zijn klanten onder wil gaan brengen die daar een contract voor hebben afgesloten. Afgehandelde zaken kunnen in een faq opgeslagen worden

Deze wordt gebaseerd op een intern gebruikte ERP applicatie. Hierop komt ook een webshop te draaien.
Facturen/offertes/opdrachten Online te bekijken en statussen te volgen.
RMA afhandeling moet online gebeuren.

Terugkoppeling naar de ERP-applicatie gaat dmv XML-attachments die via email binnen komen.

Best wel een bak werk, omdat de gegevens uit de ERP-applicatie online opgevraagd worden is het voor hun erg belangrijk dat dit dan ook goed beveiligd wordt

Ik hoor ERP, online facturen, 'alle klanten' en webshops... dan moet je sowieso via HTTPS gaan werken imho, ondanks alle andere beveiliging die je sowieso moet doen.

[Verwijderd]

Dat gebeurt ook echt wel hoor!! Ik starte dit topic ook om even eens echt duidelijk voor mezelf te krijgen wat nou veilig is. Ik dacht er nu aan na alle replies om als volgt te werken:

Inlogscherm opend op https (ssl)

Bij submit wordt de Challenge/Response toegepast zoals beschreven.

Vervolgens Indien de login ok is wordt er een sessie aangemaakt hierin wordt de gebruikersid opgeslagen zijn ip-adres en een voorgedefinieerde met md5-encrypte variabele uit configfile (extraatje) .
Op dit ip wordt gecontroleerd (of de opgeslagen hetzelfde is als de actieve). Er wordt nog gekeken of de die md5-variable bestaat en gelijk is. Wordt gekeken of de gebruikersid aanwezig is.

Dus SSL, challenge/response en controle op ip en op de bestaande sessie..

Lijkt mij al veilig.... Of heeft iemand nog een mooie uitbreiding

[curry684]

Nu nog letten op HTML- en SQL-injection en je bent klaar denk ik zo

[Verwijderd]

Nou even koffie halen en aan de slag dan maar

[dev icey]

Na een aantal topics doorgelezen te hebben, over hoe je een website moet beveiligen, zoals in dit topic gevraagd wordt, las ik het stuk over md5 encrypted gegevens versturen door de client. Ik heb dus een klein scriptje geschreven wat dus clientside het password md5 encrypt, met behulp van het script van Paj, Paj's md5 javascript.

Het is een klein scriptje, dat alleen laat zien hoe je client side iets md5'ed en dat doorgeeft met een submit. Hieraan moet natuurlijk nog het challenge/response authenticatie systeem aan toegevoegd worden, maar dat lukt met behulp van dit voorbeeld jullie wel.

Het is een tijdje geleden dat ik javascript gebruikt hebt, dus als jullie verbeteringen voor dit script weten, laat het aub horen, leer ik en anderen ook weer van. In iedergeval zag ik als enige oplossing, om de geencrypte string door te geven, het in het password vakje terug te stoppen, en gelijk erna te submitten, misschien dat dit op een betere manier kan?

Allemaal succes met het maken van het systeem , en ik heb met plezier deze topics doorgelezen. Petje af voor de beveiligings experts hier (hoop er ooit ook eentje te worden )

Net nog ff packetjes gesniffed en daar las ik dus dit:
password=598d4c200461b81522a3328565c25f7c.
Dat betekend dus, dat het in iedergeval werkt .

code:

<html>
 
 <head>
  <title>md5 javascript test</title>
  <script language="JavaScript" src="md5.js"></script>
 </head>

 <body>
  <script language='JavaScript'>
   function send() {
    hash = hex_md5(document.getElementById('passwordID').value);
    document.getElementById('passwordID').value = hash;
    document.getElementById('formID').submit();
   }
  </script>

  <form name='formnaam' id='formID' action='' method='post' onsubmit='send()'>
   <input name='password' id='passwordID' type='password'>
   <input type='submit' value='verstuur'>
  </form>

  <br /><br />

<?php
 if($_SERVER['REQUEST_METHOD'] == "POST") {
  echo "Ontvangen password(md5): ".$_POST['password']."<br />";
  echo "Md5 van \"hallo\": ".md5("hallo");
 }
?>

 </body>

</html>

Overigens zou ik graag horen in welke browsers dit allemaal werkt, tot nu toe:
Mozilla Firefox 1.0pr
MS Internet Explorer 6.0 +sp2

Disclaimer: Deze code is dus eigenlijk een voorbeeld van hoe je niet valid (x)html moet schrijven . Mist een doctype etc etc

[ Voor 133% gewijzigd door dev icey op 19-10-2004 21:02 ]

[TheBorg]

Ik ben toevallig 2 dagen aan de gang met beveiliging en zat aan het volgende systeem te denken. De server genereerd en .GIF image met een keyphrase erin, deze laat ik zien in form samen met een username/password textfield. Als de gebruiker op ok drukt dan word md5(username.password.keyphrase) verzonden. De door de server gegenereerde keyphrase is natuurlijk alleen valid voor de huidige sessie.

Is dit een correcte Challenge/Response?

[dev icey]

TheBorg schreef op 19 oktober 2004 @ 21:16:
Ik ben toevallig 2 dagen aan de gang met beveiliging en zat aan het volgende systeem te denken. De server genereerd en .GIF image met een keyphrase erin, deze laat ik zien in form samen met een username/password textfield. Als de gebruiker op ok drukt dan word md5(username.password.keyphrase) verzonden. De door de server gegenereerde keyphrase is natuurlijk alleen valid voor de huidige sessie.

Is dit een correcte Challenge/Response?

Volgens mij is dat wel zo. De "hacker/sniffer" ontvangt dan de hash(in md5) en de keyphrase. Hij kan dus niet zien wat de username/password is uit die hash. Overigens stuur je de username ook door. Maar aangezien de phrase elke keer verandert kan hij niks met die hash.

Want de volgende keer is die hash niet meer geldig, aangezien je weer een andere phrase gebruikt.

Het systeem wat jij beschrijft is precies hetzelfde dus als hierboven wordt gesugerreerd, maar jij laat de bezoeker zelf de phrase invoeren, waardoor het moeilijker voor bots wordt gemaakt de actie uit te voeren. Overigens een hele goede uitbreiding op de beveiligings ideeen als hierboven beschreven.

[eamelink]

HunterPro schreef op 18 oktober 2004 @ 12:28:
[...]

grin, inderdaad. En als hij het wachtwoord wil weten laat ie een nachtje een reverse draaien want MD5 is ontworpen voor high speed berekenten van een hash uit een waarde. Met andere woorden: erg on-slim om een pure MD5 te gebruiken om in te loggen. Het echte wachtwoord zal hij/zij niet kunnen achterhalen (of het zou echt toeval zijn) aangezien een md5 hash meer 'oplossingen' heeft.

De kans dat je het echte wachtwoord vind en geen andere plaintext lijkt me _bijzonder_ groot. De kans dat er een kleinere string dan zeg de +/- 8 tekens van een wachtwoord dezelfde hash oplevert is niet echt groot!

[TheBorg]

Ik heb er dit van gebakken:

code:

<html>
 <head>
  <title>md5 javascript test</title>
  <script language="JavaScript" src="keyphrase.js"></script>
 </head>
 <body>
  <script language='JavaScript'>
   function send() {
    username = document.getElementById('username').value;
    password = document.getElementById('password').value;
    keyphrase = document.getElementById('keyphrase').value;
    accesskey = username+password+keyphrase;
    document.getElementById('access_key').value = hex_md5(accesskey);
    document.getElementById('password').value = '';
    document.getElementById('keyphrase').value = '';
    document.getElementById('form').submit();
   }
  </script>
  <form name='formnaam' id='form' action='' method='post' onsubmit='send()'>
   username: 
   <input name='username' id='username' type='text'>
   <br>
   password:
   <input name='password' id='password' type='password'>
   <br>
   [img]'keyphrase.php'>
[/img]
   <br>
   <input type='hidden' id='access_key' name='access_key'>
   <br>
   <input type='submit' value='verstuur'>
  </form>

  <br /><br />

<?php
 if($_SERVER['REQUEST_METHOD'] == "POST") {
  echo "Ontvangen password(md5): ".$_POST['access_key']."<br />";
  echo "Md5 van \"ha ll o\": ".md5("ha"."ll"."o");
 }
?>
</body>
</html>

Zoals je ziet maak ik 'password' en 'keyphrase' value's '' zodat deze niet verstuurd worden. De username is echter wel nodig omdat het anders theoretisch kan gebeurden dat de verkeerde user inlogd...
Ik ben alleen geen JavaScript held, dus opmerkingen aan die kant zijn welkom

[JJvG]

Waar je ook nog op kan letten (naast encryptie, sql injection, ssl e.d.) is waar de formulieren vandaan worden gepost.

Als een kwaadwillende gebruiker de sources van je scherm kopieert, javascript controles weghaalt, veldlengtes groter maakt, sql statement als gebruikersnaam probeert, loop je toch risico. Door te kijken waar het POST request vandaan gekomen is, heb je weer een potentieel deurtje dichtgehouden.

[dev icey]

TheBorg schreef op 20 oktober 2004 @ 02:32:
Ik heb er dit van gebakken:

code:

<html>
 <head>
  <title>md5 javascript test</title>
  <script language="JavaScript" src="keyphrase.js"></script>
 </head>
 <body>
  <script language='JavaScript'>
   function send() {
    username = document.getElementById('username').value;
    password = document.getElementById('password').value;
    keyphrase = document.getElementById('keyphrase').value;
    accesskey = username+password+keyphrase;
    document.getElementById('access_key').value = hex_md5(accesskey);
    document.getElementById('password').value = '';
    document.getElementById('keyphrase').value = '';
    document.getElementById('form').submit();
   }
  </script>
  <form name='formnaam' id='form' action='' method='post' onsubmit='send()'>
   username: 
   <input name='username' id='username' type='text'>
   <br>
   password:
   <input name='password' id='password' type='password'>
   <br>
   [img]'keyphrase.php'>
[/img]
   <br>
   <input type='hidden' id='access_key' name='access_key'>
   <br>
   <input type='submit' value='verstuur'>
  </form>

  <br /><br />

<?php
 if($_SERVER['REQUEST_METHOD'] == "POST") {
  echo "Ontvangen password(md5): ".$_POST['access_key']."<br />";
  echo "Md5 van \"ha ll o\": ".md5("ha"."ll"."o");
 }
?>
</body>
</html>

Zoals je ziet maak ik 'password' en 'keyphrase' value's '' zodat deze niet verstuurd worden. De username is echter wel nodig omdat het anders theoretisch kan gebeurden dat de verkeerde user inlogd...
Ik ben alleen geen JavaScript held, dus opmerkingen aan die kant zijn welkom

Als ik jouw was zou ik voordat je het verstuurt de password een extra keer md5'en. Want op deze manier, moet je dus het password ongeencrypt in je database staan. Kijk maar:

Client -> Hash: md5(username+password+keyphrase)
Server-> Hash: md5(username+password(md5*)+ keyphrase)

Client != Server

Probleem is namelijk dat in je database een md5 van je password zit, dus dat gaat niet werken.

* Password uit database opgeslagen in md5 formaat

JJvG schreef op 20 oktober 2004 @ 09:39:
Waar je ook nog op kan letten (naast encryptie, sql injection, ssl e.d.) is waar de formulieren vandaan worden gepost.

Als een kwaadwillende gebruiker de sources van je scherm kopieert, javascript controles weghaalt, veldlengtes groter maakt, sql statement als gebruikersnaam probeert, loop je toch risico. Door te kijken waar het POST request vandaan gekomen is, heb je weer een potentieel deurtje dichtgehouden.

Ik vraag me af of jij toevallig ook een goede manier weet om dit te gaan controleren? Zo ja, deel dat met ons aub

In iedergeval 1 manier om dat te doen zou toch zijn, een sessie aan te maken op de inlog pagina en te controleren op de inlog(uitvoer)pagina of die sessie geset is.
Een Referer wil hier namelijk meestal niet zijn werk doen, aangezien die 1: heel simpel gefaked kunnen worden en 2: niet altijd meegestuurd worden.

[ Voor 32% gewijzigd door dev icey op 20-10-2004 13:11 ]

[Grijze Vos]

JJvG schreef op 20 oktober 2004 @ 09:39:
Waar je ook nog op kan letten (naast encryptie, sql injection, ssl e.d.) is waar de formulieren vandaan worden gepost.

Als een kwaadwillende gebruiker de sources van je scherm kopieert, javascript controles weghaalt, veldlengtes groter maakt, sql statement als gebruikersnaam probeert, loop je toch risico. Door te kijken waar het POST request vandaan gekomen is, heb je weer een potentieel deurtje dichtgehouden.

Ik meen me te herinneren dat je dat kunt vervalsen, als kwaadwillend persoon.

[Wacky]

Ik meen me te herrineren dat je de referer ook kon vervalsen door file.php?http_referer=toet.php te doen

_{(lang geleden eens mee lopen klooien, die potentiele bug /fout is er waarschijnlijk al uit)}

[dev icey]

Grijze Vos schreef op 20 oktober 2004 @ 13:08:
[...]

Ik meen me te herinneren dat je dat kunt vervalsen, als kwaadwillend persoon.

Referers zijn simpel te vervalsen ja. Maar op de manier als ik hierboven beschreef(sessies), zal het toch al lastiger worden, en is die check wel een extra goede beveiliging.

Hier is trouwens ook een telnet manier (niet getest door mij overigens , het zou best kunnen) http://www.datatrendsoftware.com/spoof.html

[ Voor 18% gewijzigd door dev icey op 20-10-2004 13:16 ]

[Andre-85]

JJvG schreef op 20 oktober 2004 @ 09:39:
Waar je ook nog op kan letten (naast encryptie, sql injection, ssl e.d.) is waar de formulieren vandaan worden gepost.

Als een kwaadwillende gebruiker de sources van je scherm kopieert, javascript controles weghaalt, veldlengtes groter maakt, sql statement als gebruikersnaam probeert, loop je toch risico. Door te kijken waar het POST request vandaan gekomen is, heb je weer een potentieel deurtje dichtgehouden.

Als beveiliging afhankelijk is van java script, doe je het niet goed. Je moet alle waardes die je binnen krijgt checken. <input type="text" maxlength="15"> dat is leuk, maar als je het goed doet moet je dat wel controleren.
Iedere input die je krijgt moet je door de addslashes() en strip_tags() functies heen halen. In je query moet je ' ' om je variabelen heen zetten. Op deze manier maak je sql injectie bijna onmogelijk.
De refferer controleren is schijnbeveiliging. Die is heel makkelijk te spoofen. Er is voor firefox bijvoorbeeld een extensie beschikbaar die spoofen heel makkelijk maakt.

[dev icey]

Andre-85 schreef op 20 oktober 2004 @ 13:38:
[...]

Als beveiliging afhankelijk is van java script, doe je het niet goed. Je moet alle waardes die je binnen krijgt checken.

Hier heb je een goed punt, maar we hebben het hier over javascript als extra beveiliging, door het sturen van een md5 encrypted password om sniffers tegen te gaan. Maar ik denk dat je toch op een andere doelgroep gokt , maar in iedergeval goed om het nog even te vermelden.

Iedere input die je krijgt moet je door de addslashes() en strip_tags() functies heen halen.

en

code:

<?php htmlspecialchars(); ?>

en

code:

<?php is_numeric(); ?>

niet te vergeten.

In je query moet je ' ' om je variabelen heen zetten. Op deze manier maak je sql injectie bijna onmogelijk.

Hier heb je het dus totaal mis. Kijk maar naar de volgende query en input:
query:

code:

<?php 
$query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET '".$offset."'"; 

$offset = "0'; UPDATE user SET Password=PASSWORD('crack') WHERE user='root";
?>

Hierdoor krijg je:

code:

<?php 
$query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET '0';
           UPDATE user SET Password=PASSWORD('crack') WHERE user='root' ";
?>

Oftewel in het geval dat de mysql_user daar rechten voor heeft, kan de hacker zo gaan inloggen onder het root account .

[querys + voorbeelden (c) php.net]

Maar ' ' horen gewoon uit netheid, maar controleer altijd de invoer zoveel als je kan. is_numeric voor getallen, desnoods gooi je een regexp match tegen de invoer aan om te kijken of het wel voldoet aan jouw standaard, als de invoer een username zonder spaties hoort te zijn, kan je al gauw kijken of de invoer spaties bevat: zo jah, voer de query niet uit.

Zorg er overigens ook voor dat de mysql user voor de site niet root rechten heeft, maar geef hem zo min mogelijk rechten, dat de website wel door blijft draaien. o.a. INSERT, UPDATE, DELETE. Je kan ook nog de user alleen rechten geven voor de database die hij gebruikt voor de website, dus niet voor de privileges database.

De refferer controleren is schijnbeveiliging. Die is heel makkelijk te spoofen. Er is voor firefox bijvoorbeeld een extensie beschikbaar die spoofen heel makkelijk maakt.

[ Voor 19% gewijzigd door dev icey op 20-10-2004 14:01 ]

[marty]

integers in een query moet je zowiezo al niet quoten. Dan kan het dus ook al niet mis gaan op de manier die je beschrijft.
maar met is_numeric kun je dan nog wel controleren, zodat je query niet stuk loopt en je gewoon de melding kan geven dat ze niet moeten zitten klooien

[Andre-85]

dev icey schreef op 20 oktober 2004 @ 13:56:
[...]
Hierdoor krijg je:

code:

<?php 
$query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET '0';
           UPDATE user SET Password=PASSWORD('crack') WHERE user='root' ";
?>

Oftewel in het geval dat de mysql_user daar rechten voor heeft, kan de hacker zo gaan inloggen onder het root account .

Dit gaat in het geval van mysql volgens mij niet werken omdat de functie mysql_query slechts één query toestaat.

[querys + voorbeelden (c) php.net]

linkje?

Maar ' ' horen gewoon uit netheid, maar controleer altijd de invoer zoveel als je kan. is_numeric voor getallen, desnoods gooi je een regexp match tegen de invoer aan om te kijken of het wel voldoet aan jouw standaard, als de invoer een username zonder spaties hoort te zijn, kan je al gauw kijken of de invoer spaties bevat: zo jah, voer de query niet uit.

Het is wel van belang om ' ' om variabelen in het WHERE gedeelte van je query te gebruiken.

code:

query = "SELECT iets FROM db WHERE id = $_POST['id']";

Als je geen quotes om $_POST['id'] heen zet is het volgende mogelijk. De hacker voert 1234 OR 1=1 in.

code:

query = "SELECT iets FROM db WHERE id = 1234 OR 1=1;

=> oftewel je query is altijd geldig.

Op het moment dat er wel quotes omheen staan wordt OR 1=1 niet gezien als sql statement maar als onderdeel van de variabele.
=> query niet geldig.
Uiteraard hoor je met php eerst de input controleren. Ik wil alleen maar aangeven dat het wel nut heeft om quotes te gebruiken.

Zorg er overigens ook voor dat de mysql user voor de site niet root rechten heeft, maar geef hem zo min mogelijk rechten, dat de website wel door blijft draaien. o.a. INSERT, UPDATE, DELETE. Je kan ook nog de user alleen rechten geven voor de database die hij gebruikt voor de website, dus niet voor de privileges database.

Dit is zeker iets waar je op moet letten, dat kan een heleboel moeilijkheden voorkomen

edit:
Ik heb het net getest of mysql_query() meerdere queries te laten uitvoeren maar dat kan volgens mij echt niet.

[ Voor 11% gewijzigd door Andre-85 op 20-10-2004 15:18 ]

[dev icey]

Andre-85 schreef op 20 oktober 2004 @ 14:40:
[...]

Dit gaat in het geval van mysql volgens mij niet werken omdat de functie mysql_query slechts één query toestaat.

[...]

linkje?

linkje

[...]
Het is wel van belang om ' ' om variabelen in het WHERE gedeelte van je query te gebruiken.

code:

query = "SELECT iets FROM db WHERE id = $_POST['id']";

Als je geen quotes om $_POST['id'] heen zet is het volgende mogelijk. De hacker voert 1234 OR 1=1 in.

code:

query = "SELECT iets FROM db WHERE id = 1234 OR 1=1;

=> oftewel je query is altijd geldig.

Op het moment dat er wel quotes omheen staan wordt OR 1=1 niet gezien als sql statement maar als onderdeel van de variabele.
=> query niet geldig.
Uiteraard hoor je met php eerst de input controleren. Ik wil alleen maar aangeven dat het wel nut heeft om quotes te gebruiken.

Daar heb je het mis, volgens mij

we nemen jouw query met ':

code:

query = "SELECT iets FROM db WHERE id = '$_POST['id']'";

De hacker voer nu 1234' OR 1='1 in, dan krijg je dit:

code:

query = "SELECT iets FROM db WHERE id = '1234' OR 1='1';

Dus dan is de query alsnog geldig, en kan de query alsnog uitgevoerd worden.

Overigens moet ik je gelijk geven dat ik het verkeerde woord "netheid" verkeerd gebruik heb, ik bedoel eerder, zoals jij al aangeeft, voor een veilige code, maar wou toch aangeven dat het geen ultieme bescherming is, omdat het op bovenstaande manier makkelijk omzeild kan worden. '' helpt alleen tegen de beginnende hackers, de hacker die wat meer weet, kan die ' heel simpel omzeilen

Maar bedankt voor je feedback

marty schreef op 20 oktober 2004 @ 14:38:
integers in een query moet je zowiezo al niet quoten. Dan kan het dus ook al niet mis gaan op de manier die je beschrijft.
maar met is_numeric kun je dan nog wel controleren, zodat je query niet stuk loopt en je gewoon de melding kan geven dat ze niet moeten zitten klooien

In bovenstaande voorbeelden waren de getallen, strings, aangezien ze uit een post zijn gehaald:

code:

$string = "1"; // is een string met inhoud 1
$int      =    1; // is een integer met waarde 1

Eigenlijk zouden we settype moeten gebruiken om de string om te zetten naar een integer. Zou je gelijk een FALSE terug krijgen, als het niet naar een integer omgezet kan worden.

[ Voor 22% gewijzigd door dev icey op 20-10-2004 15:05 ]

[joepP]

HunterPro schreef op 18 oktober 2004 @ 12:28:
[...]

grin, inderdaad. En als hij het wachtwoord wil weten laat ie een nachtje een reverse draaien want MD5 is ontworpen voor high speed berekenten van een hash uit een waarde. Met andere woorden: erg on-slim om een pure MD5 te gebruiken om in te loggen. Het echte wachtwoord zal hij/zij niet kunnen achterhalen (of het zou echt toeval zijn) aangezien een md5 hash meer 'oplossingen' heeft.

Ja vast. Heb je enig idee hoeveel verschillende wachtwoorden je gemiddeld moet proberen om een 128bits hash-collision te vinden? Dat zijn er 2^64, wat neerkomt op 18446744073709551616 pogingen. Zelfs al probeer je er een miljard per seconde dan duurt het nog steeds bijna 10.000 jaar.

Of is MD5 recentelijk gekraakt / verzwakt?

[-Lars-]

joepP schreef op 20 oktober 2004 @ 15:46:
[...]
Of is MD5 recentelijk gekraakt / verzwakt?

http://www.tweakers.net/nieuws/33911
En daar draait het om

...voor een gegeven hoeveelheid 'brondata' die een bepaalde MD5-hash oplevert, alternatieve data te berekenen die dezelfde hash genereert.

[ Voor 3% gewijzigd door -Lars- op 20-10-2004 16:02 ]

[TheBorg]

dev icey schreef op 20 oktober 2004 @ 13:06:
[...]


Als ik jouw was zou ik voordat je het verstuurt de password een extra keer md5'en. Want op deze manier, moet je dus het password ongeencrypt in je database staan. Kijk maar:

Client -> Hash: md5(username+password+keyphrase)
Server-> Hash: md5(username+password(md5*)+ keyphrase)

Client != Server

Probleem is namelijk dat in je database een md5 van je password zit, dus dat gaat niet werken.

* Password uit database opgeslagen in md5 formaat

Idd, je hebt gelijk. Ook moet de username wel unencrypted verzonden worden anders word de serverload wel erg hoog als er veel users zijn.

Anti-code injection is ook erg interessant. Om te beginnen:
Zorg ervoor dat je nooit MySQL errors laat zien.
De database structuur wordt direct zichtbaar en daar doorcode injection eenvoudiger.

[PrisonerOfPain]

Andre-85 schreef op 20 oktober 2004 @ 14:40:
[...]

Dit gaat in het geval van mysql volgens mij niet werken omdat de functie mysql_query slechts één query toestaat.

Dát voorbeeld zal niet lukken, echter kent MySql een UNION statement waar het wel mee gaat.

Over die collision in MD5; die is inderdaad gevonden. http://www.google.com/search?q=MD5+collision

[dev icey]

-Larz- schreef op 20 oktober 2004 @ 16:01:
[...]

http://www.tweakers.net/nieuws/33911
En daar draait het om

[...]

Op zich is dit wel interessant, maar zoals ze al zeggen is het voor het opslaan van wachtwoorden nog steeds goed. Met md5 hou je dus in iedergeval de wat minder ervaren, of zelfs ervaren gebruikers buiten.

[crisp]

Even je JS wat opgemooid:

In je <head>-sectie of in een extern JS-bestand:

JavaScript:

<script type="text/javascript">

    function securelogin(form)
    {
        if (md5_vm_test())
        {
            var username = form.elements['username'].value;
            var password = form.elements['password'].value;
            var keyphrase = form.elements['keyphrase'].value;

            var key = hex_md5(username + hex_md5(password) + keyphrase);

            form.elements['access_key'].value = key;
            form.elements['password'].value = '';
            form.elements['keyphrase'].value = '';

            return true;
        }
        else
        {
            return confirm('Je browser is niet in staat je wachtwoord te versleutelen\n\nLog in zonder versleuteling?');
        }
    }

</script>

je form-tag:

HTML:

<form action="iets.php" method="post" onsubmit="return securelogin(this)">

[ Voor 15% gewijzigd door crisp op 20-10-2004 16:56 ]

[dev icey]

Ik ben dus nu bezig met het controleren of de POST waarden wel verstuurd worden door jouw eigen script en dus niet door een zogenaamde hacker, ik ondervindt hier alleen wat problemen.

Referer gebruiken is onveilig: Referer is te spoofen, en wordt niet altijd meegegeven.
Sessie setten op login pagina en controleren op uitvoerpagina of de sessie geset is:
Probleem hier dus is, dat als ik naar de login pagina ga, een sessie geset wordt, maar daarna kan ik naar een andere pagina gaan(bv dus een zelf gemaakt post formulier) en dan blijft mijn sessie geset, en ziet de uitvoerpagina dus dat de sessie geset is.

Dus als iemand een manier weet om te controleren of de POST variabelen die op de uitvoerpagina komen ook echt van je eigen orginele postformulier komen, dus niet van een post formulier van een hacker.

[TheBorg]

crisp schreef op 20 oktober 2004 @ 16:40:
Even je JS wat opgemooid:

In je <head>-sectie of in een extern JS-bestand:

JavaScript:

Mooie code

1000x dank
Zo zie je maar dat ook JavaScript eigenlijk in de gereedschapskist van elke programmeur moet zitten.

[ Voor 3% gewijzigd door TheBorg op 20-10-2004 17:11 ]

[Eric]

dev icey schreef op 20 oktober 2004 @ 13:56:


Hier heb je het dus totaal mis. Kijk maar naar de volgende query en input:
query:

code:

<?php 
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20
         OFFSET '".$offset."'"; 

$offset = "0'; UPDATE user SET Password=PASSWORD('crack')
         WHERE user='root";
?>

Hierdoor krijg je:

code:

<?php 
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20
        OFFSET '0'; UPDATE user SET Password=PASSWORD('crack')
        WHERE user='root' ";
?>

En daarom moet je $offset ook door addshashes() heenhalen, het '-tekentje wordt vervangen door \' en de query wordt:

code:

<?php 
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20
        OFFSET '0\'; UPDATE user SET Password=PASSWORD(\'crack\') 
        WHERE user=\'root' ";
?>

En dit zal of een OFFSET 0 opleveren, of een foutmelding dat er een integerwaarde verwacht wordt voor OFFSET...

De code zal echter niet uitgevoerd worden, omdat deze tussen aanhalingstekens staat en er voor de aanhalingstekens in de string $offset een slash gezet worden...

<edit>enters toegevoegd in code-deel

[ Voor 34% gewijzigd door Eric op 20-10-2004 17:45 ]

[Wacky]

Kheb ff zitten klooien, werkt goed die code van crisp

[dev icey]

Super_Freak schreef op 20 oktober 2004 @ 17:37:
[...]


En daarom moet je $offset ook door addshashes() heenhalen, het '-tekentje wordt vervangen door \' en de query wordt:

code:

<?php 
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20
        OFFSET '0\'; UPDATE user SET Password=PASSWORD(\'crack\') 
        WHERE user=\'root' ";
?>

En dit zal of een OFFSET 0 opleveren, of een foutmelding dat er een integerwaarde verwacht wordt voor OFFSET...

De code zal echter niet uitgevoerd worden, omdat deze tussen aanhalingstekens staat en er voor de aanhalingstekens in de string $offset een slash gezet worden...

<edit>enters toegevoegd in code-deel

Je hebt gelijk dat je het door addslashes() moet halen. Heb ik inderdaad niet gemeld. Maar waar het mij hier omgaat, is dat we de beste beveiliging willen. Dus niet dat je een "portier voor een open deur zet", maar vooral dat je dus "die deur sluit, en nog eens een portier ervoor zet". Wat ik met deze code wou aangeven is dus, dat je moet weten dat daar een open deur zit en dat ' geen beveiliging geeft tegen sql-injection, en vooral over dat punt ging het mij om.

Een veilig script, krijg je door alle onderdelen afzonderlijk te bekijken en te beveiligen. Dus dat betekend alle gaten te dichten en ook nog eens te kijken naar andere manieren om te beveiligen.

Ik ben het dus helemaal met je eens dat je addslashes moet gebruiken (wat hiervoor al in dit topic is gezegd), maar als je de gevaren van afzonderlijke dingen niet kent, kan je het allemaal wel leuk gaan beveiligen zonder dat je weet hoe het in elkaar zit.

[TheBorg]

Wacky schreef op 20 oktober 2004 @ 17:47:
Kheb ff zitten klooien, werkt goed die code van crisp

Hij is idd erg vetjes. Voeg ook zoiets toe als:

code:

  <NOSCRIPT>
  Warning: bla bla
  </NOSCRIPT>

Dit is mijn keyphrase.php:

code:

<?php
    session_start();
    $key = substr(md5(session_id()), 0, 4);
    Header("Content-type: image/png");
    $font = imageloadfont('keyphrase.gdf');
    $keyphrase = imagecreatefrompng("keyphrase.png") or die ();
    $txt_color = ImageColorAllocate ($keyphrase, 0, 0, 0);
    ImageString ($keyphrase, $font, 5, 8,  $key, $txt_color);
    ImagePng($keyphrase);
    imagedestroy ($keyphrase);
?>

keyphrase.gdf is een binair font, het kan ook met de default fonts.
keyphrase.png is een achtergrond plaatje.

Ik ben er alleen nog niet uit hoe ik de $key ga maken. Hij moet namelijk hetzelfde zijn in de applicatie die de login checked en de waarde opslaan in de sessie lijkt me niet echt een goed idee.

[dev icey]

TheBorg schreef op 20 oktober 2004 @ 18:13:
[...]


Hij is idd erg vetjes. Voeg ook zoiets toe als:

code:

  <NOSCRIPT>
  Warning: bla bla
  </NOSCRIPT>

Dit is mijn keyphrase.php:

code:

<?php
    session_start();
    $key = substr(md5(session_id()), 0, 4);
    Header("Content-type: image/png");
    $font = imageloadfont('keyphrase.gdf');
    $keyphrase = imagecreatefrompng("keyphrase.png") or die ();
    $txt_color = ImageColorAllocate ($keyphrase, 0, 0, 0);
    ImageString ($keyphrase, $font, 5, 8,  $key, $txt_color);
    ImagePng($keyphrase);
    imagedestroy ($keyphrase);
?>

keyphrase.gdf is een binair font, het kan ook met de default fonts.
keyphrase.png is een achtergrond plaatje.

Ik ben er alleen nog niet uit hoe ik de $key ga maken. Hij moet namelijk hetzelfde zijn in de applicatie die de login checked en de waarde opslaan in de sessie lijkt me niet echt een goed idee.

nette scripts

Maar waarom lijkt het jou niet verstandig de waarde in een sessie op te slaan? Hij kan je $key altijd uitlezen omdat die in je javascript komt te staan . Overigens is een sessie lastig te hacken.

Oftewel -> hij kan niks met $key.

hacker heeft $key + hash opgevangen. Wat wilt hij ermee doen? Aangezien $key elke keer verandert, maakt het niet uit dat hij de $key heeft.

Overigens is zo'n plaatje als key, niet erg handig bij in-log systemen, zie je het al voor je? Elke keer dat je je inlogd, zon ding moeten invullen? Denk dat het eerder handig is bij registratiedoeleinden.

[ Voor 5% gewijzigd door dev icey op 20-10-2004 18:35 ]

[Wacky]

Een key opslaan als sessie is inderdaad wel een goed idee. Zodra de gebruiker op de loginpagina komt een sessie aanmaken en deze in je loginscript gebruiken voor verificatie

[TheBorg]

dev icey schreef op 20 oktober 2004 @ 18:35:
[...]


nette scripts

Maar waarom lijkt het jou niet verstandig de waarde in een sessie op te slaan? Hij kan je $key altijd uitlezen omdat die in je javascript komt te staan . Overigens is een sessie lastig te hacken.

Oftewel -> hij kan niks met $key.

hacker heeft $key + hash opgevangen. Wat wilt hij ermee doen? Aangezien $key elke keer verandert, maakt het niet uit dat hij de $key heeft.

Overigens is zo'n plaatje als key, niet erg handig bij in-log systemen, zie je het al voor je? Elke keer dat je je inlogd, zon ding moeten invullen? Denk dat het eerder handig is bij registratiedoeleinden.

Hoe makkelijk is het voor de hacker om de session variablen uit te lezen? Het idee was namelijk om ook brute-force acties af te kunnen slaan. Met het keyphrase plaatje is er dan al OCR nodig, als de keyphrase value uitgelezen kan worden dan kan de hacker dat natuurlijk implementeren in zijn brute-force script.

[TheBorg]

Na een google op session hijacking kwam ik bij dit zeer interesante artikel:
http://www.astalavista.co...rammers_hacking_huide.pdf
Komen leuke dingen aan bod zoals:
Cross Site Scripting
SQL Injection
UBB Hacks
Arbitrary Command Execution
Remote PHP execution
Mime Content Type Hack
Session Hijacking
Cookies

En bij toeval nog in het Nederlands ook.

[dev icey]

TheBorg schreef op 20 oktober 2004 @ 19:00:
[...]

Hoe makkelijk is het voor de hacker om de session variablen uit te lezen? Het idee was namelijk om ook brute-force acties af te kunnen slaan. Met het keyphrase plaatje is er dan al OCR nodig, als de keyphrase value uitgelezen kan worden dan kan de hacker dat natuurlijk implementeren in zijn brute-force script.

Maar de key die je opslaat in een sessie om later de server de hash te laten berekenen, moet ook bekend zijn bij de bezoeker, zodat die dezelfde hash kan maken. Dus die key wordt verstuurd, dus de hacker krijgt de key al zonder de sessies te kapen. Maar nu komt het leuke van de key, die verandert bij elke GET van de pagina . Dus je hoeft je niet zorgen te maken over de key in een sessie, want de hacker kan er (bijna) niks mee.

[joepP]

Je schreef als reactie op mijn bericht dat het ondoenlijk is om een message te vinden die een gegeven MD5 hash heeft:

-Larz- schreef op 20 oktober 2004 @ 16:01:
[...]

http://www.tweakers.net/nieuws/33911
En daar draait het om

[...]

Onzin. Lees het artikel eens goed.

Ze hebben een methode ontdekt om willekeurige collisions te vinden, dus twee verschillende messages M en M' die dezelfde MD5 hashwaarde opleveren. Binnen een uur. Een prachtige prestatie overigens!

Dit is echter wel compleet iets anders dan gegeven een MD5 hash een bericht te vinden die deze hash heeft. Voor opslag van wachtwoorden is er voorlopig nog helemaal niets aan de hand.

[TheBorg]

dev icey schreef op 20 oktober 2004 @ 20:49:
[...]


Maar de key die je opslaat in een sessie om later de server de hash te laten berekenen, moet ook bekend zijn bij de bezoeker, zodat die dezelfde hash kan maken. Dus die key wordt verstuurd, dus de hacker krijgt de key al zonder de sessies te kapen. Maar nu komt het leuke van de key, die verandert bij elke GET van de pagina . Dus je hoeft je niet zorgen te maken over de key in een sessie, want de hacker kan er (bijna) niks mee.

Gewoon de key md5 opslaan, dan heb je er bij brute force niets aan

code:

<?php
    session_start();
    
    $seed = "ABCHEFGHJKMNPQRSTUVWXYZ0123456789";
    $key = "";
    
    srand((double)microtime()*1000000);
    for ($x = 0; $x < 4; $x++) {
        $key = $key.substr($seed, rand() % strlen($seed), 1);
    }
    $_SESSION['keyphrase'] = md5($key);

    Header("Content-type: image/png");
    $font = imageloadfont('keyphrase.gdf');
    $keyphrase = imagecreatefrompng("keyphrase.png") or die ();
    $txt_color = ImageColorAllocate ($keyphrase, 0, 0, 0);
    ImageString ($keyphrase, $font, 5, 8,  $key, $txt_color);
    ImagePng($keyphrase);
    ImageDestroy ($keyphrase);
?>

Resultaat (bij elke pageload natuurlijk anders):

Ik moet nog een beetje werken aan de duidelijkheid van de letters...

Overigens heb ik nu een veiligheidslek in React gevonden

[ Voor 21% gewijzigd door TheBorg op 20-10-2004 21:33 ]

[dev icey]

TheBorg schreef op 20 oktober 2004 @ 21:24:
[...]


Gewoon de key md5 opslaan, dan heb je er bij brute force niets aan

code:

<?php
    session_start();
    
    $seed = "ABCHEFGHJKMNPQRSTUVWXYZ0123456789";
    $key = "";
    
    srand((double)microtime()*1000000);
    for ($x = 0; $x < 4; $x++) {
        $key = $key.substr($seed, rand() % strlen($seed), 1);
    }
    $_SESSION['keyphrase'] = md5($key);

    Header("Content-type: image/png");
    $font = imageloadfont('keyphrase.gdf');
    $keyphrase = imagecreatefrompng("keyphrase.png") or die ();
    $txt_color = ImageColorAllocate ($keyphrase, 0, 0, 0);
    ImageString ($keyphrase, $font, 5, 8,  $key, $txt_color);
    ImagePng($keyphrase);
    ImageDestroy ($keyphrase);
?>

Resultaat (bij elke pageload natuurlijk anders):
[afbeelding]
Ik moet nog een beetje werken aan de duidelijkheid van de letters...

Overigens heb ik nu een veiligheidslek in React gevonden

Waarom zou je de key willen md5'en. Het voegt echt niks toe. Geloof me nou, het maakt niks uit dat de hacker de key weet .

Denk wat betreft die veiligheidslek (dat je wat minder hacking guides moet gaan lezen) en ik ook denk dat je niet zoveel met de cookies hier kan

[Wacky]

Hmm, wat me net opvalt bij die javascript MD5 encryptie van crisp .. als je op "Verstuur" klikt vult ie het paswoord veld verder op

Iemand enig idee waarom?

[TheBorg]

Wacky schreef op 20 oktober 2004 @ 23:40:
Hmm, wat me net opvalt bij die javascript MD5 encryptie van crisp .. als je op "Verstuur" klikt vult ie het paswoord veld verder op

Iemand enig idee waarom?

Das logish, de waarde word veranderd en op het scherm meteen bijgewerkt. Ik heb dit opgelost met een hidden field, zodat je dat niet ziet gebeuren.

[Wacky]

TheBorg schreef op 20 oktober 2004 @ 23:44:
[...]


Das logish, de waarde word veranderd en op het scherm meteen bijgewerkt. Ik heb dit opgelost met een hidden field, zodat je dat niet ziet gebeuren.

Goede oplossing, heb 't hier nu ook even gefixed

_{Boeiend topic, ik hoop dat er nog meer goede tips komen}

[T-MOB]

Voor de MD5-sceptici in dit topic maar even een benchje in elkaar gedraaid. Mijn conclusie: het bruteforcen van een MD5-hash is vrij kansloos. Mijn server doet er ongeveer 14 seconden over om alle wachtwoorden van 3 chars lang (in de scope [a-z, A-Z, 0-9]) te md5-en. Wat neerkomt om zo'n 1,2 * 10²⁰ jaar voor alle wachtwoorden van 8 karakters binnen deze scope. Nu staat er bij mij maar een simpel K6-III'tje (@400Mhz \o/) te serveren, maar het geeft wel de orde van grootte aan...

Voor eenieder die wil benchen op zijn eigen server (en die wil weten of er een 3-cijferig alternatief is voor zijn wachtwoord):

PHP:

<?php
$testPW = isset($_GET['test']) ? md5($_GET['test']) : '';

header('content-type: text/plain');
## BENCHMARK
function getmicrotime() { 
    list($usec, $sec) = explode(" ",microtime()); 
    return ((float)$usec + (float)$sec); 
    } 
$time_start = getmicrotime();
##<-- BENCHMARK


$string = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890';

$start = getmicrotime();
for ($i=0; $i<strlen($string); $i++)
{
    $a = $string[$i];
    for ($j=0; $j<strlen($string); $j++)
    {
        $b = $string[$j];
        for ($k=0; $k<strlen($string); $k++)
        {
            $n = md5($a .$b .$string[$k]);
            if ($n == $testPW) 
            { 
            echo 'alternative for ' .$_GET['test'] .': ' .$a .$b .$string[$k]; 
            }
        }
    }
}

$end = getmicrotime();
$time = $end - $start;

$eight_digit = ceil ($time *(pow(8,62)/pow(3,62))/3600/24/365);
echo "\n THIS OPERATION TOOK " .$time .' seconds' ."\n" 
     .'Calculation time for 8 char PW`s: ' .$eight_digit .' years';

?>

[ Voor 23% gewijzigd door T-MOB op 21-10-2004 01:19 ]

[TheBorg]

Verander voor de grap eens md5 naar sha1. Ben benieuwd. De sha1 hash is 4bit langer.

-edit-
Laat maar, dat scheelt namelijk ongeveer 20%. M.a.w., daar ga je ook niet op zitten wachten.

Overigens is PHP niet echt de aangewezen taal om dit soort acties in uit te voeren...

[ Voor 54% gewijzigd door TheBorg op 21-10-2004 01:32 ]

[T-MOB]

TheBorg schreef op 21 oktober 2004 @ 01:24:
Verander voor de grap eens md5 naar sha1. Ben benieuwd. De sha1 hash is 4bit langer.

Dat scheelt niet veel (16s om 1.3*10²⁰ jaar). Maar de test werkt ook andersom: ik bereken de hash voor alle wachtwoorden met 3 karakters. Op welke manier je die hashed maakt daarvoor niet zoveel uit (tenzij het hash-algorithme traag is). Het gaat om het vinden van "een" string die dezelfde hash heeft.

Overigens is PHP niet echt de aangewezen taal om dit soort acties in uit te voeren...

Ach... als het gaat om "de orde van grootte"... Een factor 10²⁰ werk je niet zo snel weg met een andere taal, noch snellere hardware.

[ Voor 26% gewijzigd door T-MOB op 21-10-2004 01:39 ]

[Wacky]

Ach, als er al iemand is die je MD5 wil gaan kraken ... dan MD5 je je hash toch nog een keer

[Scorpion]

persoonlijk ben ik zelf voor een beveiliging als op de volgende pagina:
http://blackpowderonline.com/verify1.htm

[TheBorg]

Scorpion schreef op 21 oktober 2004 @ 13:08:
persoonlijk ben ik zelf voor een beveiliging als op de volgende pagina:
http://blackpowderonline.com/verify1.htm

Dat zit potdicht

[Wacky]

_{Heerlijk offtopic ja ^^}