Variabelen URL meenemen in form + body onload submit - Softwareontwikkeling

woensdag 24 januari 2007 15:25

Acties:

Verwijderd

Topicstarter

In opvolging tot mijn eerdere topic over hoe ik een formulier automatisch kan submitten, gebruik ik een onderstaand script dat in die oplossing werkt.

Wat ik nu probeer is de waarden voor "user" en "password" mee te geven in de URL wat in dit geval niet lukt op een of andere manier.

I heb het op verschillende manier geprobeerd, met echo en nog wat zaken, maar dit wil gewoon niet.

Als ik de user en pass gewoon invul werkt dit perfect, ik ben dus bang dat de "onload" al gedaan wordt voordat de variabelen uit de URL zijn gevist en in de form zijn geinclude.

Ik ben hier wet wat Javascripts tegengekomen op het forum, maar ik vraag me sterk af waarom ik het wel werkend kon krijgen wanneer ik een META-refresh van 0 in een 2e HTML pagina doe, met de waarden in de URL die ik daar opgeef.

Oftewel, direct vanuit de explorer balk werkt niet, maar vanuit een andere HTML-pagina wel.

code:

<html>

<head>

</head>

<body onload="document.login.submit()">

<form name="login" action="http://host.waar.ik.heen.wil.posten/pagina.html" method="POST">
<input type="hidden" name="actie" value="login">
<input type="hidden" name="login" value="${user}">
<input type="hidden" name="password" value="${password}">
</form>

</body>

</HTML>

Nu is vraag 2:

Aangezien het niet veilig is je username en je password zo maar in een URL te plaatsen om deze in MD5 erin te zetten en in plaintext te posten ?

Ik zal het dus ergens moeten converteren van MD5 naar plaintext voorday ik post, iets wat me niet mogelijk leek. MD5 was toch niet (makkelijk) te ontrafelen ?

Wachtwoorden opslaan in MD5 is veel beter maar kan helaas niet, dus zoek ik een workaround.

woensdag 24 januari 2007 15:30

Acties:

mithras

Ik snap helemaal niet wat je wil eigenlijk. Sowieso kan je md5->plaintext conversie niet (of: niet voor jouw systeem) doen. Bij mij komt wel de vraag op waarom je iemand automatisch wil laten inloggen; zegmaar info uit database halen en vervolgens met die info controleren of je database gegevens klopt en dan inloggen

Maar goed: inderdaad zal nu waarschijnlijk de onload eerder plaatsvinden dan het invullen van username en password. Want dat doe je ook met javascript?
Als je namelijk met bijv een server-side taal de username en wachtwoord invult kan dit probleem niet optreden.

Dus eigenlijk eerst de vraag: wanneer stop je de username en wachtwoord in je html? Serverside met php (omdat je ook $ gebruikt denk ik dat) of met javascript?

woensdag 24 januari 2007 15:37

Acties:

Verwijderd

Topicstarter

mithras schreef op woensdag 24 januari 2007 @ 15:30:
Ik snap helemaal niet wat je wil eigenlijk. Sowieso kan je md5->plaintext conversie niet (of: niet voor jouw systeem) doen. Bij mij komt wel de vraag op waarom je iemand automatisch wil laten inloggen; zegmaar info uit database halen en vervolgens met die info controleren of je database gegevens klopt en dan inloggen

Ik kan geen autologin gebruiken op dit stuk helaas. Ik kan wel een form posten en dit dus met een URL doen die ik in de favorieten zet.

Veilig is anders, maarja het kan even niet anders

Vandaar de MD5-> plaintext conversie.

Maar goed: inderdaad zal nu waarschijnlijk de onload eerder plaatsvinden dan het invullen van username en password. Want dat doe je ook met javascript?
Als je namelijk met bijv een server-side taal de username en wachtwoord invult kan dit probleem niet optreden.

Ik typ het nu gewoon in de adresbalk in:

login.php?username=USER&password=PASS

Dus eigenlijk eerst de vraag: wanneer stop je de username en wachtwoord in je html? Serverside met php (omdat je ook $ gebruikt denk ik dat) of met javascript?

Ik stop het dus op het verkeerde moment in de HTML.

Zoals je zelf al aangeeft, ik zou denk ik Javascript moeten gebruiken, het is nu een simpele php-pagina.

woensdag 24 januari 2007 15:46

Acties:

mithras

Verwijderd schreef op woensdag 24 januari 2007 @ 15:37:
[...]

Ik typ het nu gewoon in de adresbalk in:

login.php?username=USER&password=PASS

En dit werkt dus goed

[...]

Ik stop het dus op het verkeerde moment in de HTML.

Wat bedoel je daarmee?

Zoals je zelf al aangeeft, ik zou denk ik Javascript moeten gebruiken, het is nu een simpele php-pagina.

Nee, het is juist makkelijker om met php de html pagina op te bouwen. Als je met javascript de gebruikersnaam en wachtwoord in gaat vullen kunnen er _juist_ problemen ontstaan

Wat is er mis met zoiets:

PHP:

$username = "pietje puk";
$password = "123abc098";
echo '<html>
<body onload="document.login.submit()">
<form name="login" action="http://host.waar.ik.heen.wil.posten/pagina.html" method="POST">
<input type="hidden" name="actie" value="login">
<input type="hidden" name="login" value="'.$username.'">
<input type="hidden" name="password" value="'.$password.'">
</form>
</body>
</html>';

Dit is namelijk vrij basic php kennis

woensdag 24 januari 2007 16:29

Acties:

Verwijderd

Topicstarter

Inderdaad, Basic PHP.... om 4 uur 's nachts werken mijn basics niet altijd meer zo goed

Het is foutgegaan bij de PUNT die ik miste bij username en password ben ik bang.

Het werkt nu prima ! Daar is dit forum nu zo handig voor, feedback na je probeersel

dinsdag 4 december 2007 03:04

Acties:

Verwijderd

Topicstarter

Dit is welliswaar een heel oud topic, maar omdat hij van mijzelf is mag ik aannemen dat ik niet een volledig nieuw topic aan hoef te maken ? Lijkt me zonde namelijk.

mithras schreef op woensdag 24 januari 2007 @ 15:46:

Wat is er mis met zoiets:

PHP:

$username = "pietje puk";
$password = "123abc098";
echo '<html>
<body onload="document.login.submit()">
<form name="login" action="http://host.waar.ik.heen.wil.posten/pagina.html" method="POST">
<input type="hidden" name="actie" value="login">
<input type="hidden" name="login" value="'.$username.'">
<input type="hidden" name="password" value="'.$password.'">
</form>
</body>
</html>';

Dit is namelijk vrij basic php kennis

Ik ben nog steeds van mening dat iemand dit script kan stoppen op een of andere manier en het wachwoord dus zo uit de bron kan lezen.

De vraag is hoe je dit anders op zou kunnen lossen, ik denk dat dat niet mogelijk is aangezien je toch het wachtwoord ergens moet "typen".

dinsdag 4 december 2007 08:47

Acties:

Raynman

Verwijderd schreef op dinsdag 04 december 2007 @ 03:04:
[...]

Ik ben nog steeds van mening dat iemand dit script kan stoppen op een of andere manier en het wachwoord dus zo uit de bron kan lezen.

Als je javascript uitzet, kan dat makkelijk inderdaad.

Maar je idee was toch om user+pass via GET mee te geven om een soort van makkelijke inlogmethode te maken. Dan zou dus alleen degene van wie het password is, dat ook kunnen bekijken.
GET gebruiken voor inloggen is natuurlijk gewoon helemaal niet handig. Je had het ergens over het opslaan van die URL in Favorieten; dan kan iedereen die bij die Favorieten kan ook achter het wachtwoord komen.

Als je toch iets met een autologin wilt, kun je dan niet beter een sessie met een bepaalde levensduur maken (cookie+entry in db). Daarbij kun je dan het IP opslaan in je database. Vergelijk het maar met GoT.

dinsdag 4 december 2007 11:22

Acties:

ATS

Als het via de client gaat, is het inderdaad kinderspel om die data op te pikken. Het password staat gewoon plaintext in de source van je pagina!
Als ik je goed begrijp, dan wil je eigenlijk een soort cross-site login maken, klopt dat? Nou, daar zijn natuurlijk standaard methoden voor, maar je kan ook zelf wat bakken. Probleem is wel dat je over beide servers controle moet hebben. Als dat het geval is, dan kan je een one-time key systeem maken:

Client vraagt jouw pagina op van server A
Je server A legt contact met de andere server B, geeft login en IP van client door
server B controleert login en genereert one-time key op basis van die login en het IP van de client
server B geeft die one-time key terug aan server A
server A gebruikt de verkregen one-time key in het form en geeft het resultaat aan client
client submit form naar server B met daarin de one-time key
server B controleert key op basis van IP adres en tijd.

Op deze manier komt het password enzo nooit bij de client terecht, en kan hij het dus ook niet onderscheppen. Maargoed, je server B moet dit wel kunnen. Is niet moeilijk of veel code, maar enige controle heb je wel nodig.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

dinsdag 4 december 2007 12:08

Acties:

Verwijderd

Topicstarter

Ja het idee is een crosssite login.

Alleen, laat ik het volgende stellen.

Iemand is al ingelogd op zijn account, via hidden forms in een script +submit door javascript laat je iemand weer inloggen op een andere applicatie die ook van hem is.

Eigenlijk bespaar je de persoon dus zijn gegevens intypen, dat is het enige.

De vraag is hoe insecure dit is over SSL ?

Iemand die javascript uit zet en zijn blanco pagina open laat staan heeft natuurlijk een probleem als iemand zo handig is om eens de bron van die pagina te bekijken als de persoon in kwestie naar het toilet is.

Maar hoe zou je dat anders willen doen ?

Neem als voorbeeld ene centrale login voor hosting waar je met een klik op de knop in kan loggen op je webmail of je phpmyadmin.

Is die verzonden data nog ergens uit te peuteren ? Leek me niet verder.

dinsdag 4 december 2007 12:24

Acties:

Verwijderd

vergeet niet dat je voor een veilige (secured) https:// geld moet betalen

(licentie)

Dan zou ik eerder een wat veiliger systeempje bouwen (aka -> gratis) dan zo'n licentie te betalen

dinsdag 4 december 2007 12:27

Acties:

Verwijderd

Topicstarter

Verwijderd schreef op dinsdag 04 december 2007 @ 12:24:
vergeet niet dat je voor een veilige (secured) https:// geld moet betalen (licentie)

Dan zou ik eerder een wat veiliger systeempje bouwen (aka -> gratis) dan zo'n licentie te betalen

Het certificaat is er toch al, ik bedoel, laat jij mensen inloggen over onbeveiligde verbindingen dan ?

dinsdag 4 december 2007 12:42

Acties:

sopsop

[v] [;,,;] [v]

Verwijderd schreef op woensdag 24 januari 2007 @ 15:37:
[...]
Veilig is anders, maarja het kan even niet anders Vandaar de MD5-> plaintext conversie.
[...]

Je weet dat md5 geen encryptie is, maar hashing? Big difference namelijk. Voor het doel dat jij hier probeert te bereiken is MD5 of hashing in het algemeen niet de geschikte methode.

dinsdag 4 december 2007 13:09

Acties:

Equator

Crew Council

#whisky #barista

Verwijderd schreef op dinsdag 04 december 2007 @ 12:08:
Ja het idee is een crosssite login.

Alleen, laat ik het volgende stellen.

Iemand is al ingelogd op zijn account, via hidden forms in een script +submit door javascript laat je iemand weer inloggen op een andere applicatie die ook van hem is.

Eigenlijk bespaar je de persoon dus zijn gegevens intypen, dat is het enige.

De vraag is hoe insecure dit is over SSL ?

Iemand die javascript uit zet en zijn blanco pagina open laat staan heeft natuurlijk een probleem als iemand zo handig is om eens de bron van die pagina te bekijken als de persoon in kwestie naar het toilet is.

Maar hoe zou je dat anders willen doen ?

Neem als voorbeeld ene centrale login voor hosting waar je met een klik op de knop in kan loggen op je webmail of je phpmyadmin.

Is die verzonden data nog ergens uit te peuteren ? Leek me niet verder.

Als je bij het inloggen op de eerste website de gegevens (serverside) gebruikt om in teloggen op website 2 en daar een session-id laat genereren die gekoppeld is aan het IP van de gebruiker, en met het e.e.a aan hashing.

Deze session ID gebruik je dan achter de link om vanuit je ene website naar de 2e website te browsen. De website 2 ziet aan de URL dat je een session ID hebt, en controleerd of dit session ID bestaat i.c.m. de opgeslagen IP adres en eventueel andere zaken.

Zo ja, dan ben je aangemeld, en anders niet.

Je zou daar ook nog een maximale leeftijd van de session ID's aan kunnen koppelen

Met een SOAP kan je op website1 bij website 2 'aanmelden' en de ssession-id terug krijgen. Mits je dat verkeer afschermt met behulp van SSL is dat vrij veilig.

SSL vanaf de client naar server helpt alleen om het verkeer af te schermen tegen afluisteren. De gegevens die je in de html code (hidden input) plaatst kan je gewoon lezen als je de bron kan bekijken. (mits je toegang hebt tot de browser natuurlijk)

Kan je daar iets mee?

Verwijderd schreef op dinsdag 04 december 2007 @ 12:24:
vergeet niet dat je voor een veilige (secured) https:// geld moet betalen (licentie)

Niet per definitie. Een SSL certificaat kan je prima maken, probleem is dan dat het getekend wordt door een niet bekende RootCA waardoor je op de browser een melding krijgt.
Wil je dat niet, dan betaal je een bepaald bedrag per jaar voor een certificaat.
Dit is overigens niet een licentie, maar gewoon een (meer)jaarlijks terugkerend bedrag voor de administratiekosten.

Dan zou ik eerder een wat veiliger systeempje bouwen (aka -> gratis) dan zo'n licentie te betalen

Het is appels met peren vergelijken. SSL is transport beveiliging. Hashen / encrypten van password's etc. is op application (server) level.

sopsop schreef op dinsdag 04 december 2007 @ 12:42:
[...]

Je weet dat md5 geen encryptie is, maar hashing? Big difference namelijk. Voor het doel dat jij hier probeert te bereiken is MD5 of hashing in het algemeen niet de geschikte methode.

de PEAR modules bevatten een optie om te versleutelen. Dus echte synchrone encryptie waarmee je de key nodig hebt om het te decrypten.

dinsdag 4 december 2007 13:18

Acties:

Verwijderd

Topicstarter

Equator schreef op dinsdag 04 december 2007 @ 13:09:
[...]

Kan je daar iets mee?

Jazeker !

Het probleem is alleen dat ik geen grip heb op de code van enkele applicaties, dus ik zal een loginform moeten gebruiken welke ik submit.

Zolang de gebruiker dit zelf submit na inloggen op site 1 is er weinig aan de hand, maar we heeft die garantie.

Afluisteren moet niet mogelijk zijn, SSL is dus ideaal hier, verder denk ik dat plaintext een issue blijft.

Wanneer ik hier op tweakers inlog, wordt mij pass uiteindelijk ook plaintext verstuurd als ik op "inloggen" druk ?

De stipjes die je ziet als je aan het typen bent zijn toch maar HTML gegenereerd.

dinsdag 4 december 2007 13:33

Acties:

Equator

Crew Council

#whisky #barista

Wanneer ik hier op tweakers inlog, wordt mij pass uiteindelijk ook plaintext verstuurd als ik op "inloggen" druk ?

Nope: Standaard staat de optie "versleutel mijn wachtwoord" aan, via javascript wordt het wachtwoord gehashed (met een salt), en verstuurd.
Inweze controleer je ook of de hash overeenkomt met de waarde in de database..

dinsdag 4 december 2007 14:23

Acties:

Verwijderd

Topicstarter

Dat is natuurlijk ook mogelijk, je hashed de pass en vergelijkt hem weer.

Dat is een goede oplossing

Dank je !

Ik dacht hier geheel langs heen eigenlijk... ik gebruik het zelf ook

[ Voor 24% gewijzigd door Verwijderd op 04-12-2007 14:24 ]

dinsdag 4 december 2007 15:34

Acties:

Verwijderd

Toevallig ben ik hier op dit moment ook mee bezig.

Om even terug te vallen op Equator: Ik gebruik liever geen Javascript, maar ben op zoek naar een manier om een wachtwoord die ingetypt wordt in een html form als md5-hash te versturen. Ik heb alleen geen idee hoe ik hier tussen de user-input en de 'post' kom met PHP.

dinsdag 4 december 2007 15:39

Acties:

Mister_X

Equator schreef op dinsdag 04 december 2007 @ 13:33:
[...]

Nope: Standaard staat de optie "versleutel mijn wachtwoord" aan, via javascript wordt het wachtwoord gehashed (met een salt), en verstuurd.
Inweze controleer je ook of de hash overeenkomt met de waarde in de database..

grappig, dus het password staat nergens plain opgeslagen (server side) ?

Heb je ergens een tutorial hoe dat ongeveer in zijn werk gaat?

(gokje:
password invullen, onsubmit, hash js script, post, hash word in db gecontrolleerd of combo; user en hash, overeen komen).

dinsdag 4 december 2007 15:51

Acties:

Equator

Crew Council

#whisky #barista

Dat is gewoon standaard IMO.
Je wilt toch niet het plaintext wachtwoord in de database hebben staan. Dus plaats je een hash (sha1 / md5) met een bepaalde salt in de database.

Wanneer een gebruiker zijn gegevens invult pak je het wachtwoord samen met de salt (die server-side bekend is natuurlijk) en hiervan bereken je een hash-waarde. Deze controleer je in combinatie met de username in de database.

Wil je dit hashen doen voordat je het html form verstuurd, dan zal je dat met javascript moeten doen. Nadeel lijkt me dat dit javascript op te vragen is door de client, dus zou een eventuele salt opgevraagd kunnen worden. (tenzij je een include kan doen in JS die een stukje script include die buiten de web-root staat)

dinsdag 4 december 2007 15:57

Acties:

Verwijderd

Mister_X schreef op dinsdag 04 december 2007 @ 15:39:
[...]

grappig, dus het password staat nergens plain opgeslagen (server side) ?

Heb je ergens een tutorial hoe dat ongeveer in zijn werk gaat?

(gokje:
password invullen, onsubmit, hash js script, post, hash word in db gecontrolleerd of combo; user en hash, overeen komen).

Het gaat in het kort op een eenvoudige manier zo in z'n werk:

Wachtwoord wordt bijvoorbeeld opgegeven als 1234abcd.
De MD5-hash hiervan is ef73781effc5774100f87fe2f437a435. Deze wordt opgeslagen.

Als er iemand gaat inloggen, typt deze een wachtwoord in. Van dit wachtwoord wordt ook een MD5-hash gemaakt. Vervolgens wordt er gekeken of de hash van de invoer overeenkomt met de opgeslagen hash. Als dat het geval is, dan ben mag je inloggen. Als dat niet het geval is krijg je een foutmelding.

Aangezien hashes éénzijdig werken (bruteforce daargelaten), is het niet erg als iemand een hash onder ogen krijgt. Inloggen is nog steeds practisch onmogelijk.

dinsdag 4 december 2007 16:01

Acties:

Mister_X

Verwijderd schreef op dinsdag 04 december 2007 @ 15:57:
[...]

Het gaat in het kort op een eenvoudige manier zo in z'n werk:

Wachtwoord wordt bijvoorbeeld opgegeven als 1234abcd.
De MD5-hash hiervan is ef73781effc5774100f87fe2f437a435. Deze wordt opgeslagen.

Als er iemand gaat inloggen, typt deze een wachtwoord in. Van dit wachtwoord wordt ook een MD5-hash gemaakt. Vervolgens wordt er gekeken of de hash van de invoer overeenkomt met de opgeslagen hash. Als dat het geval is, dan ben mag je inloggen. Als dat niet het geval is krijg je een foutmelding.

Aangezien hashes éénzijdig werken (bruteforce daargelaten), is het niet erg als iemand een hash onder ogen krijgt. Inloggen is nog steeds practisch onmogelijk.

dus de hash word client side door een js functie gemaakt, (ben niet weg in js, gaat me ook niet om code maar om methode) bij onsubmit. Bij het 'registeren' word datzelfde gedaan en die hash word als password opgeslagen ipv 1234abcd...

klinkt vrij eenvoudig, ik ga even brainstormen, ook over die salt.

dinsdag 4 december 2007 16:11

Acties:

Verwijderd

Topicstarter

Equator schreef op dinsdag 04 december 2007 @ 15:51:
Dat is gewoon standaard IMO.
Je wilt toch niet het plaintext wachtwoord in de database hebben staan.

Opzich is dit niet het grootste probleem, je wil ze alleen niet zien in scripts, dus de bron. Serverside is niet echt een issue wanneer de applicatie goed is.

Zijn jouw mailwachtwoorden dan ook gehashed

In vele gevallen niet namelijk.

Iedere website die passwords zo kan versturen als reminder heeft ze plaintext, en dat is voor veel mensen makkelijker dan de manier waarop tweakers een nieuw wachtwoord genereert, echter kan tweakers niet anders omdat ze het wachtwoord niet kunnen raden

@tygetjuh; Ik zoek ook een manier "daar" tussen te komen, kom er niet echt uit op dit moment. Wellicht dat ik het licht nog ga zien vandaag

[ Voor 12% gewijzigd door Verwijderd op 04-12-2007 16:12 ]

dinsdag 4 december 2007 16:16

Acties:

Mister_X

@tygetjuh en RutgerM

dat kan niet zonder JS (client side!). denk toch dat je met http://pajhome.org.uk/crypt/md5/ zoiets zal moeten werken denk ik.

Maar dat lijkt me dan weer reverse engineer baar, misschien iets via https ??

http://forum.java.sun.com...5160737&messageID=9625484

[ Voor 14% gewijzigd door Mister_X op 04-12-2007 16:17 ]

dinsdag 4 december 2007 16:29

Acties:

Verwijderd

Momenteel verstuur ik de wachtwoorden plain met html 'post', maar liever zou ik een oplossing voor handen gehad hebben om het wachtwoord nog vóór het posten te hashen, zodat er helemaal geen plain wachtwoorden verstuurd hoeven te worden.

Met PHP is dit bij nader inzien technisch niet mogelijk. PHP is namelijk serverside. Als een client een wachtwoord intypt, moet het eerst verzonden worden naar de server, voordat PHP het onder handen kan nemen. De enige twee oplossingen zijn dus clientside hashen of een beveiligde verbinding.

@Mister_X:
Waarom denk je dat een met JS gehashte tekst reverse engineerbaar is? Het idee achter een hash is dat het juist NIET reverse engineerbaar is.

dinsdag 4 december 2007 18:13

Acties:

Equator

Crew Council

#whisky #barista

hashen is inweze niet reversable. Omdat het geen encryptie is, maar een berekening van een string. De uitkomst kan gelijk zijn met de hash van een willekeurig andere string (hash collisions)

het enige wat je kan doen is een hashwaarde door een zogeheten rainbow table halen om te kijken of je de plaintekst kan vinden. Het gebruik van een random salt (en dan bedoel ik iets van U@ENCUWRJOWHD*UAQWRH#QRHVohakjdhoiqsaudf9auslfhkahf) zorgt ervoor dat je wachtwoord nog steeds niet bekend is.

dinsdag 4 december 2007 19:15

Acties:

Mister_X

Verwijderd schreef op dinsdag 04 december 2007 @ 16:29:
Momenteel verstuur ik de wachtwoorden plain met html 'post', maar liever zou ik een oplossing voor handen gehad hebben om het wachtwoord nog vóór het posten te hashen, zodat er helemaal geen plain wachtwoorden verstuurd hoeven te worden.

Met PHP is dit bij nader inzien technisch niet mogelijk. PHP is namelijk serverside. Als een client een wachtwoord intypt, moet het eerst verzonden worden naar de server, voordat PHP het onder handen kan nemen. De enige twee oplossingen zijn dus clientside hashen of een beveiligde verbinding.

@Mister_X:
Waarom denk je dat een met JS gehashte tekst reverse engineerbaar is? Het idee achter een hash is dat het juist NIET reverse engineerbaar is.

Omdat je de js code kan achterhalen en dus kan zien hoe de hash werkt, immers is er geen js functie zoals in php.

dinsdag 4 december 2007 19:57

Acties:

ATS

Dus? Het algoritme van een MD5, maar ook van betere hash functies zijn gewoon tot in detail bekend. Daarom zijn er ook implementaties in elke willekeurige taal. Dat wil nog niet zeggen dat je met behulp van dat algoritme uit de hash kan berekenen wat de plaintext was! Het hele idee van een hashfunctie is juist dat hij niet om te draaien, maar wel reproduceerbaar is. Je kan ook prima veilig een goede salt open en bloot meesturen in je javascript, omdat rainbowtables (die je kan gebruiken om aan de hand van een bekende hash een daarbij bekende plaintext op te zoeken) maar een beperkte set aan plaintexts hebben. Weinig kans dat ze die plaintext in combinatie met jouw goed lange en vooral random salt hebben (al kán het natuurlijk gebeuren...).

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

dinsdag 4 december 2007 21:02

Acties:

T-MOB

Verwijderd schreef op dinsdag 04 december 2007 @ 16:29:
Momenteel verstuur ik de wachtwoorden plain met html 'post', maar liever zou ik een oplossing voor handen gehad hebben om het wachtwoord nog vóór het posten te hashen, zodat er helemaal geen plain wachtwoorden verstuurd hoeven te worden.

Wanneer je de wachtwoorden voor het posten hashed beveilig je nog niets, je voorkomt er alleen mee dat degene die afluistert ook het letterlijke wachtwoord weet. Verder kan de aanvaller - net als de gebruiker - de hash naar je server sturen om in te loggen.

Waar je naar opzoek bent is waarschijnlijk challenge response. Het idee is vrij simpel:

Je start serverside een sessie, hierin sla je een random code op.
Je geeft de code aan de client
Clientside hash je wachtwoord + code, dit verstuur je naar server om in te loggen
Serverside haal je wachtwoord uit de database, dit hash je met de code uit de sessie
komt de hash overeen met de ontvangen waarde dan was het wachtwoord correct

Het random token zorgt hier voor de beveiliging. Iemand die de lijn afluistert kan niet met dezelfde gegevens inloggen.

Wanneer je serverside gehashte passwords opslaat dan kun je het principe ook toepassen, je moet dan het wachtwoord aan de clientside twee keer hashen. Een keer met de salt die je serverside gebruikt en een keer met het random token.

Regeren is vooruitschuiven

woensdag 5 december 2007 14:42

Acties:

Mister_X

ATS schreef op dinsdag 04 december 2007 @ 19:57:
Dus? Het algoritme van een MD5, maar ook van betere hash functies zijn gewoon tot in detail bekend. Daarom zijn er ook implementaties in elke willekeurige taal. Dat wil nog niet zeggen dat je met behulp van dat algoritme uit de hash kan berekenen wat de plaintext was! Het hele idee van een hashfunctie is juist dat hij niet om te draaien, maar wel reproduceerbaar is. Je kan ook prima veilig een goede salt open en bloot meesturen in je javascript, omdat rainbowtables (die je kan gebruiken om aan de hand van een bekende hash een daarbij bekende plaintext op te zoeken) maar een beperkte set aan plaintexts hebben. Weinig kans dat ze die plaintext in combinatie met jouw goed lange en vooral random salt hebben (al kán het natuurlijk gebeuren...).

ok ok, zat nog even te denken, maar het js md5'en slaat ook nergens op , immers kun je gewoon die hash uit de post halen en tegen de db aangooien, of je nou een plain wachtwoord eruit vist, of de hash, het is allebei 'het wachtwoord' in combo met de username.

Dat van die salt is 'de' enige veilige oplossing denk ik.

edit:
T-MOB was me voor

, maar psies wat hij zegt kwam ik ook achter

[ Voor 7% gewijzigd door Mister_X op 05-12-2007 14:43 ]

woensdag 5 december 2007 14:57

Acties:

Verwijderd

Topicstarter

Mister_X schreef op woensdag 05 december 2007 @ 14:42:
[...]

ok ok, zat nog even te denken, maar het js md5'en slaat ook nergens op , immers kun je gewoon die hash uit de post halen en tegen de db aangooien, of je nou een plain wachtwoord eruit vist, of de hash, het is allebei 'het wachtwoord' in combo met de username.

Dat van die salt is 'de' enige veilige oplossing denk ik.

edit:
T-MOB was me voor , maar psies wat hij zegt kwam ik ook achter

Dat is niet waar.

Stel jij hebt plaintext je PW in je DB staan dan kun je hem aan de kant waar hij plaintext staat eerst MD5-en en dan vergelijken.

Is de vergelijking goed, dan run je een login script, anders niet.

woensdag 5 december 2007 15:40

Acties:

Mister_X

zoals je zegt,

dus je vult je wachtwoord in: 1234, er word client side een hash gemaakt: xxxx.

daarna de post met username & xxxx -> server haalt wachtwoord eruit, op basis van alleen 'username', het wachtwoord word ook gehased: xxxx, whalla login goed.

maar wat als ik nou de post onderschept, ik zie daar een username en xxxx voorbij gaan. Wat gebeurt er dan, denk je als ik die post faked met diezelfde gegevens?

juist, ik log er mee in.

wat wel kan:

je vult je username en passw in. username word gepost en er word een md5 hash van wachtwoord TERUG GESTUURD op basis van ALLEEN de username. De client (JS) hashed het wachtwoord en vergelijkt dat met de teruggestuurde hash CLIENT SIDE $_/-\o_$ $_/-\o_$ ..

damn dat is hem.

[ Voor 26% gewijzigd door Mister_X op 05-12-2007 15:45 ]

woensdag 5 december 2007 20:57

Acties:

T-MOB

Mister_X schreef op woensdag 05 december 2007 @ 15:40:
je vult je username en passw in. username word gepost en er word een md5 hash van wachtwoord TERUG GESTUURD op basis van ALLEEN de username. De client (JS) hashed het wachtwoord en vergelijkt dat met de teruggestuurde hash CLIENT SIDE $_/-\o_$ $_/-\o_$ ..

damn dat is hem.

En dan, stuur je bericht naar de server dat het wachtwoord klopt?

Regeren is vooruitschuiven

woensdag 5 december 2007 23:35

Acties:

Gomez12

Mister_X schreef op woensdag 05 december 2007 @ 15:40:
zoals je zegt,

dus je vult je wachtwoord in: 1234, er word client side een hash gemaakt: xxxx.

daarna de post met username & xxxx -> server haalt wachtwoord eruit, op basis van alleen 'username', het wachtwoord word ook gehased: xxxx, whalla login goed.

maar wat als ik nou de post onderschept, ik zie daar een username en xxxx voorbij gaan. Wat gebeurt er dan, denk je als ik die post faked met diezelfde gegevens?

juist, ik log er mee in.

Op deze site op dit moment ( veel sites gebruiken een dated salt ) Maar niet op een andere site omdat je de gebruiker zijn wachtwoord nog niet kent...

En het is nu eenmaal een feit dat 99% vd gebruikers geen unieke wachtwoorden per site beheert. Dus het is gewoon risico vermindering.

wat wel kan:

je vult je username en passw in. username word gepost en er word een md5 hash van wachtwoord TERUG GESTUURD op basis van ALLEEN de username. De client (JS) hashed het wachtwoord en vergelijkt dat met de teruggestuurde hash CLIENT SIDE $_/-\o_$ $_/-\o_$ ..

damn dat is hem.

Yep, en als ik dan de server programmeer log jij nooit in, want ik vertrouw geen client side data.
Jouw methode voorkomt dat iemand het wachtwoord over de lijn kan zien gaan ( hashed of niet ) maar nu kan iedere client gewoon aangeven dat het gelukt is.
Alle checks die je wilt doen moeten altijd server-side gebeuren want dat is het enige waar je controle over hebt. Client side checks zijn leuk voor de usability, maar moeten altijd over gedaan worden op de server...

Btw, een niet salted hash is tegenwoordig inderdaad redelijk te vergelijken met een plain text wachtwoord vanwege alle rainbow tabellen die rondzwerven / vast algoritme ( als ik de unsalted md5 van een wachtwoord heb kan ik bij alle sites inloggen die ook unsalted zijn want berekening is server side gelijk dus zelfde uitkomst ).
Maar salt jij het wachtwoord alleen maar met je url dan is het gelijk al niet meer bruikbaar voor andere sites, salt jij hem nog eens met het ip-adres ook, dan is hij gelijk voor 99% van alle hackers/crackers/scriptkiddies niet meer de moeite waard / bruikbaar omdat ze dan man in the middle moeten gaan spelen voor 1 site.

[ Voor 16% gewijzigd door Gomez12 op 05-12-2007 23:43 ]

donderdag 6 december 2007 00:07

Acties:

Verwijderd

Topicstarter

Mister_X schreef op woensdag 05 december 2007 @ 15:40:
zoals je zegt,

dus je vult je wachtwoord in: 1234, er word client side een hash gemaakt: xxxx.

daarna de post met username & xxxx -> server haalt wachtwoord eruit, op basis van alleen 'username', het wachtwoord word ook gehased: xxxx, whalla login goed.

maar wat als ik nou de post onderschept, ik zie daar een username en xxxx voorbij gaan. Wat gebeurt er dan, denk je als ik die post faked met diezelfde gegevens?

Ik mag aannemen dat je de user verifieert met iets in de sessie dat in beide DB's staat en niemand weet... of meerdere dingen.

Je kan dat zo complex maken

[ Voor 0% gewijzigd door Verwijderd op 06-12-2007 05:53 . Reden: typo again ]