[php] simpel te kraken?

[Verwijderd]

ik maak wel vaker met php een simpel inlog systeempje, en wel als volgt:

op wijzig.php moet je een wachtwoord invullen. Vervolgens op verzenden drukken en dan staat er in check.php het volgende:

code:

<?

if ($ww = 1234) {
print "hier komt dan allemaal belangrijke info";
} else {
print "hier iets van je hebt je ww niet goed";
};

?>

Ik heb het hier wel eens eerder gezien, en toen zeiden een hoop mensen dat het makkelijk te kraken is.
Kan iemand me vertellen hoe mensen dit kraken?

Een letterlijk voorbeeld(script)? Tnx!!!

/me is benieuwd

[Orphix]

nou ik fiets gewoon met m'n browser naar check.php en dan kom ik binnen

[Xandrios]

Op donderdag 28 februari 2002 15:32 schreef Orphix het volgende:
nou ik fiets gewoon met m'n browser naar check.php en dan kom ik binnen

eem....als $ww geen 1234 is, zal hij toch "hier iets van je hebt je ww niet goed" laten zien

lijkt me dan....

[Verwijderd]

Op donderdag 28 februari 2002 15:32 schreef Orphix het volgende:
nou ik fiets gewoon met m'n browser naar check.php en dan kom ik binnen

Moet je het wachtwoord wel weten

edit: te laat

[HGM]

Das wel veilig totdat iemand de source kan zien, doen dan zoiets if(MD5($ww) == MD5_string) ..

[Pooh]

Geef eens een voorbeeld van een site, dan kunnen we 't proberen.

[Verwijderd]

Op donderdag 28 februari 2002 15:37 schreef Poohbear het volgende:
Geef eens een voorbeeld van een site, dan kunnen we 't proberen.

moment svp

[Verwijderd]

Op donderdag 28 februari 2002 15:17 schreef ivy het volgende:

if ($ww = 1234) {

maak daar ff een == van anders komt iemand altijd binnen

[brammetje]

Op donderdag 28 februari 2002 15:34 schreef Cutebritney het volgende:
eem....als $ww geen 1234 is, zal hij toch "hier iets van je hebt je ww niet goed" laten zien

lijkt me dan....

Nee hoor, hij checkt gewoon of hij 1234 aan $ww kan toekennen.. zal meestal wel true opleveren

edit: 2 sec te laat.

[Verwijderd]

Ben nu ook sinds kort bezig in de wondere wereld van PHP/MYSQL, maar het enige waar je bij dit soort oplossingen toch op moet letten is dat de mensen je .php bestanden niet uit kunnen lezen en dat je dus idd je ftp dir enzo (net als bij ons op de kub) dicht moet zetten? Op het moment dat jij namelijk een .php file in je browser aanvraagt zal de server toch je request nemen, de html genereren en terugsturen?

Interessante topic!

[Verwijderd]

en zie hier voor de liefhebbers:

http://www.streamingmediadesign.nl/kraakme/kraakme.php?ww=vuldanhierjewachtwoordmaarin

Succes! Er wordt beweerd dat dit simpel te kraken is, dus kom maar op (niet door jullie, maar iedereen maakt altijd van die moeilijk inlog systemen terwijl dat volgens mij helemaal niet nodig is).

Als je het ww weet, dan krijg je iets te zien. Laat me weten wat!

[Pooh]

Op donderdag 28 februari 2002 15:37 schreef HGM het volgende:
Das wel veilig totdat iemand de source kan zien, doen dan zoiets if(MD5($ww) == MD5_string) ..

MD5 is redelijk veilig, maar niet heel sterk... de beste tooltjes halen 15k keys / seconde op 1 processor (800 MHz), dat is 1.296.000.000 keys / dag.

not case-sensitive, alleen letters:
5 letters: 26^5 = 11881376 = 13 minuten
6 letters: 26^6 = 308915776 = 5.7 uur
7 letters: 26^7 = 8031810176 = 6 dagen

Alleen een wachtwoord met hoofd en kleine letters, cijfers en leestekens is echt moeilijk te kraken...

[Verwijderd]

Op donderdag 28 februari 2002 15:46 schreef Poohbear het volgende:

[..]

MD5 is redelijk veilig, maar niet heel sterk... de beste tooltjes halen 15k keys / seconde op 1 processor (800 MHz), dat is 1.296.000.000 keys / dag.

not case-sensitive, alleen letters:
5 letters: 26^5 = 11881376 = 13 minuten
6 letters: 26^6 = 308915776 = 5.7 uur
7 letters: 26^7 = 8031810176 = 6 dagen

Alleen een wachtwoord met hoofd en kleine letters, cijfers en leestekens is echt moeilijk te kraken...

dus jij weet binnen 5 min. de informatie van de test site te halen? ben beniewut

[Verwijderd]

Op donderdag 28 februari 2002 15:45 schreef ivy het volgende:
maar iedereen maakt altijd van die moeilijk inlog systemen terwijl dat volgens mij helemaal niet nodig is).

alleen een wachtwoord valideren is niet zo ingewikkeld te maken nee _duh...
maar zorgen dat een gebruiker niet bij iedere actie ze wachtwoord in moet vullen is weer wat anders

[Grum]

de beveliging is net zo slecht als de zwakste plek erin en dat is hier:

1/ kort/slecht wachtwoord
en potentieel (omdat je er normaliter niet bij kan)
2/ plain txt pass in de file

[HGM]

Op donderdag 28 februari 2002 15:51 schreef Grum_ het volgende:
de beveliging is net zo slecht als de zwakste plek erin en dat is hier:

1/ kort/slecht wachtwoord

en potentieel (omdat je er normaliter niet bij kan)
2/ plain txt pass in de file

Tja, database of text file, maakt niet zoveel verschil IMO. Anders moet ie de php file zend-encoderen, problem solved

[Pooh]

Op donderdag 28 februari 2002 15:48 schreef ivy het volgende:

[..]

dus jij weet binnen 5 min. de informatie van de test site te halen? ben beniewut

Nee hoor... heb geen beschikking over brute-force capaciteiten hier, heb ook geen zin om moeite te doen... Maar iemand met een goede lijn zou een heel eind komen.

[Verwijderd]

Misschien een optie is om een soort account lock te maken door in bijvoorbeeld de tabel (ik heb het dus over een login systeem met database) een extra veld op te nemen waarin staat of je wel of niet mag inloggen (boolean). Als er dan bijvoorbeeld 10x een verkeerd password is ingetikt (ook loggen in een aparte tabel) de mag inloggen veld te veranderen naar false en dat dan een kwartier te laten staan ofzo. Dan wordt het een stuk moeilijker voor een key generator lijkt mij.

[Olaf van der Spek]

Op donderdag 28 februari 2002 15:40 schreef brammetje het volgende:

[..]

Nee hoor, hij checkt gewoon of hij 1234 aan $ww kan toekennen.. zal meestal wel true opleveren

edit: 2 sec te laat.

Nee, hij doet $ww = 1234 (wat 1234 oplevert) en kijkt of 1234 true is.

[Olaf van der Spek]

Op donderdag 28 februari 2002 15:53 schreef Poohbear het volgende:

[..]

Nee hoor... heb geen beschikking over brute-force capaciteiten hier, heb ook geen zin om moeite te doen... Maar iemand met een goede lijn zou een heel eind komen.

Dan moet je dus wel de MD5 waarde hebben en die heb je hier ook niet.

[brammetje]

Op donderdag 28 februari 2002 16:35 schreef OlafvdSpek het volgende:
Nee, hij doet $ww = 1234 (wat 1234 oplevert) en kijkt of 1234 true is.

hmmz.. ok

[Pooh]

Op donderdag 28 februari 2002 16:26 schreef Xenith het volgende:
Misschien een optie is om een soort account lock te maken door in bijvoorbeeld de tabel (ik heb het dus over een login systeem met database) een extra veld op te nemen waarin staat of je wel of niet mag inloggen (boolean). Als er dan bijvoorbeeld 10x een verkeerd password is ingetikt (ook loggen in een aparte tabel) de mag inloggen veld te veranderen naar false en dat dan een kwartier te laten staan ofzo. Dan wordt het een stuk moeilijker voor een key generator lijkt mij.

De makkelijkere oplossing is een sleep() toevoegen. 1 keer per seconde inloggen is voor een normale gebruiker meer dan genoeg, maar voor een brute-force attack vreselijk...

[drm]

Olafvdspek heeft wel een goed puntje. Is niet helemaal wat hij zei, maar dit idee vloeit er wel uit voort:

Namelijk: encodeer het wachtwoord in md5 voordat de request gedaan wordt.

Gevolg: mensen die hun wachtwoord intikken en submitten versturen in feite een wachtwoord van 32 characters ipv. een stuk of 6.

Ga dat maar eens brute-force hacken.

[drm]

woeitje:
alleen een wachtwoord valideren is niet zo ingewikkeld te maken nee _duh...
maar zorgen dat een gebruiker niet bij iedere actie ze wachtwoord in moet vullen is weer wat anders

Zet het wachtwoord in een cookie

[Verwijderd]

He vriend, je hebt je apache manual nog online staan. Dazz niet zo veilig.

http://212.203.14.81///manual/

[Verwijderd]

Op donderdag 28 februari 2002 16:49 schreef olav het volgende:
He vriend, je hebt je apache manual nog online staan. Dazz niet zo veilig.

http://212.203.14.81///manual/

Nee, want dan komen we er achter hoe Apache werkt

[Verwijderd]

ik vindt dat jullie allemaal wat moois te zeggen hebben, maar ondertussen weet niemand de info nog van de test site....

Mijn conclusie tot nu toe: zo dicht als een huis

[Verwijderd]

Op donderdag 28 februari 2002 16:55 schreef ivy het volgende:
ik vindt dat jullie allemaal wat moois te zeggen hebben, maar ondertussen weet niemand de info nog van de test site....

Mijn conclusie tot nu toe: zo dicht als een huis

Als je niet een script in de buurt hebt waarmee je de source van het script kan bekijken op zich wel ja.

[Grum]

wanneer komt er een policy dat deze threads zonder enig pardon dicht gesmeten worden ?

bruteforcen doe je zelf maar .. en als je er bang voor bent .. dan zet je maar nix online

[Woef]

Op donderdag 28 februari 2002 17:01 schreef Grum_ het volgende:
wanneer komt er een policy dat deze threads zonder enig pardon dicht gesmeten worden ?

bruteforcen doe je zelf maar .. en als je er bang voor bent .. dan zet je maar nix online

Das onzin,
dat was zijn vraag ook helemaal niet!
Zijn vraag was of het veilig was en niet HOE het te kraken is!

[Olaf van der Spek]

Op donderdag 28 februari 2002 16:44 schreef Poohbear het volgende:

[..]

De makkelijkere oplossing is een sleep() toevoegen. 1 keer per seconde inloggen is voor een normale gebruiker meer dan genoeg, maar voor een brute-force attack vreselijk...

Ja, maar het vertraagt de boel ook, terwijl dat toch te voorkomen is.

[Verwijderd]

Discussies over hoe iets te verbeteren valt m.b.t. security is interessant, maar of een bepaalde site/pagina nou wel of niet te kraken valt niet.

[Verwijderd]

Op donderdag 28 februari 2002 17:17 schreef OlafvdSpek het volgende:

[..]

Ja, maar het vertraagt de boel ook, terwijl dat toch te voorkomen is.

Ik kende de functie nog niet, ik dacht dat sleep alleen mogelijk was in deplhi/c++ builder enzo.

Ik vind het ook niet echt een mooie oplossing, geef mij toch maar mijn manier , alhoewel ik tot nu toe te lui ben geweest om het ergens in toe te passen .

[Olaf van der Spek]

Op donderdag 28 februari 2002 16:59 schreef Zef het volgende:

[..]

Als je niet een script in de buurt hebt waarmee je de source van het script kan bekijken op zich wel ja.

En zo'n script bestaat (IIRC) ook helemaal niet.

En inderdaad gaat dit niet over een bepaalde site maar over een bepaald algoritme.

Ik vind het hier soms een beetje hypocriet dat over dit soort zaken niet gesproken mag/kan worden.

[Grum]

Op donderdag 28 februari 2002 17:17 schreef Xenith het volgende:
Discussies over hoe iets te verbeteren valt m.b.t. security is interessant, maar of een bepaalde site/pagina nou wel of niet te kraken valt niet.

my point

[Verwijderd]

Op donderdag 28 februari 2002 17:17 schreef Xenith het volgende:
Discussies over hoe iets te verbeteren valt m.b.t. security is interessant, maar of een bepaalde site/pagina nou wel of niet te kraken valt niet.

Moet je iets verbeteren als het al goed is? Denk het niet. Maar hoe weet je of een beveiliging goed is? Post het op GoT /14...

/me vindt dat er wel zielige gasten zijn hoor. Als de discussie ze niet bevalt don*eren ze toch lekker op

[Verwijderd]

Op donderdag 28 februari 2002 17:01 schreef Grum_ het volgende:
wanneer komt er een policy dat deze threads zonder enig pardon dicht gesmeten worden ?

bruteforcen doe je zelf maar .. en als je er bang voor bent .. dan zet je maar nix online

wat ben jij een triest figuur zeg

[Verwijderd]

Op donderdag 28 februari 2002 18:00 schreef ivy het volgende:

[..]

wat ben jij een triest figuur zeg

_amen

[Bart B]

Je moet met nog iets rekening houden wanneer je aan het beveiligen bent. Bij gewoon gebruik van MD5 is wordt iedere keer dat de gebruiker inlogged de zelfde gegevens verzonden. Wanneer deze gegevens kan aflsuiteren (op een HUB of een passerende router is dit mogelijk) is het mogelijk heeel makelijk in te loggen (gebruik de zelfde gegevens als die gebruiker).

Als je het geheel wat veiliger wilt maken dan zorg je er voor dat je een MD5-codering toepast, en ook een cijfer toevoegd (erachter plakken bijv). Wanneer deze veranderd iedere keer dat de gebruiker inlogged is het zo mogelijk om een heel veilig inlogsysteem te maken, zonder dat het voor iemand mogelijk is om af te luisteren.

Tijdens mijn stage heb ik iets dergelijks in Javascript geschreven. Kijk er maar es naar. Het is best een mooi mechanisme, zeker wanneer een aantal kleine veranderingen worden doorgevoerd. (stageverslag te vinden op http://beumer.xs4all.nl/bart/dirindex/school/stage/ )

[Grum]

zoals al eerder gezegd is:

Discussies over het verbeteren van de veiligheid zijn ok. Domme 'bruteforce-mijn-site-dan'-discussies zijn 100% zinloos.

Als je zelf nix kan bedenken om et te testen heb je vast ook niet genoeg in huis om er iets tegen te doen en tis een beetje zonde van ieders cpu-cycles/bandbreedte om ze jou probleem op te laten lossen.

En tja .. kan je niet tegen commentaar ? .. post dan niet als ik wakker ben

[GA!S]

Op donderdag 28 februari 2002 17:01 schreef Grum_ het volgende:
wanneer komt er een policy dat deze threads zonder enig pardon dicht gesmeten worden ?

bruteforcen doe je zelf maar .. en als je er bang voor bent .. dan zet je maar nix online

Sorry hoor, maar zo'n reply als die van jou in een redelijk interessante discussie is IMHO vele malen erger...

Nog minder nuttig dan deze reply!

[Verwijderd]

Op donderdag 28 februari 2002 17:56 schreef ivy het volgende:
Moet je iets verbeteren als het al goed is? Denk het niet.

Daar ben ik het niet helemaal mee eens, ik denk dat (bijna) alles altijd beter kan.

[Verwijderd]

Op donderdag 28 februari 2002 16:47 schreef drm het volgende:
Gevolg: mensen die hun wachtwoord intikken en submitten versturen in feite een wachtwoord van 32 characters ipv. een stuk of 6.

Ga dat maar eens brute-force hacken.

Ik ben geen expert hierin, maar volgens mij maakt dit helemaal niks uit, want je kan gewoon je brute force ding op die inlog pagina zetten en die inlog pagina zet dit weer om in 32 characters. Volgens mij is dat md5 opslaan in de database om te voorkomen dat iemand het echte password kan lezen (bijvoorbeeld degene die de site beheren) of als er een leak in de database zit dat de passworden dan nog steeds onbruikbaar zijn.

[drm]

Xenith:
je kan gewoon je brute force ding op die inlog pagina zetten en die inlog pagina zet dit weer om in 32 characters.

Zit wat in
* drm was obviously niet wakker ...

[Verwijderd]

Ik maak zowiezo gebruik van encrypted timestamps in al mijn urls indien mogelijk. Dan wordt inbreken al een stuk moeilijker.

[Verwijderd]

Op donderdag 28 februari 2002 15:45 schreef ivy het volgende:
en zie hier voor de liefhebbers:

http://www.streamingmediadesign.nl/kraakme/kraakme.php?ww=vuldanhierjewachtwoordmaarin

Succes! Er wordt beweerd dat dit simpel te kraken is, dus kom maar op (niet door jullie, maar iedereen maakt altijd van die moeilijk inlog systemen terwijl dat volgens mij helemaal niet nodig is).

Als je het ww weet, dan krijg je iets te zien. Laat me weten wat!

alleen cijfers als wachtwoord? of ook letters/?

[Olaf van der Spek]

Op donderdag 28 februari 2002 18:16 schreef Bart B het volgende:
Je moet met nog iets rekening houden wanneer je aan het beveiligen bent. Bij gewoon gebruik van MD5 is wordt iedere keer dat de gebruiker inlogged de zelfde gegevens verzonden. Wanneer deze gegevens kan aflsuiteren (op een HUB of een passerende router is dit mogelijk) is het mogelijk heeel makelijk in te loggen (gebruik de zelfde gegevens als die gebruiker).

Met een switch ben je ook nog niet veilig.

Als je het geheel wat veiliger wilt maken dan zorg je er voor dat je een MD5-codering toepast, en ook een cijfer toevoegd (erachter plakken bijv). Wanneer deze veranderd iedere keer dat de gebruiker inlogged is het zo mogelijk om een heel veilig inlogsysteem te maken, zonder dat het voor iemand mogelijk is om af te luisteren.

Tijdens mijn stage heb ik iets dergelijks in Javascript geschreven. Kijk er maar es naar. Het is best een mooi mechanisme, zeker wanneer een aantal kleine veranderingen worden doorgevoerd. (stageverslag te vinden op http://beumer.xs4all.nl/bart/dirindex/school/stage/ )

Het is jammer dat dit net niet zonder JS kan.

[Verwijderd]

Op donderdag 28 februari 2002 18:00 schreef ivy het volgende:

[..]

wat ben jij een triest figuur zeg

Je moet er gewoon niet op ingaan man, dan ben jij degene die triest is! Maar on-topic, dit is gemakkelijk te kraken, gewoon brute-forcen. Je kan wel zeggen: niemand is het nog gelukt maar ik denk te dat meer te wijten is aan het feit dat niemand daar zin in heeft.

[Verwijderd]

Op vrijdag 01 maart 2002 12:16 schreef robbinh het volgende:

[..]

Je moet er gewoon niet op ingaan man, dan ben jij degene die triest is! Maar on-topic, dit is gemakkelijk te kraken, gewoon brute-forcen. Je kan wel zeggen: niemand is het nog gelukt maar ik denk te dat meer te wijten is aan het feit dat niemand daar zin in heeft.

ben ik aan het doen

edit:

(maar nu alleen met zijfers, wil weten of er ook letters tussen staan)

[Grum]

dit word wel errug paranoia

als je 100% veilig op internet wil zitten dan moet je niet op internet zitten.

conclusie: over sommige dingen moet je niet mekkeren. alles wat beveiligd is kan toch bekeken worden. zo niet ? dan kan de andere kant het ook niet zien en wat heb je dan nog aan de data?

je kan het mensen moeilijk maken maar niet (nearly) onmogelijk,zonder het jezelf moeilijk te maken (of de serverload naar een nieuwe hoogte te schoppen))

Wat je ZOU kunnen doen:

je komt op de page, er word een publickey in een javascriptje gezet (bv md5(rand().microtime().rand()))

je insert die publickey + ip in de database

nu vul je op die page je password in. Een javascriptje maakt mbv van de publickey en een md5 algoritme jouw private key en submit die ipv je password mee onsubmit. (bv dit om de private key te maken: md5($publickey.$password)

nu controleer je of
1/ de publickey bij het ip hoort
2/ de privatekey bij de publickey hoort

zo jah .. dan hebben we onze gebruiker geindentificeerd zonder dat we z'n pass hebben gezien

de volgende keer dat de gebruiker op een page (als je paranoide bent zoals we hier allemaal zijn) hoeft je alleen even z'n IP+publickey te checken en je bent klaar.

je kan de publickey nu in een cookie kwakken en als et niet meer geldig is de hele 'inlog' procedure overnieuw doen.

MAAR dit is ranzig inefficient want je moet elke keer kijken of ie wel een openstaande sessie heeft

maarja .. der is nou eenmaal een prijs voor 'security'

(en dat is voor mij een prijs die ik nooit zal betalen - ik haat deze methodes zeker op een webbrowser schaal - ik heb em wel toegepast in een xmlrpc-session schema waar het perfect voldoet omdat je max 3 calls doet )

[TheRebell]

Hmmm...als ik nou intik in mn browser:

code:

check.php?ww=1234

dan zal ik er dus zo opkomen. Ik doe ook zoiets maar ik maak gebruik van sessions. Ik delete alle variabelen die ik vie de url binnen krijg en vraag ze via PHP_SESSION_VARS gewoon weer op.

werkt geweldig en is (iig via de url) niet te omzeilen

[Verwijderd]

Op vrijdag 01 maart 2002 13:27 schreef TheRebell het volgende:
Hmmm...als ik nou intik in mn browser:

code:

check.php?ww=1234

dan zal ik er dus zo opkomen. Ik doe ook zoiets maar ik maak gebruik van sessions. Ik delete alle variabelen die ik vie de url binnen krijg en vraag ze via PHP_SESSION_VARS gewoon weer op.

werkt geweldig en is (iig via de url) niet te omzeilen

WERKT GEWELDIG??? AL EENS GEPROBEERD???


voordat je zegt dat het geweldig werkt

snuggere

[Grum]

dit is de reden dat trackvars in php4.1.X std uitstaat

Magio: Wat blaat je ? Denk zelf eerst es ff na voor je wat post. Wat onze vriend zegt klopt.

es kijken of je dom/eigenwijs genoeg bent om een discussie met me aan te gaan

[Verwijderd]

discussie altijd welkom (open die site dan met dat als wachtwoord)
http://www.streamingmediadesign.nl/kraakme/kraakme.php?ww=1234

[Grum]

ok dit is zinloos .. je snapt dus ook totaal niet wat bedoeld woord door TheRebell.

zucht

[Verwijderd]

Op vrijdag 01 maart 2002 14:09 schreef Grum het volgende:
ok dit is zinloos .. je snapt dus ook totaal niet wat bedoeld woord door TheRebell.

zucht

je snapt dus ook totaal niet wat bedoeld wordt

[Verwijderd]

Even weer ontopic hoor:
dit is dus gewoon veilig (bruteforce daargelaten)? Ik wil namelijk een zelfde eenvoudige manier gebruiken.

Met veilig bedoel ik dus zolang ze je .php(3) bestanden niet kunnen bekijken.

En stop flaming, ik ben ook maar een redelijke newB met php, maar vind dit wel een interessante vraag (van iemand anders met weinig ervaring). Kom op, we hebben het allemaal een keer moeten leren. Volgens mij klopt het wat ik zeg, zo niet hoor ik graag van iemand wat er dan niet aan klopt en waarom.

[Grum]

ja dat is dus veilig genoeg .. tot iemand je verbinding proxied of sniffed

[LuCarD]

Dit topic kan je ongeveer vergelijken met.

Ik heb me voordeur van me huis opslot gedaan kan iemand zonder de sleutel de deur openmaken?
Antwoord: Nee

Is mijn huis nu veilig?
Antwoord: hangt er vanaf of je het raam dicht heb gedaan.

Met andere woorden: deze topic is redelijk onzinnig....

[Verwijderd]

Goed je moet het misschien in de context zien:

er staat geen bedrijfskritische info op ofzo, gewoon een script om een nieuwspagina van een studentenclubje te updaten. Dan lijkt de deur op slot me genoeg .

Verder even offtopic: ik heb ook wel eens een sniffer gedraaid maar dat kostte zoveel moeite om uberhaupt iets ergs zinnigs op te vangen dat het me wat veel moeite lijkt voor dit soort oplossingen?

[SWINX]

Op dinsdag 12 maart 2002 16:55 schreef LuCarD het volgende:

Met andere woorden: deze topic is redelijk onzinnig....

Toch nog meer mensen die het doorhebben
Er komen tegenwoordig steeds meer topics met "is dit veilig" en allemaal even on-nuttig

[LauPro]

Zo'n programma is zo gemaakt, maar de mensen die zomaar een site gaan aanvallen hebben denk ik 0,001 % kans dat ze binnen een dag binnenkomt. Pak het slim aan en kijk bijvoorbeeld eventjes mee als hij zijn password intypt (1 letter kan alweer een week schelen... (zoals je zag)). Soms is dit een beetje lastig omdat de persoon bijvoorbeeld aan de andere kant van de wereld woont.

En als je een site gaat 'hacken' dan moet je je van tevoren goed realiseren met wie je maken hebt. Ivy bijvoorbeeld is niveau 2 (geen zorgen Ivy, niveau 100 is pas het hoogst ). Dit bijvoorbeeld zou je met een simpele do-loop kunenn doen:

code:

'language: Visual Basic
dim i as double, s as string

do
   i = i + 1
   s = PakInHoudVanUrlMetNr(i)
   if instr(s, "info") <> 0 then exit do
   'moet nog een beperking e.d. in
loop

msgbox "Gekraakt! met nr: " & i

4 cijverig heb je denk ik binnen een paar minuten gedaan.

[D2k]

mooi ik heb het wel gezien
voegt nix toe (zie de post van Grum over beveiliging die iets toevoegd en dit soort bruteforcen)
verder staat de sfeer me niet aan dus aan ieder het verzoek zich iets minder te laten uitlokken en gewoon correct te antwoorden
de replyers in een topic kan je negeren de topicstarter niet