[php] md5 password onderscheppen.

[Verwijderd]

Ik heb een loginformuliertje en encrypt het wachtwoord md5 met javascript alvorens naar de server te sturen.

Op de server verglijk ik met PHP dit ww met die in de dbs. Komen deze overeen, dan is het ok.

Nu kan iemand dit wachtwoord met een sniffer onderscheppen en dan het formuliertje even simuleren en men is ook binnen.

Hoe kan ik dit oplossen? IP adres md5 in een hash met het wachtwoord? Heb ik een probleem als men achter een proxy zit oid.

Bedankt voor elke tip of suggestie.

[curry684]

Zoek eens op dit forum op 'challenge response' logica

[OkkE]

Wachtwoord + timestamp in MD5 hash. Dan is die hash maar bijv 1 seconde te gebruiken, genoeg om in te loggen. De kans dat iemand binnen die tijd snifft en opnieuw inlogt is klein.

[Emmeau]

https ? ssl?

[curry684]

[rml]curry684 in "[ php] User authenticatie veilig? "Hacker"[/rml]

[Verwijderd]

curry bedankt. Ik ga even lezen. Ik zocht gewoon de term challenge response.

Okke, denk je dat dat veilig is? Komt de timestamp die je clientside genereert dan overeen met die serverside?

[curry684]

Verwijderd schreef op 20 October 2003 @ 14:15:
curry bedankt. Ik ga even lezen. Ik zocht gewoon de term challenge response.

Okke, denk je dat dat veilig is? Komt de timestamp die je clientside genereert dan overeen met die serverside?

De challenge moet in principe uniek zijn, dus een timestamp + sequence nummer of gewoon een GUID (de makkelijkste methode).

En je moet niet clientside genereren, maar op de server. De client doet alleen het password erinhashen.

[ Voor 12% gewijzigd door curry684 op 20-10-2003 14:17 ]

[Verwijderd]

Simpele RSA bouwen in javascript

[Bosmonster]

Challenge is leuk, maar ook voor zover ik weet niet echt veilig in browser-based systemen. De challenge moet je doorgeven aan de client door deze in de pagina te genereren. Gevolg? Iedereen kan dat ding lezen/regenereren/hergebruiken. Zeker als je weet hoe de client dat ding MD5't...

Dit blijft gewoon een probleem met javascript oplossingen (en over hetzelfde probleem breek ik met Flash dus al maanden mijn hoofd.. hoe in hemelsnaam een veilig highscore systeem te bouwen ).

[curry684]

Bosmonster schreef op 20 October 2003 @ 15:16:
Challenge is leuk, maar ook voor zover ik weet niet echt veilig in browser-based systemen. De challenge moet je doorgeven aan de client door deze in de pagina te genereren. Gevolg? Iedereen kan dat ding lezen/regenereren/hergebruiken. Zeker als je weet hoe de client dat ding MD5't...

Aan de serverside buffer je echter je outstanding challenges natuurlijk, en deze zijn na 15 minuten of zo niet meer geldig. Daarnaast koppel je ze natuurlijk aan het IP

[Bosmonster]

curry684 schreef op 20 October 2003 @ 15:17:
[...]

Aan de serverside buffer je echter je outstanding challenges natuurlijk, en deze zijn na 15 minuten of zo niet meer geldig. Daarnaast koppel je ze natuurlijk aan het IP

Dat lost het probleem niet op daar waar het het makkelijkste is: binnen een bedrijf.

[Verwijderd]

Koppelen aan IP vind ik niet echt een oplossing. Daarnaast nog een nadeel: iedereen kan je PHP sessie uitlezen. Of kun je deze op de een of andere manier beveiligen?

[Soultaker]

Bosmonster schreef op 20 October 2003 @ 15:36:
Dat lost het probleem niet op daar waar het het makkelijkste is: binnen een bedrijf.

Want...?

Verwijderd schreef op 20 October 2003 @ 15:44:
Daarnaast nog een nadeel: iedereen kan je PHP sessie uitlezen.

Heu? Hoe doen ze dat dan weer?!

[Verwijderd]

Stel iemand heeft FTP en PHP toegang op dezelfde server. Diegene kan in phpinfo de map halen waar de phpsessionid's opgeslagen zijn . /tmp ofzo. Aangezien je webserver toegang heeft tot deze map kan je hem zo met fopen uitlezen en dan een scriptje maken waarbij je dit sessionid achter je url plaatst (trans_sid gebeuren) en dan een print_r($_SESSION) doet de rest.

Sorry niet iedereen dus. Je moet wel toegang hebben tot de server en dit is in mijn geval niet ondenkbaar.

[ Voor 15% gewijzigd door Verwijderd op 20-10-2003 15:54 ]

[Soultaker]

Naar mijn mening is dat een volledig ander onderwerp... Mag je het van mij ook wel over hebben, maar heeft vrij weinig met client authentication te maken.

In principe zou het helemaal geen probleem moeten zijn dat je webserver bepaalde bestanden op de server heeft staan, als de boel maar goed afgeschermd is. Dat betekent PHP in safe mode draaien, bijvoorbeeld, en andere gebruikers niet toestaan de session-directory uit te lezen. Dat is echter een lokaal configuratieverhaal en heeft met beveiliging tegen inbreuk van buitenaf niets te maken. Het is sowieso gewoon verstandig om mensen die daar niets te zoeken hebben van je internetserver te weren; uit je reacties kon ik onmogelijk afleiden dat dit in jouw situatie onmogelijk zou zijn.

[ Voor 16% gewijzigd door Soultaker op 20-10-2003 15:59 ]

[Bosmonster]

Soultaker schreef op 20 October 2003 @ 15:47:
[...]

Want...?

Iedereen zelfde uitgaande IP?

[ Voor 4% gewijzigd door Bosmonster op 20-10-2003 17:23 ]

[Soultaker]

Bosmonster schreef op 20 October 2003 @ 17:22:
Iedereen zelfde uitgaande IP?

Dat is toch helemaal geen issue? Als je binnen je bedrijf niet hebt beveiligd, dan zijn er nog wel honderd miljoen manieren om de beveiliging te doorbreken? Keylogger, extra VGA kabel, iemand die meekijkt, op de harde schijf opgeslagen data bekijken, enzovoorts, enzovoorts.

Het gaat erom dat je beschermd bent tegen factoren waar je geen invloed op hebt: die buiten je bedrijfsnetwerk dus. Je kunt onmogelijk eisen dat een externe webapplicatie jou beveiliging biedt tegen jouw eigen netwerkbeheer. Dat is ook onmogelijk te garanderen natuurlijk.

[BtM909]

Soultaker schreef op 20 October 2003 @ 18:37:
[...]

... Je kunt onmogelijk eisen dat een externe webapplicatie jou beveiliging biedt tegen jouw eigen netwerkbeheer. Dat is ook onmogelijk te garanderen natuurlijk.

Wat heeft het antwoord van Bosmonster met beveiliging te maken

Waar het groene monster op doelt is als je je beveiliging gaat baseren op IP-adressen, dat het IP-adres wellicht niet zo uniek is als je zou verwachten.

[curry684]

Ik zei ook helemaal niet 'baseren op IP-adressen', read again Ik zei dat je challenges altijd uniek moeten zijn en voor 1 IP max 15 minuten geldig moeten zijn. Het 2e gedeelte is puur een cleanup en een extra bescherming tegen sessietje jatten, terwijl het 1e gedeelte het al overbodig maakt. Niemand kan binnen 15 minuten een MD5 bruteforcen, vooral niet als je maar 1 poging mag doen

[Verwijderd]

Ok, duidelijk. Wat zou in mijn geval dan een veilige authenticatie procedure zijn.

Mensen moeten in kunnen loggen op een website en ww en gebruikersnaam kunnen onthouden met een cookie.

Ik kan geen gebruik maken van SSL, maar wil wel dat wachtwoord en gebruikersnaam niet te onderscheppen zijn door een sniffer.

Dit zou wel mogen, maar dan moet het dus op een of andere manier encrypt zijn, waardoor een hacker er niks mee kan.

[Gerco]

Precies wat hierboven beschreven is, je genereert op de server een challenge, maakt niet zoveel uit wat het is, een md5 hash van een willekeurig getal is bijvoorbeeld wel leuk.

Die challenge stuur je mee met het login form als een hidden form variable, Javascript code op de client maakt van het password een md5 hash, plakt de challenge daarachter en gooit nog een md5 over het geheel en submit het naar de server.

Op de server maak je een md5 hash van je uitstaande challenge en de opgeslagen md5 hash van het wachtwoord van de gebruiker. De gesubmitte hash en de server gegenereerde hash controleer je met elkaar, zijn die gelijk, is de gebruiker ingelogd.

De uitstaande challenge is natuurlijk slechts een beperkte tijd geldig en wordt verwijderd zodra er een verkeerde inlogpoging gebeurd, dan genereer je gewoon een nieuwe challenge.

Waarom nu die dubbele md5 van het wachtwoord? Simpel, op de server heb je het wachtwoord natuurlijk alleen als hash opgeslagen, je zal dus met de hash van het wachtwoord en de challenge een nieuwe hash moeten maken, omdat anders de server niet dezelfde hash kan genereren, die heeft het originele wachtwoord immer niet.

[Verwijderd]

Die challenge stuur je mee met het login form als een hidden form variable, Javascript code op de client maakt van het password een md5 hash, plakt de challenge daarachter en gooit nog een md5 over het geheel en submit het naar de server.

En als je die handel nu onderschept met een sniffer en die dan achter het url post. Dan ben je toch ook binnen?

[ik voel me net een newbie opmerking]
Hmmm ik zit net nog een beetje te zoeken en kom erachter dat wanneer je register_globals op off zet, je niet meer je variabelen via een GET of POST kan krijgen. Misschien dat ik dit kan gebruiken.... ik speur nog even verder.
[/ik voel me net een newbie opmerking]

[ Voor 30% gewijzigd door Verwijderd op 21-10-2003 16:01 ]