[JS] Hoe password MD5 encrypten voor POST wordt uitgevoerd

[Verwijderd]

Ik zou graag de variablen password welke gevuld word in een form MD5 encrypten voordat deze ge-post wordt door het form.

Dus als op de knop login wordt gedrukt, dat dan eerst het password wordt geencrypt en dan gepost.

Kan dit?

[gorgi_19]

Je wilt door door middel van Javascript een wachtwoord MD5'en? Vervolgens wil je dit gehash'de wachtwoorden verzenden?

[Verwijderd]

Met javascript. Even zoeken op onze zoekgod was voldoende.

[crisp]

http://pajhome.org.uk/crypt/md5/index.html

hash wel een eenmalige challenge mee, anders is het natuurlijk nog niet secure.

[ Voor 50% gewijzigd door crisp op 14-10-2004 16:35 ]

[Verwijderd]

gorgi_19 schreef op 14 oktober 2004 @ 16:34:
Je wilt door door middel van Javascript een wachtwoord MD5'en? Vervolgens wil je dit gehash'de wachtwoorden verzenden?

Nee, niet door middel van java. Gewoon bv. met de php functie MD5($password);
maar dit moet uitgevoerd worden VOORDAT er gepost wordt.

[Verwijderd]

crisp schreef op 14 oktober 2004 @ 16:35:
http://pajhome.org.uk/crypt/md5/index.html

hash wel een eenmalige challenge mee, anders is het natuurlijk nog niet secure.

offtopic:
Crisp en Ivy zoeken klaarblijkelijk met dezelfde zoekmasjien

[Verwijderd]

crisp schreef op 14 oktober 2004 @ 16:35:
http://pajhome.org.uk/crypt/md5/index.html

hash wel een eenmalige challenge mee, anders is het natuurlijk nog niet secure.

Ik kan je hier even niet volgen.

[gorgi_19]

Verwijderd schreef op 14 oktober 2004 @ 16:36:
[...]


Nee, niet door middel van java. Gewoon bv. met de php functie MD5($password);
maar dit moet uitgevoerd worden VOORDAT er gepost wordt.

Java != Javascript. Als je nog niet gepost hebt, zit je op de client en komt PHP er nog niet bij kijken Deze draait op de server Zie Crisp (oa) voor een Javascript oplossing; deze kan op de client draaien

[AtleX]

Verwijderd schreef op 14 oktober 2004 @ 16:36:
[...]


Nee, niet door middel van java. Gewoon bv. met de php functie MD5($password);
maar dit moet uitgevoerd worden VOORDAT er gepost wordt.

Kan niet, PHP wordt uitgevoerd op de server. Elke event voor de POST is op de client, daar kan je met PHP niets doen.

[Verwijderd]

AtleX schreef op 14 oktober 2004 @ 16:37:
[...]


Kan niet, PHP wordt uitgevoerd op de server. Elke event voor de POST is op de client, daar kan je met PHP niets doen.

Ok, dan houd het op wat PHP betreft. Ik zal de javascript oplossing implementeren.

[gorgi_19]

Dan gooi ik hem nog even richting Webdesign & Graphics

[Verwijderd]

crisp schreef op 14 oktober 2004 @ 16:35:
http://pajhome.org.uk/crypt/md5/index.html

hash wel een eenmalige challenge mee, anders is het natuurlijk nog niet secure.

Kun je misschien een korte uitleg geven? Wat bedoel je precies met een eenmalige challenge

[.oisyn]

Verwijderd schreef op 14 oktober 2004 @ 16:36:
[...]


Ik kan je hier even niet volgen.

Wat heb je eraan als je gewoon md5 (je_wachtwoord) stuurt? Als iemand anders de data onderschept kan hij ook gewoon diezelfde waarde opsturen als hij als jou in wil loggen, zonder dat ie dan je wachtwoord weet.

Je moet dus met je form een bepaalde waarde (noemen we even x) meesturen die elke keer anders is, zodat die waarde mee kan worden genomen in je MD5 berekening. Als iemand nou het gehashte wachtwoord onderschept dan kan hij alleen maar inloggen als x ook hetzelfde is, dus als jij zorgt dat die x elke keer anders is heeft de persoon niets aan de onderschepte data.

[ Voor 13% gewijzigd door .oisyn op 14-10-2004 16:44 ]

[MBV]

Waarom gebruik je niet HTTPS voor zo'n belangrijk form? Dan kan er helemaal geen data worden onderschept, zonder uren te rekenen aan de sleutels

[Verwijderd]

.oisyn schreef op 14 oktober 2004 @ 16:43:
[...]


Wat heb je eraan als je gewoon md5 (je_wachtwoord) stuurt? Als iemand anders de data onderschept kan hij ook gewoon diezelfde waarde opsturen als hij als jou in wil loggen, zonder dat ie dan je wachtwoord weet.

Je moet dus met je form een bepaalde waarde (noemen we even x) meesturen die elke keer anders is, zodat die waarde mee kan worden genomen in je MD5 berekening. Als iemand nou het gehashte wachtwoord onderschept dan kan hij alleen maar inloggen als x ook hetzelfde is, dus als jij zorgt dat die x elke keer anders is heeft de persoon niets aan de onderschepte data.

Maar die meegestuurde x waarde kunnen ze toch ook opvangen?

Hoe controleer je dan tegen de database of je pwd klopt als de waarde x elke keer verandert? Aan wat voor soort berekening moet ik dan denken?

[crisp]

stappenplan:

1. genereer serverside een random variabele x
2. sla deze op in een sessie
3. stuur formulier door naar client met variabele x
4. gebruiker typt wachtwoord in
5. genereer nu een waarde y1 dmv md5(md5(wachtwoord) + x)
6. stuur y1 terug naar server
7. server haalt wachtwoord z van gebruiker uit database - deze is natuurlijk al als md5 opgeslagen
8. server berekent zelf y2 dmv md5(z + x)
9. als y1 == y2 dan mag de gebruiker verder, anders terug naar 1)

[Janoz]

De server onthoudt x en stuurt deze naar de client. De client hashed wachtwoord+x en stuurt dit op naar de server. De server haalt het wachtworod op en maakt ook een hash van wachtwoord+x en vergelijkt dit met de opgestuurde versie. Komen deze overeen dan was het wachtwoord het juiste wachtwoord.

Door x nu te laten varieren is het overgestuurde (hash van wachtwoord+x) dus altijd verschillend. Een onderschepte waarde kan nooit worden hergebruikt tenzij er ooit een keer dezelfde x op de server wordt onthouden.

hmm... spuit++

[.oisyn]

Verwijderd schreef op 14 oktober 2004 @ 16:49:
[...]


Maar die meegestuurde x waarde kunnen ze toch ook opvangen?

En wat hebben ze daaraan dan? Die verandert toch steeds, ze weten slechts dat voor een bepaalde x het md5 van je wachtwoord y is, dus kunnen ze alleen met y inloggen als x hetzelfde is. Alleen x verandert steeds, dus y ook.

- Server genereert random waarde (x), en slaat deze op
- Server stuurt x met de html mee
- Client berekent y = md5 (ingevoerde_wachtwoord + x), en stuurt dat terug
- Server controleert of y == md5 (opgeslagen_wachtwoord + opgeslagen_x)

Nadeel van bovenstaand schema is dat de server beschikking moet hebben over een ongecodeerd wachtwoord, maar ik laat de manier om dat op te lossen aan jouw creativiteit over

[Roa]

Verwijderd schreef op 14 oktober 2004 @ 16:49:
[...]


Maar die meegestuurde x waarde kunnen ze toch ook opvangen?

Hoe controleer je dan tegen de database of je pwd klopt als de waarde x elke keer verandert? Aan wat voor soort berekening moet ik dan denken?

Goed, iets anders uitgelegd.

Je hebt een inlog script met 2 velden, een username veld en een password veld. Je wilt niet dat mensen je password kunnen onderscheppen, dus je encrypt dit d.m.v. javascript, maar als mensen nu het geëncrypte wachtwoord onderscheppen, kunnen ze nog steeds inloggen, ze kunnen immers de opgevangen data verzenden naar de server, dus wat je wilt is bij iedere POST een uniek iets toevoegen. Wat je dus in feite moet doen is dit:

Als iemand op de login pagina komt, stuur je d.m.v. php ook een hidden veld mee waarin een unieke key staat (een cijfer o.i.d.) Als het formulier vervolgens gesubmit wordt, stop je de username, het password en die key bijelkaar, en je encrypt het. Dan pas verstuur je de data naar je server. In je php script dat de login controleerd doe je hetzelfde, je voegt de username, het password en die key weer samen, en je encrypt dit. Vervolgens vergelijk je die 2 gegevens met elkaar, die zouden overéén moeten komen. Als de verzonden data dus anders was, klopt of het wachtwoord niet, of de username of er zat geen key bij/de key was fout.

Doordat je dus iedere keer een andere key gebruikt (random) kan iemand die die gegevens onderschept er niets mee, want de key is bij iedere aanvraag weer anders en dus kan hij/zij er nog niets mee

edit:
Nou, je zou denken dat het na 4 posts met uitleg toch wel duidelijk moet zijn

Nadeel van bovenstaand schema is dat de server beschikking moet hebben over een ongecodeerd wachtwoord, maar ik laat de manier om dat op te lossen aan jouw creativiteit over

Daar is ook weer van alles te verzinnen hoor, persoonlijk vind ik het gevaarlijker om je wachtwoorden ongecodeerd in je database te hebben staan, dan om geen key bij je post te hebben. Maar goed, hoe veilig wil je het hebben, het is niet alsof er kernraketten kunnen worden afgevuurd als je in het CMS komt

[ Voor 16% gewijzigd door Roa op 14-10-2004 17:03 ]

[.oisyn]

Roa: hashen != encrypten

Daar is ook weer van alles te verzinnen hoor

euh ja duh, het ging me erom dat ik niet alles voor wilde kauwen, maar helaas heeft crisp de hint al gegeven...

[ Voor 76% gewijzigd door .oisyn op 14-10-2004 17:05 ]

[Roa]

.oisyn schreef op 14 oktober 2004 @ 17:03:
Roa: hashen != encrypten

Mjah, maar je kan ook een hash encrypten en dat was eigenlijk wel de bedoeling volgens mijn verhaal..dacht ik Ohk, goed, ik had de username even weg moeten laten in mijn voorbeeld

[Verwijderd]

Roa schreef op 14 oktober 2004 @ 17:00:
[...]


Goed, iets anders uitgelegd.

Je hebt een inlog script met 2 velden, een username veld en een password veld. Je wilt niet dat mensen je password kunnen onderscheppen, dus je encrypt dit d.m.v. javascript, maar als mensen nu het geëncrypte wachtwoord onderscheppen, kunnen ze nog steeds inloggen, ze kunnen immers de opgevangen data verzenden naar de server, dus wat je wilt is bij iedere POST een uniek iets toevoegen. Wat je dus in feite moet doen is dit:

Als iemand op de login pagina komt, stuur je d.m.v. php ook een hidden veld mee waarin een unieke key staat (een cijfer o.i.d.) Als het formulier vervolgens gesubmit wordt, stop je de username, het password en die key bijelkaar, en je encrypt het. Dan pas verstuur je de data naar je server. In je php script dat de login controleerd doe je hetzelfde, je voegt de username, het password en die key weer samen, en je encrypt dit. Vervolgens vergelijk je die 2 gegevens met elkaar, die zouden overéén moeten komen. Als de verzonden data dus anders was, klopt of het wachtwoord niet, of de username of er zat geen key bij/de key was fout.

Doordat je dus iedere keer een andere key gebruikt (random) kan iemand die die gegevens onderschept er niets mee, want de key is bij iedere aanvraag weer anders en dus kan hij/zij er nog niets mee

edit:
Nou, je zou denken dat het na 4 posts met uitleg toch wel duidelijk moet zijn

[...]


Daar is ook weer van alles te verzinnen hoor, persoonlijk vind ik het gevaarlijker om je wachtwoorden ongecodeerd in je database te hebben staan, dan om geen key bij je post te hebben. Maar goed, hoe veilig wil je het hebben, het is niet alsof er kernraketten kunnen worden afgevuurd als je in het CMS komt

Thx, allemaal.
Ik kom er wel uit.

[Verwijderd]

Ik ben toch gezwicht voor javascript.
Ik maak gebruik van een PHP SESSIE. In deze sessie creer ik een unieke code. Nu wil ik dmv javascript hetvolgende uitvoeren vb.: md5(password+unieke code) en dan posten.

Maar hoe kan ik dmv. javascript de functie POST van een pagina overnemen?

De rest(md5 enzo) lukt wel in javascript, maar hoe submit ik dan het form?

Verder, bedankt voor al de reacties. Ik heb al enorm veel geleerd hier.

[MisterData]

euhm...

code:

<form id="mijnForm"> blabla </form>

in de JS:

document.getElementById('mijnForm').submit();

[crisp]

beter is

HTML:

<form onsubmit="functie()">

[Verwijderd]

Hmm, ik had gedacht dat er in javascript een functie md5 zou zitten, maar dat bestaat er niet volgens mij.
En ik krijg het niet voor mekaar om de evt. gewijzigde gegevens terug te sturen naar het form.
Iemand enig idee hoe dit wel werkend te krijgen is?
Thx..

[Erkens]

Verwijderd schreef op 18 oktober 2004 @ 20:10:
Hmm, ik had gedacht dat er in javascript een functie md5 zou zitten, maar dat bestaat er niet volgens mij.

waarom denk je dat ivy en crisp dan een linkje hebben gepost met md5 in javascript?

Verwijderd schreef op 14 oktober 2004 @ 16:34:
Met javascript. Even zoeken op onze zoekgod was voldoende.

crisp schreef op 14 oktober 2004 @ 16:35:
http://pajhome.org.uk/crypt/md5/index.html

hash wel een eenmalige challenge mee, anders is het natuurlijk nog niet secure.

[Verwijderd]

Tuurlijk, srry. Zal aan het feit liggen dat ik nu al 13,5 uur aan het werk ben

Toch rest mij een vraag: kan het niet op een andere manier dan met javascript? Wat als de browser nu geen javascript ondersteund?

[André]

Verwijderd schreef op 18 oktober 2004 @ 20:15:
Tuurlijk, srry. Zal aan het feit liggen dat ik nu al 13,5 uur aan het werk ben

Toch rest mij een vraag: kan het niet op een andere manier dan met javascript? Wat als de browser nu geen javascript ondersteund?

SSL is dan een mogelijkheid of anders Flash.

[crisp]

Verwijderd schreef op 18 oktober 2004 @ 20:15:
Tuurlijk, srry. Zal aan het feit liggen dat ik nu al 13,5 uur aan het werk ben

Toch rest mij een vraag: kan het niet op een andere manier dan met javascript? Wat als de browser nu geen javascript ondersteund?

Dan geef je ze de optie om zonder versleuteling in te loggen; zie bijvoorbeeld http://gathering.tweakers.net/forum/login

[Verwijderd]

iemand anders toevallig nog een simpel doch doeltreffend en secure voorbeeld script liggen? Mijn denkvermogen laat me nu toch echt in de steek. Stuur al te lang naar het scherm.

[JHS]

Verwijderd schreef op 18 oktober 2004 @ 20:19:
iemand anders toevallig nog een simpel doch doeltreffend en secure voorbeeld script liggen? Mijn denkvermogen laat me nu toch echt in de steek. Stuur al te lang naar het scherm.

_{Neem dan even pauze en ga morgen weer verder}

www.hotscripts.com heeft bijvoorbeeld een hele lading scipts, vast ook wel op dit vlak

[crisp]

Hoe moeilijk is het om eens te kijken hoe wij dat hier geimplementeerd hebben? In feite heb ik daarmee al aan je scriptrequest (want dat is het nu) al voldaan...