[ALG/PHP] - Veilige procedure voor verloren wachtwoord

[gvanh]

Graag wil ik een procedure maken voor het aanpassen van een verloren wachtwoord.

Als de gebruiker aangeeft dat hij zijn wachtwoord is verloren, dan kan hij zijn e-mailadres opgeven. Vervolgens wordt er gekeken of er voor het e-mailadres een gebruikersaccount aanwezig is. Zo ja, dan wordt er een e-mail gestuurd naar het e-mailadres met daarin een link om het wachtwoord te wijzigen.

Ik wil niet direct een nieuw wachtwoord sturen, want dat zou betekenen dat ik andere mensen kan gaan pesten door hun e-mailadres in te vullen, zij krijgen dan voortdurend e-mails met nieuwe wachtwoorden erin.

Nu moet ik dus een link gaan samenstellen waarmee de gebruiker op de website terechtkomt en waarmee hij zelf een nieuw wachtwoord kan invoeren.

Nu zit ik eraan te denken om de link op te bouwen uit de volgende onderdelen:
- Een hash op basis van het e-mailadres van de betreffende gebruiker.
- Een hash op basis van een tijdelijk wachtwoord* + de timestamp van genereren.

*Het tijdelijke wachtwoord wordt voor het account gegenereerd naast het "echte" wachtwoord en daarbij een datum wordt opgeslagen, zodat dit wachtwoord na X periode verloopt.

Zodra de gebruiker dan de link bezoekt, wordt gekeken of er voor de hash van het opgegeven e-mailadres een tijdelijk wachtwoord is, wordt gecontroleerd of het tijdelijke wachtwoord niet is verlopen en wordt vervolgens de hash gecontroleerd op basis van wachtwoord + timestamp.

Nu ben ik benieuwd of dit veilig is, of dat ik iets over het hoofd zie waardoor dit systeem makkelijk te "kraken" is.

Alvast weer veel dank voor het meedenken.

[gertvdijk]

gvanh schreef op maandag 23 juni 2008 @ 17:02:
- Een hash op basis van het e-mailadres van de betreffende gebruiker.

Ahum. Dan moet je wel een goede seed gebruiken... Zonder (niet te raden) seed is voor iedereen de hash bekend natuurlijk.

Zelf zat ik te denken aan een gehashte string op basis van andere velden van de gebruiker (liefst een onlogische volgorde en/of gegevens die niet publiekelijk bekend zijn) en een seed die niet herleidbaar is voor een eventuele aanvaller, maar wel bij jou bekend is. Je kan ook telkens een andere seed nemen, op basis van 'echte' randomness (/dev/random als je op *nix zit) en die opslaan in de database zodat je hem later weer kan gebruiken.
Bovendien een termijn (van een dag bijv.) voor het activeren met nieuwe wachtwoord, daarna wordt de request als niet-legitiem beschouwd. En daarnaast nog dat de elke link maar eenmaal klikbaar is.

gvanh schreef op maandag 23 juni 2008 @ 17:11:
Zou het dan handiger zijn om dat te doen op basis van het IP adres van degene die de aanvragen doet of op basis van het e-mailadres waarvoor steeds een nieuw wachtwoord wordt aangevraagd?

E-mail is geen (of iig niet bedoeld als) instant messaging, waardoor het prima een uurtje ofzo kan duren voordat de mail binnen is of gelezen wordt. In die tijd is het prima denkbaar dat de (legitieme) aanvrager een ander ip adres heeft gekregen (om wat voor reden dan ook). Daarom zou ik het niet op ip binden. Daarnaast is het gebruik van een proxy dodelijk voor simpele ip checks.

[ Voor 98% gewijzigd door gertvdijk op 23-06-2008 17:26 ]

[spaceninja]

Wat ook wel handig is dat mensen maar x aantal keer een nieuw wachtwoord aan kunnen vragen in x tijd.

Zoals je zelf al zegt "voordurend e-mails met nieuwe wachtwoorden" is vervelend, dit geld natuurlijk ook voor "voordurend nieuwe e-mails met links".

[gvanh]

Wat ook wel handig is dat mensen maar x aantal keer een nieuw wachtwoord aan kunnen vragen in x tijd.

Zou het dan handiger zijn om dat te doen op basis van het IP adres van degene die de aanvragen doet of op basis van het e-mailadres waarvoor steeds een nieuw wachtwoord wordt aangevraagd?

[user109731]

Ik zou gewoon een hash berekenen van een uniqid:

PHP:

$token = md5(uniqid(rand(), true));

Die sla je op in een database tabel met velden (token, user_id, password). De token zet je in de link in het e-mail bericht, op de server hoef je dan enkel te checken of het token geldig is en zo ja welke user_id met welk password erbij hoort. Aan de hand daarvan kun je dan je user tabel updaten.

[SvEn]

Bij een site die ik gemaakt heb moet je je email adres ingeven en je geboorte datum. Aan de hand daarvan word er een mailtje verstuurd met een hash ( token whatever ).

Daarna klikt de gebruiker op een link, en dan pas kan het wachtwoord daadwerkelijk worden veranderd. Veiliger kan ik het niet bedenken

Succes ermee!

[gertvdijk]

SvEn schreef op maandag 23 juni 2008 @ 17:29:
Bij een site die ik gemaakt heb moet je je email adres ingeven en je geboorte datum. Aan de hand daarvan word er een mailtje verstuurd met een hash ( token whatever ).

Dus als ik het e-mail adres en geboortedatum weet en hoe jij die samenstelt om er een hash van te maken kan ik van iedereen waarvan ik die twee gegevens heb de wachtwoorden wijzigen?
Overigens is je constructie achterhalen niet zo moeilijk: ik registreer mezelf en volg gewoon je procedure, pak de hash erbij en ga aan de slag om die hash zelf te verkrijgen door verschillende mogelijkheden. Is niet heel moeilijk. Geboortedatum en e-mail adres zijn niet de meest lastig op te zoeken gegevens. Soms staan ze openbaar bij een andere community waar de gebruiker dezelfde gebruikersnaam heeft. En dan gewoon de link herschrijven met de hash die ik maak.
Daarom dus: gebruik een niet te raden seed in je hashes.

[Confusion]

gvanh schreef op maandag 23 juni 2008 @ 17:02:
Ik wil niet direct een nieuw wachtwoord sturen, want dat zou betekenen dat ik andere mensen kan gaan pesten door hun e-mailadres in te vullen, zij krijgen dan voortdurend e-mails met nieuwe wachtwoorden erin.

Er zijn vele grote sites die dat zo doen: het is dus de vraag of het probleem dat je voorziet wel echt optreedt. Als je zorgt dat dat formulier niet spambaar is, dan heb je hier sowieso vrijwel geen last van, zonder het voor jezelf moeilijker te maken dan nodig is.

[SvEn]

gertvdijk schreef op maandag 23 juni 2008 @ 17:38:
[...]

Dus als ik het e-mail adres en geboortedatum weet en hoe jij die samenstelt om er een hash van te maken kan ik van iedereen waarvan ik die twee gegevens heb de wachtwoorden wijzigen?
Overigens is je constructie achterhalen niet zo moeilijk: ik registreer mezelf en volg gewoon je procedure, pak de hash erbij en ga aan de slag om die hash zelf te verkrijgen door verschillende mogelijkheden. Is niet heel moeilijk. Geboortedatum en e-mail adres zijn niet de meest lastig op te zoeken gegevens. Soms staan ze openbaar bij een andere community waar de gebruiker dezelfde gebruikersnaam heeft. En dan gewoon de link herschrijven met de hash die ik maak.
Daarom dus: gebruik een niet te raden seed in je hashes.

Je krijgt pas het mailtje met een hash op het moment dat je die twee gegevens dus weet. En het mailtje krijgt degene die het account bezit.

Daarnaast is die hash met verschillende factoren random in elkaar gedraaid. Verder word deze hash automatisch verwijderd als er binnen een paar dagen geen gebruik van word gemaakt.

Ik daag je uit haha.

EDIT : De hash word nl. o.a. gemaakt uit de tijd in miliseconden. Dit is uiterst moeilijk te achterhalen welke miliseconde het precies was

[ Voor 6% gewijzigd door SvEn op 23-06-2008 18:03 ]

[Razr]

In het eerste mailtje (na het aangeven op de site dat het wachtwoord is vergeten) stuur je een mailtje naar het geregistreerde e-mail adres of het inderdaad klopt dat het wachtwoord is vergeten. Hierin zet je dan een link met een unieke hash (welke je opslaat in je db + een vlaggetje zetten bij deze user dat hij aan heeft gegeven z'n wachtwoord vergeten te zijn). Vervolgens stuur je een nieuw gegenereerd wachtwoord naar z'n mail. Vanaf dit moment kan hij weer inloggen en pas dan zijn wachtwoord veranderen.

Na het mailen van het nieuwe wachtwoord reset je het vlaggetje uiteraard. En je checkt ook op aanwezigheid van dit vlaggetje + de hash in de db voordat je een nieuw wachtwoord genereert en mailt.

[gertvdijk]

SvEn schreef op maandag 23 juni 2008 @ 17:58:
Je krijgt pas het mailtje met een hash op het moment dat je die twee gegevens dus weet. En het mailtje krijgt degene die het account bezit.

Mijn punt was dus dat je ook zonder dat mailtje de boel kon overnemen.

SvEn schreef op maandag 23 juni 2008 @ 17:58:
EDIT : De hash word nl. o.a. gemaakt uit de tijd in miliseconden. Dit is uiterst moeilijk te achterhalen welke miliseconde het precies was

Ja, dat zei je er niet bij. Is het een standaard unix time stamp? Dan kom je met een schatting al aardig in de richting. Dan nog even uitzoeken wanneer de ntp sync wordt gedaan op je server (distro kijken en wat default is) en dan is het een kwestie van een paar duizend mogelijkheden proberen. Nee, ik zou het niet tijdsafhankelijk maken (als enige randomness).

[Zoijar]

gertvdijk schreef op maandag 23 juni 2008 @ 18:30:
Ja, dat zei je er niet bij. Is het een standaard unix time stamp? Dan kom je met een schatting al aardig in de richting. Dan nog even uitzoeken wanneer de ntp sync wordt gedaan op je server (distro kijken en wat default is) en dan is het een kwestie van een paar duizend mogelijkheden proberen. Nee, ik zou het niet tijdsafhankelijk maken (als enige randomness).

Aangezien je een mailtje krijgt met een link is je ingevoerd hash altijd de eerste keer goed. Op het moment dat er dus 1x een verkeerde hash binnekomt wordt die uiteraard meteen uit het systeem verwijderd. Dat kraak je vrijwel nooit. Maar goed, het kan geen kwaad om er een salt achter te plakken.

[gertvdijk]

Zoijar schreef op maandag 23 juni 2008 @ 18:59:
Aangezien je een mailtje krijgt met een link is je ingevoerd hash altijd de eerste keer goed. Op het moment dat er dus 1x een verkeerde hash binnekomt wordt die uiteraard meteen uit het systeem verwijderd. Dat kraak je vrijwel nooit. Maar goed, het kan geen kwaad om er een salt achter te plakken.

Dat doet niks af aan je slechte beveiliging hoor. Als iemand een account probeert over te nemen doet hij dat zonder de e-mail die verstuurd is. De gebruiker waar het om gaat leest de e-mail pas later (bijvoorbeeld de volgende dag) en de link zal niet werken, omdat de 'hacker' de goede hash al had gevonden...

[ Voor 5% gewijzigd door gertvdijk op 23-06-2008 19:04 ]

[Zoijar]

gertvdijk schreef op maandag 23 juni 2008 @ 19:02:
Dat doet niks af aan je beveiliging hoor. Als iemand een account probeert over te nemen doet hij dat zonder de e-mail die verstuurd is. De gebruiker waar het om gaat leest de e-mail pas later en de link zal niet werken...

Dat kan uiteraard niet als er geen email is verstuurd, want dan staat je password-reset veld gewoon op 0, en dan werkt het uberhaupt niet. Pas bij een email aanvraag wordt dat veld geinitialiseerd, en op een speciale pagina wordt het vergeleken met de gestuurde waarde. Als die twee niet matchen wordt het veld weer op 0 gezet.

(verder de restrictie die boven al is genoemd: je kan zo'n password reset maar 1x per dag aanvragen oid)

[ Voor 7% gewijzigd door Zoijar op 23-06-2008 19:06 ]

[gertvdijk]

Zoijar schreef op maandag 23 juni 2008 @ 19:04:
Dat kan uiteraard niet als er geen email is verstuurd, want dan staat je password-reset veld gewoon op 0, en dan werkt het uberhaupt niet. Pas bij een email aanvraag wordt dat veld geinitialiseerd, en op een speciale pagina wordt het vergeleken met de gestuurde waarde. Als die twee niet matchen wordt het veld weer op 0 gezet.

Ja, de mail wordt ook verstuurd. Maar die heeft de 'hacker' niet nodig. Wel lezen.
Dus: de hash staat in de database, de hash kan worden bepaald door de hacker (al dan niet met enige moeite), de link kan worden gemaakt op basis van de link die de hacker met zijn eigen account heeft gekregen...

Zoijar schreef op maandag 23 juni 2008 @ 19:04:
[...]
(verder de restrictie die boven al is genoemd: je kan zo'n password reset maar 1x per dag aanvragen oid)

De password reset hoeft ook maar 1x te worden aangevraagd. Alleen de hash 'indienen' dient te gebeuren voordat de betreffende gebruiker (het slachtoffer) op de link in zijn mailbox klikt. Voor zover nog geen restrictie van jullie kant over het maar 1x per dag mogen indienen van een hash.

[ Voor 26% gewijzigd door gertvdijk op 23-06-2008 19:08 ]

[Zoijar]

Hoe kan de hacker de hash dan bepalen? Hij krijgt 1x per dag 1 poging. De hash bestaat uit het aantal nanasecondes verstreken in de huidige seconde (plus een server constante salt waarde). Hash heb je ook niet echt nodig, je kan gewoon dat getal sturen. Maar je kan het hashen, zodat het niet als plaintekst in je database staat.

(Overigens is md5 broken... niet meer gebruiken. Niet dat het hier uitmaakt, maar toch.)

[gertvdijk]

Zoijar schreef op maandag 23 juni 2008 @ 19:10:
Hoe kan de hacker de hash dan bepalen? Hij krijgt 1x per dag 1 poging.

Nee, hij krijgt met bovenstaand verhaal 1x per dag 1 poging om de juiste combinatie e-mail adres / geboortedatum te laten vinden. De methode van hash genereren is bekend a.d.h.v. de hackers' eigen accounte met 'vergeten' wachtwoord (zie verhaal hierboven).

Zoijar schreef op maandag 23 juni 2008 @ 19:10:
De hash bestaat uit het aantal nanasecondes verstreken in de huidige seconde (plus een server constante salt waarde).

Dat er een salt wordt gebruikt lees ik nu pas. Standaard is die er niet hoor.
De tijd in miliseconden is toch wel te schatten op +/- een halve seconde als je weet wanneer hij synct met ntp. Dan heb je dus 1000 verschillende hashes (oplopende afwijking van je schatting) en die ga je een voor een aanbieden door de link te submitten, totdat de server toehapt.

Zoijar schreef op maandag 23 juni 2008 @ 19:10:
Hash heb je ook niet echt nodig, je kan gewoon dat getal sturen. Maar je kan het hashen, zodat het niet als plaintekst in je database staat.

Dan is het alleen nog even uitvogelen wat de afwijking van de tijd is op de server, a.d.h.v. het account van de hacker zelf die de timestamp vergelijkt met die op het moment van zijn request.

Zoijar schreef op maandag 23 juni 2008 @ 19:10:
(Overigens is md5 broken... niet meer gebruiken. Niet dat het hier uitmaakt, maar toch.)

Het is inderdaad zo dat md5 gekraakt is, maar je moet wel de achtergrond ervan even kennen. Het probleem is dat je kan aantonen dat er meerdere strings mogelijk zijn die dezelfde hash geven (er zijn immers meer strings mogelijk dan hashes) en dat er relatief eenvoudig een tweede string te vinden is die dezelfde hash geeft. Hierdoor kan je dus niet meer 100% zeker zijn of twee strings hetzelfde zijn (of onaangetast, man in the middle) door de hashes te vergelijken. Heeft hier dus geen invloed op.

[Zoijar]

gertvdijk schreef op maandag 23 juni 2008 @ 19:30:
Nee, hij krijgt met bovenstaand verhaal 1x per dag 1 poging om de juiste combinatie e-mail adres / geboortedatum te laten vinden. De methode van hash genereren is bekend a.d.h.v. de hackers' eigen accounte met 'vergeten' wachtwoord (zie verhaal hierboven).

Bekend ja, behalve dat hij nog even de juiste seconde moet vinden, en dan de juiste 1 op 1000 microseconde.

Dat er een salt wordt gebruikt lees ik nu pas. Standaard is die er niet hoor.
De tijd in miliseconden is toch wel te schatten op +/- een halve seconde als je weet wanneer hij synct met ntp. Dan heb je dus 1000 verschillende hashes (oplopende afwijking van je schatting) en die ga je een voor een aanbieden door de link te submitten, totdat de server toehapt.

Ja, ik begrijp hoe je aanval werkt. Ik voeg altijd standaard iets van 10 characters salt toe, dan ben je sowieso van het hele gezeur af. Dan ga je ze een voor een aanbieden. De server krijgt jouw geschatte key, die matched niet. Server reset het veld naar 0. Dan ga je opnieuw een reset aanvragen en de tijd schatten ofzo? Dat werkt dus niet. Als je het een keer fout hebt (of 2 a 3 keer...), dan moet je een nieuwe reset key aanvragen. Die nieuwe key heeft een andere timestamp. Het blijft dus een 1 op 1000 verhaal, als je verder alles precies zou weten. Naar verwachting moet je het dus 500 keer proberen; dat duurt 500 dagen, en de gebruiker krijgt 500 dagen lang elke dag een mailtje van een wachtwoord reset request. Niet echt opvallend.

Dan is het alleen nog even uitvogelen wat de afwijking van de tijd is op de server, a.d.h.v. het account van de hacker zelf die de timestamp vergelijkt met die op het moment van zijn request.

Je weet niet precies wanneer de code voor jouw request runned op een veel gebruikte web-server. Maar goed, in principe mogelijk dat je het meteen goed hebt.

Het is inderdaad zo dat md5 gekraakt is, maar je moet wel de achtergrond ervan even kennen. Het probleem is dat je kan aantonen dat er meerdere strings mogelijk zijn die dezelfde hash geven (er zijn immers meer strings mogelijk dan hashes) en dat er relatief eenvoudig een tweede string te vinden is die dezelfde hash geeft. Hierdoor kan je dus niet meer 100% zeker zijn of twee strings hetzelfde zijn (of onaangetast, man in the middle) door de hashes te vergelijken. Heeft hier dus geen invloed op.

Ik ken precies de achtergrond ervan; vandaar dat ik er al bij vertelde dat het er hier niet toe doet, maar dat het een voetnoot was.

Misschien was ik niet duidelijk. Mijn voorstel was dus het algoritme van de TS te gebruiken; email een random getal dat als wachtwoord kan worden gebruikt, etc. De enige toevoeging bij mij is dat je dat tijdelijk wachtwoord weer weghaalt/delete/"op 0 zet" na een login poging, zowel een goede als een verkeerde. Ook moeten natuurlijk beide wachtwoorden blijven werken.

[ Voor 6% gewijzigd door Zoijar op 23-06-2008 20:41 ]

[Nvidiot]

Zoijar schreef op maandag 23 juni 2008 @ 20:35:
De server krijgt jouw geschatte key, die matched niet. Server reset het veld naar 0. Dan ga je opnieuw een reset aanvragen en de tijd schatten ofzo? Dat werkt dus niet. Als je het een keer fout hebt (of 2 a 3 keer...), dan moet je een nieuwe reset key aanvragen. Die nieuwe key heeft een andere timestamp. Het blijft dus een 1 op 1000 verhaal, als je verder alles precies zou weten. Naar verwachting moet je het dus 500 keer proberen; dat duurt 500 dagen, en de gebruiker krijgt 500 dagen lang elke dag een mailtje van een wachtwoord reset request. Niet echt opvallend.

[...]

De enige toevoeging bij mij is dat je dat tijdelijk wachtwoord weer weghaalt/delete/"op 0 zet" na een login poging, zowel een goede als een verkeerde. Ook moeten natuurlijk beide wachtwoorden blijven werken.

Hoe weet de server dat <foutief gegokt random getal> een inlogpoging is voor een bepaald account? Dat kan de server niet weten. (Ervanuitgaande dat de link iets is als http://server.com/reset_password/1234567890)

[gertvdijk]

Nvidiot schreef op maandag 23 juni 2008 @ 20:45:
Hoe weet de server dat <foutief gegokt random getal> een inlogpoging is voor een bepaald account? Dat kan de server niet weten. (Ervanuitgaande dat de link iets is als http://server.com/reset_password/1234567890)

Als de username erbij zit, in de aanvraag, is het wel weer een stuk beter in te dammen, door ook de aan te bieden hashes te beperken. Ik gok dat Zoijar dit wel bedoelt, maar dat staat nergens beschreven.
Ik stel voor dat iedereen volledig is in zijn voorstellen en dan ook niet iets vergeet te noemen in het beschrijven van zijn 'oplossing'. Vaak zijn de dingen die klein lijken het grote gat in je beveiliging.

[ Voor 4% gewijzigd door gertvdijk op 23-06-2008 20:59 ]

[Hydra]

Snap niet dat mensen zo moeilijk zitten te doen. Je maakt gewoon een unieke hash aan (MD5 gebaseerd op uniqueid bijvoorbeeld), slaat die hash op in een speciale tabel gekoppeld aan de username/password, en stuurt een link met die user/hash naar het mailadres. Die persoon klikt de link aan, je checked in je script of de username/hash in de tabel staan en kloppen, en genereert dan een nieuw random pass dat je naar het mailadres stuurt. Klaar.

[Gomez12]

En de geschatte tijd is ook weer in te dammen door in het md5-proces bij de huidige tijd nog een waarde x op te tellen als extra salt.

In principe maakt het hele md5'en ( of andere hashing manier voor de mensen die over md5 vallen ) het onkraakbaar zolang je maar een salt neemt die "random" is.
Paar kleine dingetjes in je verificatie procedure zodat er niet gebruteforced kan worden ( max logins 1 per 3 sec., max 3 logins daarna geen reset meer ).

En in principe moet je al een email adres / iets anders unieks in de link vermelden omdat elke hashing methode zelf al conflicts oplevert en zonder uniek kenmerk heb je dus de kans dat een /1234567890 bij meerdere gebruikers geldig is zodat zelfs een goede gebruiker nog het wachtwoord van een ander persoon kan wijzigen.

Hydra schreef op maandag 23 juni 2008 @ 21:09:
Snap niet dat mensen zo moeilijk zitten te doen. Je maakt gewoon een unieke hash aan (MD5 gebaseerd op uniqueid bijvoorbeeld), slaat die hash op in een speciale tabel gekoppeld aan de username/password, en stuurt een link met die user/hash naar het mailadres. Die persoon klikt de link aan, je checked in je script of de username/hash in de tabel staan en kloppen, en genereert dan een nieuw random pass dat je naar het mailadres stuurt. Klaar.

Dus met jouw methode kan ik eventjes gaan bruteforcen met een aantal hashes en dan krijgen misschien een paar andere mensen mailtjes met een nieuw paswoord. Nee, daar worden je gebruikers vrolijk van...

Nog even daargelaten dat een unieke hash niet te maken is ( md5-hash kent maar een beperkt aantal karakters, dus als ik een 100Gb bestand ga hashen dan heeft dat gegarandeert een conflict met nog een aantal andere bestanden, misschien wel met zo'n unique id van jouw ).
Kan je beter gelijk het id meesturen, is veel en veel unieker.

[ Voor 41% gewijzigd door Gomez12 op 23-06-2008 21:19 ]

[gertvdijk]

Hydra schreef op maandag 23 juni 2008 @ 21:09:
Snap niet dat mensen zo moeilijk zitten te doen. Je maakt gewoon een unieke hash aan (MD5 gebaseerd op uniqueid bijvoorbeeld)

Been there, done that.
Heb je ook gekeken wat uniqid doet?

string uniqid ([ string $prefix [, bool $more_entropy ]] )
Gets a prefixed unique identifier based on the current time in microseconds.

Ook weer standaard op basis van tijd. Als is met microseconden wel een factor 1000 verschil in het aantal mogelijkheden t.o.v. milliseconden.

Verder is er niks op aan te merken, maar het kan netter naar mijn idee, met een mailtje minder en waarbij de gebruiker zelf een nieuw wachtwoord kan invoeren. Met een goede randomness en goede hash.
En de TS wil volgens mij liever geen nieuw random password via e-mail.

gvanh schreef op maandag 23 juni 2008 @ 17:02:
Nu moet ik dus een link gaan samenstellen waarmee de gebruiker op de website terechtkomt en waarmee hij zelf een nieuw wachtwoord kan invoeren.

[ Voor 16% gewijzigd door gertvdijk op 23-06-2008 21:21 ]

[daniëlpunt]

Hydra schreef op maandag 23 juni 2008 @ 21:09:
Snap niet dat mensen zo moeilijk zitten te doen. Je maakt gewoon een unieke hash aan (MD5 gebaseerd op uniqueid bijvoorbeeld), slaat die hash op in een speciale tabel gekoppeld aan de username/password, en stuurt een link met die user/hash naar het mailadres. Die persoon klikt de link aan, je checked in je script of de username/hash in de tabel staan en kloppen, en genereert dan een nieuw random pass dat je naar het mailadres stuurt. Klaar.

Waarom laat je de user niet gelijk een nieuw wachtwoord invulen? Hij is de vorige al vergeten, en nu ga je een nieuwe, voor hem onbekende uitkiezen die hij daarna (waarschijnlijk) toch meteen veranderd.

[Gomez12]

Waarom moet je een mailtje minder doen? Het mailtje is imho juist een belangrijk wapen tegen hackers.

Als iemand het voor elkaar krijgt om een password reset aan te vragen dan weet hij alsnog niet de unieke code die naar dat email adres is verstuurd ( behalve als de email box ook gekraakt is ), alle aanvragen tot password met een verkeerde code blokkeren en na 10 blokkades op 1 dag het hele ip blacklisten, et voila. Iemand moet naast de md5 bruteforcen binnen 10 pogingen ook nog eens een emailbox uit kunnen lezen...

[Zoijar]

Nvidiot schreef op maandag 23 juni 2008 @ 20:45:
Hoe weet de server dat <foutief gegokt random getal> een inlogpoging is voor een bepaald account? Dat kan de server niet weten. (Ervanuitgaande dat de link iets is als http://server.com/reset_password/1234567890)

Het leek me wel logisch dat je user-id er bij zit...

Maar jullie hebben gelijk, ik beschreef het rommelig. Maar het leek me zo voor de hand te liggen. Overigens had de TS het zelf eigenlijk al opgeschreven... je kan een paar dingen toevoegen om het iets robuster te maken: een goede random key gebruiken (dwz +salt), het gebruik van een specifieke reset key maar 1x toestaan, reset-requests maar 1x per dag toe te staan, reset-keys laten expiren na een dag, en zorgen dat zowel je oude wachtwoord als de reset key geldig blijven.

Ok, duidelijker dan:

Database tabel: user-id / password-hash / reset-key(0) / reset-date(0)

Actie: user X vraag reset aan
- check bij user-id X of geboortedatum/email oid klopt, tegen spam scripts
- check reset-date meer dan 1 dag geleden, of 0, anders FAIL
- genereer random getal R op basis van timer
- Key=hash(R+salt), waar salt een onbekende string op je server is
- email gebruiker link naar pagina +Key + user-id
- sla Key op in veld reset-key
- sla date op in veld reset-date

Actie: normale login user-id X
- check password hash
- if correct, set reset-key = 0, reset-date = 0

Actie: reset pagina wordt aangeroepen
- Input: user-id=X, key=Key
- Zoek in database reset-key op bij gebruiker X
- Als reset-key == 0, of reset-date is te oud, of reset-key != Key --> reset-key = 0 en FAIL (exit)
- Log gebruiker in en laat hem watchwoord veranderen.
- reset-key = 0, reset-date = 0

Zoiets?

[ Voor 35% gewijzigd door Zoijar op 23-06-2008 21:38 ]

[Verwijderd]

Waarschijnlijk is dit al gepost (sorry geen zin om alles door te lezen) maar voor het geval van niet:

Het is naar mijn mening onnodig om een hash te genereren met daarin gebruikersinformatie. Deze informatie is namelijk helemaal niet nodig om authenticatie toe te passen. Als je een extra tabel in je database maakt met daarin een gebruikers id voor de gebruiker waarvan het wachtwoord gewijzigd mag worden, een unieke random gekozen token van > 128 tekens oid en een timestamp van de tijd van het aanvragen van het wijzigen van het wachtwoord. Je stuurt vervolgens een mailtje naar de desbetreffende gebruiker met daarin een link naar een pagina + de unieke token die je gegenereerd hebt. Op deze pagina kun je vervolgens kijken welke user id hoort bij deze token, vervolgens controleer je ook nog eens of de huidige tijd niet teveel afwijkt van de tijd die je in je database hebt staan (enkele uren bijvoorbeeld), zodat je brute-force aanvallen ook geen kans biedt. Eventueel laat je de gebruiker bij het wijzigen van het wachtwoord nogmaals zijn of haar email adres invullen zodat mensen niet "per-ongeluk" het wachtwoord van iemand anders kunnen wijzigen door een random token te proberen.

Dit lijkt mij een veilig systeem.

[ Voor 10% gewijzigd door Verwijderd op 23-06-2008 21:32 ]

[gertvdijk]

Gomez12 schreef op maandag 23 juni 2008 @ 21:22:
Waarom moet je een mailtje minder doen? Het mailtje is imho juist een belangrijk wapen tegen hackers.

Misvatting. Alleen met goede randomness kan je wat bereiken. Met een mailtje weet je ook wel dat de persoon de mail naar opgegeven adres kan openen.
Het maitlje minder is dus niet alleen netter en gebruiksvriendelijker. Een tweede is imo overbodig, mits je de rest van de zaken op orde hebt.

Gomez12 schreef op maandag 23 juni 2008 @ 21:22:
Als iemand het voor elkaar krijgt om een password reset aan te vragen dan weet hij alsnog niet de unieke code die naar dat email adres is verstuurd ( behalve als de email box ook gekraakt is )

Lezen.
De unieke code wordt vaak te snel uniek geclassificeerd. Dit terwijl het redelijk eenvoudig te vinden is. (zie posts erboven)

Verwijderd schreef op maandag 23 juni 2008 @ 21:30:
Het is naar mijn mening onnodig om een hash te genereren met daarin gebruikersinformatie. Deze informatie is namelijk helemaal niet nodig om authenticatie toe te passen.

True. Het gaat gewoon om randomness. Maar veel mensen putten die uit gebruikersinformatie (zoals ook de TS in zijn OP), terwijl dat alles behalve random is en zelfs achterhaalbaar is zonder salt.

[ Voor 20% gewijzigd door gertvdijk op 23-06-2008 21:37 ]

[user109731]

gertvdijk schreef op maandag 23 juni 2008 @ 21:18:
Heb je ook gekeken wat uniqid doet?
[...]
Ook weer standaard op basis van tijd. Als is met microseconden wel een factor 1000 verschil in het aantal mogelijkheden t.o.v. milliseconden.

Je kunt ook een prefix als rand() meegeven en voor de tweede parameter true:

prefix
Can be useful, for instance, if you generate identifiers simultaneously on several hosts that might happen to generate the identifier at the same microsecond. With an empty prefix, the returned string will be 13 characters long. If more_entropy is TRUE, it will be 23 characters.

more_entropy
If set to TRUE, uniqid() will add additional entropy (using the combined linear congruential generator) at the end of the return value, which should make the results more unique.

Zoals in mijn eerdere post in dit topic. Je hebt dan een op micro-seconden gebaseerde code, plus 10 random tekens erna, plus een random prefix ervoor. Dat ga je echt niet raden

Gomez12 schreef op maandag 23 juni 2008 @ 21:13:
Dus met jouw methode kan ik eventjes gaan bruteforcen met een aantal hashes en dan krijgen misschien een paar andere mensen mailtjes met een nieuw paswoord. Nee, daar worden je gebruikers vrolijk van...

Dan moeten die gebruikers wel aangegeven hebben dat ze hun wachtwoord vergeten zijn, en deze nog niet geactiveerd hebben. Okee dat zou je automatisch kunnen doen, maar dan nog is het aantal mogelijke md5 hashes veel te groot (16^32 = 340282366920938463463374607431768211456...). Maar goed, dan zet je de user id ook in de link en voeg je een timestamp veld toe in de database.

[ Voor 14% gewijzigd door user109731 op 23-06-2008 22:54 ]

[gertvdijk]

JanDM schreef op maandag 23 juni 2008 @ 22:44:
Je kunt ook een prefix als rand() meegeven en voor de tweede parameter true:

[...]

Zoals in mijn eerdere post in dit topic. Je hebt dan een op micro-seconden gebaseerde code, plus 10 random tekens erna, plus een random prefix ervoor. Dat ga je echt niet raden

Kan ik niet met je oneens zijn. Maar praktijk is anders, daar worden die features vaak niet gebruikt.

[ Voor 10% gewijzigd door gertvdijk op 23-06-2008 22:59 ]

[SvEn]

gertvdijk schreef op maandag 23 juni 2008 @ 22:59:
[...]

Kan ik niet met je oneens zijn. Maar praktijk is anders, daar worden die features vaak niet gebruikt.

Dat ben ik met je eens, maar 100% veilig hoeft het natuurlijk niet. Er is m.i. niemand die hier een paar uur aan gaat zitten om access te krijgen tot een site onder iemand anders zijn account.

Desondanks moet je natuurlijk altijd de veiligste oplossing bedenken tijdens het developen

[gertvdijk]

SvEn schreef op dinsdag 24 juni 2008 @ 00:10:
Er is m.i. niemand die hier een paar uur aan gaat zitten om access te krijgen tot een site onder iemand anders zijn account.

En als dat nou een bepaalde user is die meer rechten of bekendheid heeft? Moderator, admin, Paris Hilton, you-name-it.

[SvEn]

gertvdijk schreef op dinsdag 24 juni 2008 @ 00:12:
[...]

En als dat nou een bepaalde user is die meer rechten of bekendheid heeft? Moderator, admin, Paris Hilton, you-name-it.

Een moderator of admin moet je gewoon kunnen vertrouwen, die heeft meestal toch meer access. Maar wat is precies je punt? Want door het dus te limiteren tot 1 try zie ik echt het probleem niet.

[ Voor 8% gewijzigd door SvEn op 24-06-2008 00:22 ]

[gertvdijk]

SvEn schreef op dinsdag 24 juni 2008 @ 00:19:
Een moderator of admin moet je gewoon kunnen vertrouwen, die heeft meestal toch meer access. Maar wat is precies je punt?

Hmm... het is misschien laat, maar lees het nou nog eens.
De 'andere user' is de celeb of admin.

SvEn schreef op dinsdag 24 juni 2008 @ 00:10:
Er is m.i. niemand die hier een paar uur aan gaat zitten om access te krijgen tot een site onder iemand anders zijn account.

[TheBorg]

gertvdijk schreef op maandag 23 juni 2008 @ 21:18:
Heb je ook gekeken wat uniqid doet?

Lekker belangrijk. Het gaat om de aangedrage methode (extra db veld), hoe je een unieke id genereerd moet je zelf weten. Ik sluit me aan bij JanDM en ProFox.

[Gomez12]

gertvdijk schreef op maandag 23 juni 2008 @ 21:32:
[...]

Misvatting. Alleen met goede randomness kan je wat bereiken. Met een mailtje weet je ook wel dat de persoon de mail naar opgegeven adres kan openen.
Het maitlje minder is dus niet alleen netter en gebruiksvriendelijker. Een tweede is imo overbodig, mits je de rest van de zaken op orde hebt.

Ok, ik dacht dat je met mailtje minder het 1e mailtje weglaten bedoelde. 2mailtjes sturen is idd overbodig.

[SvEn]

gertvdijk schreef op dinsdag 24 juni 2008 @ 00:26:
[...]

Hmm... het is misschien laat, maar lees het nou nog eens.
De 'andere user' is de celeb of admin.

[...]

Akkoord misverstand. Maar lees het topic nou nog eens, 1 keer proberen is voldoende. En dan werkt het niet meer. Ik weet niet precies wat je probeert te bewijzen maar ik denk dat de vraag van de TS wel beantwoord is.

[Gomez12]

TheBorg schreef op dinsdag 24 juni 2008 @ 00:26:
[...]

Lekker belangrijk. Het gaat om de aangedrage methode (extra db veld), hoe je een unieke id genereerd moet je zelf weten. Ik sluit me aan bij JanDM en ProFox.

Het probleem is volgens mij meer dat heel veel mensen unieke dingen genereren die totaal voorspelbaar zijn. Dan is het leuk dat het uniek is. Als het voorspelbaar is dan heb je er nog niets aan...

[TheBorg]

Gomez12 schreef op dinsdag 24 juni 2008 @ 00:28:
[...]

Het probleem is volgens mij meer dat heel veel mensen unieke dingen genereren die totaal voorspelbaar zijn. Dan is het leuk dat het uniek is. Als het voorspelbaar is dan heb je er nog niets aan...

Ik vergeet er inderdaad bij te zeggen dat juist een database veld wordt gebruikt zodat een id gebruikt kan worden die random is gegenereerd, en dus geen hash is van persoonlijke gegevens (al dan niet in combinatie van een salt).

[gertvdijk]

SvEn schreef op dinsdag 24 juni 2008 @ 00:28:
Maar lees het topic nou nog eens, 1 keer proberen is voldoende. En dan werkt het niet meer.

Nu niet meer nee. Maar zie laatste alinea.

SvEn schreef op dinsdag 24 juni 2008 @ 00:28:
Ik weet niet precies wat je probeert te bewijzen maar ik denk dat de vraag van de TS wel beantwoord is.

Ik probeer niks te bewijzen. Het enige dat ik probeer is mensen bewust te maken van de beveiligingslekken die ze ermee opzetten. En tuurlijk is de vraag van de TS beantwoord, maar je kan het beter netjes oplossen (niet alleen time als randomness) en ook geen tweede e-mail.
Plus, dat het belangrijk is alle aspecten in de gaten te blijven houden als je bezig bent. Zelf ben je net even het belang van het beveiligen dat iemand het overnemen van een account van iemand anders even uit het oog verloren, bijvoorbeeld.

[g4wx3]

Er is natuurlijk een mogelijkheid om de link te ontcijfen, door zelf een nieuw wachtwoord aan te maken, maar in dat opzicht is phishing veel makkelijker.
Als je echt veilig zijn, dan schrap je het account...
maar je zou dus ook zo kunnen doen:

wachtwoord vergeten?
voer nieuw wachtwoord in:
kies een kleur (dynmische kleurenschijf)
Bevestig wachtwoord in mail

Hallo,
Je hebt een nieuw wachtwoord aangevraagd, bevestig met onderstaande link
https://www.domein.com?r=...m&255255255=MD4J2AJL42L4J

dan ook nog een checkje op de tijd moet zeker wel genoeg zijn.

Er zijn belangrijkere dingen om het hoofd over te breken!


Het is makkelijker een wachtwoord van iemand te raden, dan een hash proberen op te bouwen die voldoet aan de ijsen!

[ Voor 8% gewijzigd door g4wx3 op 24-06-2008 01:07 ]

[gertvdijk]

g4wx3 schreef op dinsdag 24 juni 2008 @ 01:05:
maar je zou dus ook zo kunnen doen:

wachtwoord vergeten?
voer nieuw wachtwoord in:
kies een kleur (dynmische kleurenschijf)
Bevestig wachtwoord in mail

Hallo,
Je hebt een nieuw wachtwoord aangevraagd, bevestig met onderstaande link
https://www.domein.com?r=...m&255255255=MD4J2AJL42L4J

Dan kan je mensen 'pesten' zoals de TS het noemt. Of bedoel je dat je het oude wachtwoord actief laat totdat het nieuwe is bevestigd?

g4wx3 schreef op dinsdag 24 juni 2008 @ 01:05:
Er zijn belangrijkere dingen om het hoofd over te breken!

Er zijn dingen net zo belangrijk om het hoofd over te breken, bedoel je, mag ik hopen?

g4wx3 schreef op dinsdag 24 juni 2008 @ 01:05:
Het is makkelijker een wachtwoord van iemand te raden, dan een hash proberen op te bouwen die voldoet aan de ijsen!

Dat denk ik niet. Een minimale wachtwoord sterkte is toch wel standaard en niet relevant voor dit topic imo.
Bij het maken van een hash zijn er natuurlijk wel een heleboel mogelijkheden, maar daar kan je een leuk scriptje voor schrijven je pc daar lekker 'het hoofd over laten breken'. Je probeert simpelweg allerlei mogelijkheden, met gegevens die je weet. Met een 1000-tal of meer als tijdsafhankelijke in je hash wordt het al veel lastiger en stijgt de tijd die je nodig hebt natuurlijk explosief. De TS wilde echter beginnen met een hash van slechts wel heel bekende variabelen (die heb je dan zo!) en later had iemand het over een geboortedatum. Je hebt gewoon een zo goed mogelijke randomness nodig, die niet te raden/herleiden valt.

[ Voor 7% gewijzigd door gertvdijk op 24-06-2008 01:25 ]

[gvanh]

Heren en dames,

Veel dank voor de uitbundige reacties. Het lijkt me dat ik hier nu meer dan voldoende info heb om een mooi en - tot op zekere hoogte - veilige procedure in te richten.

[Niemand_Anders]

Ik ken hackers die het precies andersom doen. Die hacken niet jouw account, maar juist eerst je mailbox. Weinig pop3/imap servers houden namelijk bij hoe vaak iemand foutief inlogd. Er is zelfs een grote kans dat de website accounts (username + wachtwoord) gewoon als welkoms mailtje in de mailbox staan.

Daarbij is het erg bekend dat mensen vaak hetzelfde wachtwoord gebruiken. Ook pincode pinpas + telefoon is vaak hetzelfde. Behalve dat als je met een websites zoals die van een bank bezig bent is de impact van een gehacked account natuurlijk ook erg beperkt. En dan komen we bij de phissing mailtjes terrecht. Mensen weten ondertussen zo'n beetje wel dat hun bank dergelijk mailtjes niet stuurd, maar dat hebben de meeste mensen nog niet doorgetrokken naar de rest van internet.

Ook foutmeldingen op veel websites zijn 'heerlijk' voor de hacker. Geef nooit op de website aan dat het emailadres niet in de database voorkomt! (bevestig namelijk wanneer een email WEL bestaat) Gewoon altijd aangeven dat het wachtwoord verstuurd is. Maar ook bij de inlog procedure worden ontzettend vaak ongewild kennis weggegeven. Vaak zie ik bij de inlog meldingen als 'user niet bekend' of 'wachtwoord incorrect'. Beter geef je dan de melding 'de combinatie user/password is niet correct'.

Wat betreft de hash, onder linux lees ik meestal gewoon 20 bytes van /dev/urandom en daarover gegeneer ik een SHA1. Onder windows vormt de GUID een goede hash. Bij de website van een verzekerings maatschappij (waarvan, gezien dit topic, ik de naam niet mag noemen) hebben wij een extra checksum aan de hash toegevoegd. In het betreffende geval werd de ascii waarde van elk karakter bepaald en bij elkaar opgeteld. Van dat getal werden alleen de laatste 4 cijfers gebruikt. De eerste twee werden vooraan toegevoegd en de laatste in hex notatie achteraan. De link zelf bevat onder andere het requestid (eveneens een guid) en customernr (een door elkaar gegooid customerid).
In de database is tevens de datum opgeslagen tot wanneer de confirmatie link actief is. De gebruiker krijg op deze website ook bijvoorbeeld een confirmatie link als deze zijn portefeuille wijzigt.

[gvanh]

Geef nooit op de website aan dat het emailadres niet in de database voorkomt! (bevestig namelijk wanneer een email WEL bestaat)

Hier heb ik ook aan gedacht. Maar ik zie dat andere websites dat onderscheid wel maken. Die hebben dus inderdaad een specifieke foutmelding als een account niet bestaat voor een bepaald e-mailadres. Vanuit de gebruiker gedacht is dat natuurlijk wel zo vriendelijk. Zelf heb ik bijvoorbeeld een hele hoop e-mailadressen die ik met enige willekeur door elkaar gebruik. Ik weet dus vaak niet meer met welk e-mailadres ik een bepaald account gestart ben. Als ik dan geen foutmelding krijg, moet ik dus een hele hoop opties proberen in de hoop dat er ergens op een gegeven moment in een van de accounts een e-mailtje binnenkomt, die ook nog 'ns niet in een Junkmail folder is binnengekomen.

[Niemand_Anders]

gvanh schreef op dinsdag 24 juni 2008 @ 10:51:
[...]
Hier heb ik ook aan gedacht. Maar ik zie dat andere websites dat onderscheid wel maken. Die hebben dus inderdaad een specifieke foutmelding als een account niet bestaat voor een bepaald e-mailadres. Vanuit de gebruiker gedacht is dat natuurlijk wel zo vriendelijk. Zelf heb ik bijvoorbeeld een hele hoop e-mailadressen die ik met enige willekeur door elkaar gebruik. Ik weet dus vaak niet meer met welk e-mailadres ik een bepaald account gestart ben. Als ik dan geen foutmelding krijg, moet ik dus een hele hoop opties proberen in de hoop dat er ergens op een gegeven moment in een van de accounts een e-mailtje binnenkomt, die ook nog 'ns niet in een Junkmail folder is binnengekomen.

Wij maken websites voor mensen welke normaal weinig tot niets doen op internet, maar wel op deze websites hun financiële zaken regelen. Een andere mogelijkheid is dat je bijhoud hoe vaak een IP je wachtwoord vergeten website bezoekt en als deze een bepaalde thresshold overschrijft het IP blokkeerd voor een bepaalde tijd (bijvoorbeeld 24 uur). Daarbij is het dan wel belangrijk bij te houden hoe vaak een IP wordt geblokkeerd zodat deze na X blokkades een permanente (firewall) ban krijgt.

In het geval van een 'kleine' bank is de procedure weer anders. Je geeft op basis van sofinummer en geboortedatum aan dat je je wachtwoord kwijt bent. Daarna wordt je gebeld door een medewerker van de bank om telefonisch je identiteit te bevestigen. De medewerker vraag je dan je legitimatie bewijs erbij te halen en zij (de medewerker) noemt je ID nummer op. Deze is bekend vanwege de legitimatie plicht voor banken ivm anti terrorisme wetgeving. Als deze overeenkomt stuurt de medewerker je een (automatische) email met daarin je nieuwe wachtwoord. Als het niet overeenkomt (bijvoorbeeld omdat je deze bent verloren) krijg je een brief van de bank waarbij gevraagd wordt een kopie van je legitimatie terug te sturen. De bank is daarna verplicht deze te controleren bij de instantie welke het ID heeft uitgegeven. Nadat deze is verwerkt krijg je alsnog een email met je nieuwe inlog gegevens.

Hoewel enigszins omslachtig heeft De Nederlandse Bank de methode als zeer goed beoordeeld. Een dergelijke methode is natuurlijk niet nodig bij een forum.

[djiwie]

Niemand_Anders schreef op dinsdag 24 juni 2008 @ 09:33:
Bij de website van een verzekerings maatschappij (waarvan, gezien dit topic, ik de naam niet mag noemen) hebben wij een extra checksum aan de hash toegevoegd. In het betreffende geval werd de ascii waarde van elk karakter bepaald en bij elkaar opgeteld. Van dat getal werden alleen de laatste 4 cijfers gebruikt. De eerste twee werden vooraan toegevoegd en de laatste in hex notatie achteraan. De link zelf bevat onder andere het requestid (eveneens een guid) en customernr (een door elkaar gegooid customerid).

En wat maakt dit het confirmation gebeuren veiliger dan een random gegenereerde checksum?

[Niemand_Anders]

djiwie schreef op dinsdag 24 juni 2008 @ 11:50:
[...]

En wat maakt dit het confirmation gebeuren veiliger dan een random gegenereerde checksum?

Omdat random niet bestaat in computer talen. Hackers proberen vaak met gegevens uit hun eigen account de checksum te opnieuw te produceren. Door zelfs de checksum lichtelijk aan te passen maak je het de hacker lastiger. Een hash string van 36 tekens (18 bytes) kan niet rechtstreeks aan bekende hash algoritmes gekoppeld worden. Alleen als de hacker echt per se jouw systeem wilt kraken, zal deze hiervoor de benodigde dagen uittrekken. Maar er is een grotere kans dat de hacker vertrekt naar een andere website. Dit geldt vooral voor de 'crackers' welke met kant- en klare tools werken. Die groep was in 2007 goed voor 89,5% van de hack pogingen op onze websites.

Het maakt de hash zelf niet veiliger, maar wel minder herkenbaar.

[? ?]

..

[ Voor 103% gewijzigd door ? ? op 25-01-2013 09:51 ]

[Gerco]

Niemand_Anders schreef op dinsdag 24 juni 2008 @ 11:49:
De medewerker vraag je dan je legitimatie bewijs erbij te halen en zij (de medewerker) noemt je ID nummer op. ... Hoewel enigszins omslachtig heeft De Nederlandse Bank de methode als zeer goed beoordeeld. Een dergelijke methode is natuurlijk niet nodig bij een forum.

Ik mag toch hopen dat de persoon aan de andere kant van de lijn (*niet* de medewerker dus) het nummer moet oplezen en niet dat de medewerker een willekeurige persoon gaat voorzien van een geldig paspoortnummer?

Ik kan me ook niet voorstellen dat DNB deze methode zou goedkeuren als de medewerker dat soort informatie aan een willekeurige persoon zou verstrekken.

[ZpAz]

Ook foutmeldingen op veel websites zijn 'heerlijk' voor de hacker. Geef nooit op de website aan dat het emailadres niet in de database voorkomt! (bevestig namelijk wanneer een email WEL bestaat) Gewoon altijd aangeven dat het wachtwoord verstuurd is. Maar ook bij de inlog procedure worden ontzettend vaak ongewild kennis weggegeven. Vaak zie ik bij de inlog meldingen als 'user niet bekend' of 'wachtwoord incorrect'. Beter geef je dan de melding 'de combinatie user/password is niet correct'.

Met het tweede ben ik het eens, maar het eerste is gewoon totaal gebruikersonvriendelijk, de persoon in kwestie heeft een typo gemaakt, en wacht een dag op een mail die nooit gaat komen.

[Confusion]

Niemand_Anders schreef op dinsdag 24 juni 2008 @ 09:33:
Ook foutmeldingen op veel websites zijn 'heerlijk' voor de hacker. Geef nooit op de website aan dat het emailadres niet in de database voorkomt! (bevestig namelijk wanneer een email WEL bestaat)

Nou en? Als je gewoon zorgt dat iemand dat niet vijfduizend keer per minuut kan proberen, dan is er geen man overboord. Anders creeer je een hoop extra support mail, omdat mensen niet meer weten welk mailaccount ze hadden gebruikt voor je site. Dat zijn extra helpdeskkosten, of gebruikers/klanten die je gewoon kwijt bent. Alleen maar omdat je paranoider bent dan je site waard is.

Er wordt hier een probleem opgelost dat niet voor de meeste sites niet relevant is. Ik heb ook geen antwoord gehad op Confusion in "\[ALG/PHP] - Veilige procedure voor verlo...". Als iemand zijn wachtwoord vergeten is, dan moet hij gewoon een nieuwe aan kunnen vragen, dat random wachtwoord toegemaild krijgen, die eenmalig invoeren en hem daarna direct veranderen. Dan hoef je niet met hashes, timestamps en god mag weten wat nog meer te klooien, met alle kans op bugs en security fuckups die niet voorkomen als je het gewoon simpel houdt. KISS.

[ Voor 16% gewijzigd door Confusion op 24-06-2008 22:20 ]

[pkuppens]

Gerco schreef op dinsdag 24 juni 2008 @ 15:43:
[...]

Ik mag toch hopen dat de persoon aan de andere kant van de lijn (*niet* de medewerker dus) het nummer moet oplezen en niet dat de medewerker een willekeurige persoon gaat voorzien van een geldig paspoortnummer?

Ik kan me ook niet voorstellen dat DNB deze methode zou goedkeuren als de medewerker dat soort informatie aan een willekeurige persoon zou verstrekken.

Als ik het hele verhaal lees, heb je al via geboortedatum, sofinummer, al verifieerbare gegevens opgestuurd. Verder word je gebeld, je telefoonnummer is dus ook bekend.
Doordat de medewerker jouw ID-nummer kent weet jij dat je met de gewenste organisatie praat en niet met een fishing-site, die niet vervolgens om je credit card nummer dat je moet blokkeren gaat vragen.

Edit: de persoon is dus niet willekeurig, bedoel ik te zeggen.

[ Voor 3% gewijzigd door pkuppens op 24-06-2008 22:33 ]