[PHP/(My)SQL] voor dummies - Deel 23

je kunt die functies toch gewoon combineren in 1 functie?Of de ene functie de ander aan laten roepen..

onsubmit="doiets()"

function doiets()
{
doDit();
doNogIets();
}

function doDit() {}

function doNogIets() {}

quote:

Op maandag 13 maart 2006 17:02 schreef ikke_ook het volgende:
je kunt die functies toch gewoon combineren in 1 functie?Of de ene functie de ander aan laten roepen..

ja dat is natuurlijk een mogelijkheid

enne:
[Javascript] voor dummies - deel 3

En deze manier van encrypten heeft weinig zin toch?
Als iemand deze string onderschept heeft hij het wachtwoord toch helemaal niet nodig?Hij kan deze string gewoon naar de server sturen en dan is hij ook ingelogd....

@ikke_ook

Dat is inderdaad geen veilige manier van inloggen. Een veiligere manier is challenge-response, in een notendop:

1. Maak gebruik van een hashing algoritme, in dit voorbeeld even SHA1
2. De server heeft de SHA1-hash van het wachtwoord van de gebruiker in de database staan
3. Als een gebruiker wil inloggen stuurt de server een random getal mee welke de server ook opslaat in de database (tijdelijk, in een session bijvoorbeeld)
4. Als de gebruiker zijn wachtwoord heeft ingevoerd berekent hij eerst de SHA1-hash van zijn wachtwoord en vervolgens de SHA1-hash van het random getal plus de eerste hash. Dit ziet er dan zo uit:

Uiteindelijke hash = SHA1(random getal + SHA1(wachtwoord))

Dit alles gebeurt door een SHA1-functie in javascript.

5. De uiteindelijke hash stuurt de gebruiker terug naar de server. Als iemand deze hash onderschept, kan hij redelijkerwijs onmogelijk de hash omdraaien aangezien het origineel bestaat uit een string van meer dan 40 tekens (random getal + SHA1(wachtwoord)) - zelfs als hij het random getal weet.
6. De server weet het random getal en de SHA1-hash van het wachtwoord (staat in de database) en kan dus controleren of de gestuurde hash geldig is. Zo ja, dan kan de gebruiker inloggen.

Natuurlijk moet je met meer dingen rekening houden, zoals een controle op IP-adres en/of Agent-string aangezien de onderschepper ook de session ID zou kunnen stelen.

quote:

Op maandag 13 maart 2006 17:05 schreef ikke_ook het volgende:

[ code verwijderd ]

enne:
[Javascript] voor dummies - deel 3

En deze manier van encrypten heeft weinig zin toch?
Als iemand deze string onderschept heeft hij het wachtwoord toch helemaal niet nodig?Hij kan deze string gewoon naar de server sturen en dan is hij ook ingelogd....

ja richtig daar wordt nog wat op bedacht. _{webscripten is niet leuk}

quote:

Op maandag 13 maart 2006 17:21 schreef JeRa het volgende:
@ikke_ook

Dat is inderdaad geen veilige manier van inloggen. Een veiligere manier is challenge-response, in een notendop:

1. Maak gebruik van een hashing algoritme, in dit voorbeeld even SHA1
2. De server heeft de SHA1-hash van het wachtwoord van de gebruiker in de database staan
3. Als een gebruiker wil inloggen stuurt de server een random getal mee welke de server ook opslaat in de database (tijdelijk, in een session bijvoorbeeld)
4. Als de gebruiker zijn wachtwoord heeft ingevoerd berekent hij eerst de SHA1-hash van zijn wachtwoord en vervolgens de SHA1-hash van het random getal plus de eerste hash. Dit ziet er dan zo uit:

Uiteindelijke hash = SHA1(random getal + SHA1(wachtwoord))

Dit alles gebeurt door een SHA1-functie in javascript.

5. De uiteindelijke hash stuurt de gebruiker terug naar de server. Als iemand deze hash onderschept, kan hij redelijkerwijs onmogelijk de hash omdraaien aangezien het origineel bestaat uit een string van meer dan 40 tekens (random getal + SHA1(wachtwoord)) - zelfs als hij het random getal weet.
6. De server weet het random getal en de SHA1-hash van het wachtwoord (staat in de database) en kan dus controleren of de gestuurde hash geldig is. Zo ja, dan kan de gebruiker inloggen.

Natuurlijk moet je met meer dingen rekening houden, zoals een controle op IP-adres en/of Agent-string aangezien de onderschepper ook de session ID zou kunnen stelen.

ok bedankt ik ga er mee bezig!

quote:

Op maandag 13 maart 2006 17:05 schreef ikke_ook het volgende:

[ code verwijderd ]

enne:
[Javascript] voor dummies - deel 3

En deze manier van encrypten heeft weinig zin toch?
Als iemand deze string onderschept heeft hij het wachtwoord toch helemaal niet nodig?Hij kan deze string gewoon naar de server sturen en dan is hij ook ingelogd....

Dat ziet er eerder uit als een stukje code voor het valideren van een mail adres bij registratie. Puur een vergelijking of de gebruiker in staat is 2 keer hetzelfde mail adres in te voeren.

quote:

Op maandag 13 maart 2006 18:15 schreef Light het volgende:

[..]

Dat ziet er eerder uit als een stukje code voor het valideren van een mail adres bij registratie. Puur een vergelijking of de gebruiker in staat is 2 keer hetzelfde mail adres in te voeren.

Dat wil hij toch ook

quote:

Op maandag 13 maart 2006 17:21 schreef JeRa het volgende:
@ikke_ook

Dat is inderdaad geen veilige manier van inloggen. Een veiligere manier is challenge-response, in een notendop:

1. Maak gebruik van een hashing algoritme, in dit voorbeeld even SHA1
2. De server heeft de SHA1-hash van het wachtwoord van de gebruiker in de database staan
3. Als een gebruiker wil inloggen stuurt de server een random getal mee welke de server ook opslaat in de database (tijdelijk, in een session bijvoorbeeld)
4. Als de gebruiker zijn wachtwoord heeft ingevoerd berekent hij eerst de SHA1-hash van zijn wachtwoord en vervolgens de SHA1-hash van het random getal plus de eerste hash. Dit ziet er dan zo uit:

Uiteindelijke hash = SHA1(random getal + SHA1(wachtwoord))

Dit alles gebeurt door een SHA1-functie in javascript.

5. De uiteindelijke hash stuurt de gebruiker terug naar de server. Als iemand deze hash onderschept, kan hij redelijkerwijs onmogelijk de hash omdraaien aangezien het origineel bestaat uit een string van meer dan 40 tekens (random getal + SHA1(wachtwoord)) - zelfs als hij het random getal weet.
6. De server weet het random getal en de SHA1-hash van het wachtwoord (staat in de database) en kan dus controleren of de gestuurde hash geldig is. Zo ja, dan kan de gebruiker inloggen.

Natuurlijk moet je met meer dingen rekening houden, zoals een controle op IP-adres en/of Agent-string aangezien de onderschepper ook de session ID zou kunnen stelen.

heb m 5x doorgelezen voordat ik er een beetje duidelijk uit werd

maar kan deze uiteindelijke hash zelf niet onderschept worden dan? want dan ben je net zo ver van huis lijkt mij. of is het meer het idee om het wachtwoord geheim te houden dan het onmogelijk maken van inloggen?

quote:

Op maandag 13 maart 2006 20:11 schreef Desdinova het volgende:

[..]

maar kan deze uiteindelijke hash zelf niet onderschept worden dan? want dan ben je net zo ver van huis lijkt mij. of is het meer het idee om het wachtwoord geheim te houden dan het onmogelijk maken van inloggen?

Je kunt de uiteindelijke hash wel onderscheppen, maar je kunt er niets mee omdat als jij als onderschepper wilt inloggen je een ander random getal en session hebt. Zelfs als je de session ID gelijktijdig weet te onderscheppen kun je nog door IP-adres/Agent te controleren checken of het wel veilig is

But then again, als iemand je verbinding weet te rerouten is helemaal niéts veilig.

Die hash kan wel onderschept worden, maar je kunt er niks mee.
Met zo'n hash kun je 2 dingen proberen
1. het wachtwoord eruit halen
-Dat valt niet mee omdat een hash niet zomaar te kraken is, en er zit een random getal bij in gehashed waardoor het niet makkelijker wordt.
2. de gestolen hash zelf naar de server sturen en daardoor inloggen.
-Dit kan niet, omdat er een random getal in de hash zit, dit random getal heb je op de server in een session variabele gezet, en aangezien een (goede) session uniek is kan de hacker niet inloggen omdat hij een eigen sessie heeft, en dus een ander random getal in zn session

Duidelijk?

-edit- tering wat heb ik langzaam getypt

aaaaaaah. op die manier


nameserver check SIDN geeft hetvolgende bij mij:

errors=0, warnings=2, informational=0
* domein test.nl.
* nameserver ns1.test.nl./213.189.16.22
W SOA refresh (7200) < 4 uur (zie RFC1537)
* nameserver ns2.test.nl./213.189.16.23
W SOA refresh (7200) < 4 uur (zie RFC1537)


is dit ok of een verkeerde DNS instelling? zijn nog geen 4u voorbij..

quote:

Op maandag 13 maart 2006 19:28 schreef ikke_ook het volgende:

[..]

Dat wil hij toch ook

Dan zie ik even niet waar je die code vandaan hebt gehaald of waar je op doelt met die eerste opmerking Maar het is geen encryptie, die vergelijking.

Weten jullie nog van mijn mail probleem, waarbij HTML e-mails soms maar voor de helft bij de ontvanger aankwam?

Uiteindelijk ben ik erachter gekomen dat dit fenomeen zich voornamelijk bij mensen met een planet.nl mail adres voordeed. Ik heb planet gemailed en heb een keurig antwoord gekregen:

quote:

Geachte heer Swets,

Wij bieden u onze excuses aan voor de lange wachttijd voordat u een antwoord van ons ontvangt op uw vraag.

De response bestaat uit 3900 karakters achter elkaar, volgens de huidige standaard mogen maximaal 998 karakters worden gebruikt waarna een return moet volgen. Niet alle providers houden zich strikt aan deze standaard. Planet Internet hanteert deze standaard wel op zijn mailservers.

Wij vertrouwen er op u hiermee voldoende te hebben geïnformeerd. Mocht u nog vragen hebben, dan vernemen wij dit graag van u.


Met vriendelijke groet,

Planet Internet

Nu moet ik zeggen dat ik in de source inderdaad geen newline heb gezet, dus de volledig body van de mail stond als 1 zin achter elkaar.

ik heb nu dus


vervangen door



en hoop dat het probleem nu opgelost is

Tnx Swetsenegger, weer iets om te onthouden

quote:

Op maandag 13 maart 2006 21:15 schreef JeRa het volgende:
Tnx Swetsenegger, weer iets om te onthouden

Inderdaad niet iets wat veel ontwikkelaars op het puntje van hun tong hebben

quote:

Op maandag 13 maart 2006 21:15 schreef JeRa het volgende:
Tnx Swetsenegger, weer iets om te onthouden

Idem

quote:

Op maandag 13 maart 2006 21:10 schreef Swetsenegger het volgende:
Nu moet ik zeggen dat ik in de source inderdaad geen newline heb gezet, dus de volledig body van de mail stond als 1 zin achter elkaar.

Jammer dat je het voorbeeld netjes had opgemaakt. En in de header had je ook al netjes \r\n staan.

quote:

Op maandag 13 maart 2006 21:40 schreef Darkomen het volgende:

[..]

Idem

Konden ze overigens niet ipv dat mailtje afbreken geen foutmelding erin gooien?

quote:

Op maandag 13 maart 2006 22:01 schreef SuperRembo het volgende:

[..]

Jammer dat je het voorbeeld netjes had opgemaakt. En in de header had je ook al netjes \r\n staan.

Wel regeleindes, maar gaan '\r\n'. Dat was toch juist het probleem?

quote:

Op dinsdag 14 maart 2006 00:47 schreef the_disheaver het volgende:

[..]

Wel regeleindes, maar gaan '\r\n'. Dat was toch juist het probleem?

"\r\n" is gelijk aan een Windows-regeleinde

k probeer om de 5 seconden een pagina automatisch te laten refreshen. Hiervoor gebruik ik

1	header( 'refresh: 5;');

Het bovenstaande werkt mighty fine...in firefox that is. In IE refreshed de boel niet Ik heb al ff wat gezocht, maar overal stond dat het bij > IE 6.0 gewoon goed moet werken. Toen dacht ik om

<META HTTP-EQUIV="Refresh" CONTENT="5;URL=blabla.php">

te gebruiken. Werkt in Firefox wederom perfect..maar in IE niet.

Iemand enig idee waar dit aan zou kunnen liggen?


edit: verdomme...F5 of ctrl+F5 hielp niet, IE ff helemaal opnieuw opstarten daarentegen wel... Zie deze post als een teeveepee'tje dan maar

[ Bericht 2% gewijzigd door H4ze op 14-03-2006 01:06:21 ]

quote:

Op dinsdag 14 maart 2006 00:49 schreef JeRa het volgende:

[..]

"\r\n" is gelijk aan een Windows-regeleinde

ja, dat weet ik. Maar als je in een php file een regeleinde gooit, krijg je veel (meestal niets), maar geen regeleinde.

Dus hangt een beetje af hoe je het mailtje via php ingooit.