paswoord zichtbaar in adres balk

[Verwijderd]

Probleempje,
Ik heb een site waar een inlog op zit, probleem is nu dat als de gegevens verstuurd worden er doodleuk in de adresbalk paswoord=$paswoord_waarde komt te staan.

Hoe kan je dit oplossen/encoden?

[danslo]

Niet doorgeven in GET maar in POST. (excuse me if I'm wrong, beetje een n00b edit (in P&W dus))

[ Voor 14% gewijzigd door danslo op 29-09-2003 19:10 ]

[Verwijderd]

Dan moet je geen html maar php gebruiken (of via mysql)

[André]

in het formulier de action op post zetten ipv get. En als het niet jouw site is dan kun je er verder niets aan doen.

Verwijderd schreef op 29 September 2003 @ 19:10:
Dan moet je geen html maar php gebruiken (of via mysql)

met php kun je clientside niets. php spuugt alleen maar html uit.

[ Voor 51% gewijzigd door André op 29-09-2003 19:11 ]

[Verwijderd]

Idd, nu geef je de variabele d.m.v de url door.
Dit zul je doen met een GET of een gewone url.
Zet alles even in een formulier en gebruik method=POST.

[Verwijderd]

:-) hmm net 3 uur in encodatie tutorials zitten bladeren en blijkt method=post gewoon te werken. Thanx

[Wirf]

maar nu gaat het nog steeds in clear-text over het internet, dat betekent dat iedereen tussen de eind gebruiker en de server dat passwoord kan lezen, meestal zijn die providers wel te vertrouwen, maar ook providers kunnen gehackt worden door mensen die niet te vertrouwen zijn.

De oplossing? https of een andere vorm van encryptie gebruiken

edit:
Hangt wel een beetje af van wat je maakt, soms (vaak) is het overkill om encryptie te gebruiken, maar als je dingen aan het maken bent die geld kunnen kosten als de passwoorden bekend zijn, dan moet je het zeker doen

[ Voor 27% gewijzigd door Wirf op 29-09-2003 19:27 ]

[André]

https is eigenlijk de enige oplossing, clientside encryptie is eigenlijk zinloos.

[Verwijderd]

'Clientside encryptie' hoeft niet zinloos te zijn:

Voor het inloggen kan de volgende procedure plaatsvinden:

- gebruiker gaat naar inlogpagina

+ Het php-script genereerd een random string en stuurt deze mee met de pagina

- Gebruiker voert gebruikersnaam en wachtwoord in
- javascript plakt het ingevoerde wachtwoord en de random string aan elkaar en stuurt de MD5-hash hiervan naar de server tijdens het submitten (POST/GET) van het form

+ De server vergelijkt de hash van de gebruiker met een hash die hij zelf heeft gemaakt van de random-string en het uit het database verkregen wachtwoord (php). Als beide hashes gelijk waren klopte het ingevoerde wachtwoord.

[André]

Als het verkeer met paswoord onderschept kan worden kan ook die php-random-string onderschept worden en is het puur een kwestie van decrypten. Dus toch zinloos zonder https.

[Verwijderd]

André schreef op 29 September 2003 @ 19:42:
Als het verkeer met paswoord onderschept kan worden kan ook die php-random-string onderschept worden en is het puur een kwestie van decrypten. Dus toch zinloos zonder https.

een md5 hash is niet te decrypten, is eigenlijk ook geen encryptie.
Maarja, het is te onderscheppen en je kunt dus op een sessie inbreken. (man in the middle)

[Verwijderd]

Verwijderd schreef op 29 September 2003 @ 19:55:
[...]

een md5 hash is niet te decrypten, is eigenlijk ook geen encryptie.
Maarja, het is te onderscheppen en je kunt dus op een sessie inbreken. (man in the middle)

ligt eraan wat voor sessie's je gebruikt e.d. het is ook geen gek idee om een sessie aan een ip te koppelen, want hoe vaak wijzigt je wachtwoord tijdens een sessie?

[André]

Verwijderd schreef op 29 September 2003 @ 19:55:
[...]

een md5 hash is niet te decrypten, is eigenlijk ook geen encryptie.
Maarja, het is te onderscheppen en je kunt dus op een sessie inbreken. (man in the middle)

Waarom is die niet te decrypten? Hoe word op de server dan gecontroleerd of het paswoord klopt?

[gorgi_19]

André schreef op 29 September 2003 @ 19:59:
[...]

Waarom is die niet te decrypten? Hoe word op de server dan gecontroleerd of het paswoord klopt?

Door de gehashde versie te vergelijken met de gehashde code, welke opgeslagen is in een database.

Een MD5-hash is per definitie 32 karakters lang en nooit terug te herleiden via een formule.

Zo kan in theorie het wachtwoord : "kip" dezelfde hash opleveren als "ei". Alleen door middel van brute force kan je dus een wachtwoord achterhalen.

[ Voor 21% gewijzigd door gorgi_19 op 29-09-2003 20:03 ]

[Verwijderd]

André schreef op 29 September 2003 @ 19:59:
[...]

Waarom is die niet te decrypten? Hoe word op de server dan gecontroleerd of het paswoord klopt?

2 strings vergelijken.
md5 doet niets meer dan een 32 karakters lange string berekenen van een andere string.
Hiermee neemt hij ook dingen als lengte e.d. mee.
Aangezien er een vaste string van 32 karakters uit komt, is het dus mogelijk dat meerdere strings dezelfde hash opleveren.
Hierdoor is het dus nooit terug te halen.

edit:

Ben net te laat zie ik

[ Voor 5% gewijzigd door Verwijderd op 29-09-2003 20:04 ]

[supakeen]

Verwijderd schreef op 29 September 2003 @ 19:55:
[...]

een md5 hash is niet te decrypten, is eigenlijk ook geen encryptie.
Maarja, het is te onderscheppen en je kunt dus op een sessie inbreken. (man in the middle)

Het is niet te onderscheppen want die string die meegestuurd word door PHP is eenmalig en javascript voegt die samen. Zo kun je dus maar eenmalig inloggen en dat is als password+string correct zijn. Daarna is het waardeloos.

Onderscheppen heeft dus geen zin hier

[crisp]

challenge en response heet dat, en is inderdaad een goede beveiliging

[Not Pingu]

gorgi_19 schreef op 29 september 2003 @ 20:02:
[...]

Door de gehashde versie te vergelijken met de gehashde code, welke opgeslagen is in een database.

Een MD5-hash is per definitie 32 karakters lang en nooit terug te herleiden via een formule.

Zo kan in theorie het wachtwoord : "kip" dezelfde hash opleveren als "ei". Alleen door middel van brute force kan je dus een wachtwoord achterhalen.

maar in dat geval maakt het geen fuk uit of je nou 'kip' of 'ei' intikt als password, de hash zal overeenkomen met die in de DB en dus krijg je toegang. Zodra je een MD5 hash kunt terugleiden naar iets wat het geweest zou kunnen zijn, heb je al bingo.

[Verwijderd]

Gunp01nt schreef op 29 september 2003 @ 20:13:
[...]


maar in dat geval maakt het geen fuk uit of je nou 'kip' of 'ei' intikt als password, de hash zal overeenkomen met die in de DB en dus krijg je toegang. Zodra je een MD5 hash kunt terugleiden naar iets wat het geweest zou kunnen zijn, heb je al bingo.

mja, er zijn 36^32 mogelijkheden, dat zijn er dus:
6,3340286662973277706162286946812e+49

Ga daar maar eens 2 strings zoeken die dezelfde hash produceren.

crisp schreef op 29 september 2003 @ 20:07:
challenge en response heet dat, en is inderdaad een goede beveiliging

challenge en response werkt idd vrij veilig, maar niet als het niet over een beveiligde verbinding gaat.
Anders kan iemand die de eenmalige string onderschept deze net zo "makkelijk" gebruiken.
Maar het is idd de beste oplossing op ssl na

[ Voor 7% gewijzigd door Verwijderd op 29-09-2003 20:18 ]

[Wirf]

André schreef op 29 September 2003 @ 19:28:
https is eigenlijk de enige oplossing, clientside encryptie is eigenlijk zinloos.

uuh... https is ook client-side hoor

_{en natuurlijk ook een gedeelte op de server, maar das logisch}