Procedure Mot de passe oublie

Bonjour,

Le sgbd contient le login, et le hashage sha1 du mot de passe (oui, oui,
je sais que John G. n'est pas pour, mais c'est déjà stocké comme ca...).

Je n'ai pas dit ça. La seule position que je soutiens, c'est qu'il est
plus primordial d'empêcher l'accès aux données que de les chiffrer. Cf
/etc/passwd vs /etc/shadow pour illustrer.

Ne *jamais* tenir le raisonnement "c'est pas grave si on accède à ces
données car elles sont chiffrées".

Je rappelle seulement que quand l'attaquant a réussit à avoir accès à
cette information :

1) il lui faudra peu de temps pour casser la crypto d'au moins quelques
mots de passe (rainbow tables, etc...)

2) c'est sacrément tard pour faire de la sécurité quand l'attaquant est
capable au moins d'extraire ce qu'il veut de la base.

Dit autrement, le chiffrage des données sensibles est la dernière
barrière, pas la première, et certainement pas suffisante en elle même.

Donc ma première idée est de mettre en place la page classique contenant
un champ entrez votre email et on vous renvoie un nouveau mot de passe.

Envoi d'un lien valide pendant X minutes (oh, une session !) permettant
d'écraser le mot de passe actuel.

Au moment de la validation, je pensai changer le mot de passe dans la
base en utilisant un généré aléatoirement, et envoyer ce dernier à
l'adresse email.
Oui si colonne temporaire. Mais ne rien faire sur le mot de passe

d'origine avant d'avoir le retour du mail. Inutile dans l'absolu.

Avez-vous des idées ou des liens pour résoudre ce problème?
Envoyer un jeton d'autorisation de changement au lieu d'envoyer le

nouveau mot de passe. Exactement comme tout accès à une page protégée
par une session, sauf qu'on passe par un envoi mail. Noter que
l'authentification réside alors uniquement sur le fait qu'on espère que
l'attaquant n'a pas accès au mail en question (s'il est devant
l'ordinateur de la victime...).

Prévoir aussi de trapper les mails qui bouncent...

JG

Or, comme les adresses email figurent aussi dans des messages sur le
site, j'ai peur qu'un petit malin ne s'amuse à changer les mots de passe
des autres. Bien sur, les membres recevront leur nouveau mot de passe,
mais ils risquent de se lasser de les modifier si cela se reproduit.

Déjà, faire figurer les emails complets est une mauvaise idée...
Mais quoi qu'il en soit, la seule chose qui me semble logique est de
faire ce que j'ai fait: tu intègres dans le mail un message du genre:
"La récupération du mot de passe a été demandée le 13/08/2007 à 15:59
par l'IP 255.255.255.255 ... Si ce n'est pas vous qui avez demandé cette
opération, transmettez ces informations au webmaster".

--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net

Envoi d'un lien valide pendant X minutes (oh, une session !) permettant
d'écraser le mot de passe actuel.

Et c'est un John confiant dans les serveurs de mails :) Pour ma part, je
donnerais un lien valide quelques heures (24?)

Oui si colonne temporaire. Mais ne rien faire sur le mot de passe
d'origine avant d'avoir le retour du mail. Inutile dans l'absolu.

Pas bête du tout

Envoyer un jeton d'autorisation de changement au lieu d'envoyer le
nouveau mot de passe. Exactement comme tout accès à une page protégée
par une session, sauf qu'on passe par un envoi mail. Noter que
l'authentification réside alors uniquement sur le fait qu'on espère que
l'attaquant n'a pas accès au mail en question (s'il est devant
l'ordinateur de la victime...).

Si l'attaquant peut prendre possession des mails, on ne peut rien y
faire, la victime est dans son tort.

--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net

Noter que
l'authentification réside alors uniquement sur le fait qu'on espère que
l'attaquant n'a pas accès au mail en question (s'il est devant
l'ordinateur de la victime...).

Si l'attaquant peut prendre possession des mails, on ne peut rien y
faire, la victime est dans son tort.

Parce que tu verrouilles systématiquement ton écran au bureau quand tu
vas pisser/cloper/bouffer/prendre un café ? Moi oui si j'ai des fenêtres
root sur des machines de prod, mais si c'est celle avec mon mail
wanamou... je peux oublier. Et je suis souvent en régie, chez des
clients. On ne doit pas avoir d'a priori sur les circonstances
d'utilisation, donc je tire le signal d'alarme, après chacun en fait ce
qu'il en veut selon les utilisateurs de son application et le niveau de
sécurité à atteindre.

A bien y réfléchir d'ailleurs, cet article bien qu'acceptable en Charte
ici aurait probablement eut des réponses plus pertinentes de termes de
sécurité sur fr.comp.securite (modéré).

JG

Re,

"La récupération du mot de passe a été demandée le 13/08/2007 à 15:59
par l'IP 255.255.255.255 ... Si ce n'est pas vous qui avez demandé cette
opération, transmettez ces informations au webmaster".

Et il en fera quoi le webmaster ? Il déposera une plainte au BEFTI pour
tentative d'intrusion dans un SI ?

Toutes les requêtes http reçues sur le log ci-dessous ne peuvent être
que des tentavives d'attaque par IP (un robot quelconque qui scanne un
segment d'IPs) du genre :

67.15.70.24 - - [20/Jun/2006:16:23:21 +0200] "GET /adxmlrpc.php
67.15.70.24 - - [20/Jun/2006:16:23:22 +0200] "GET /xmlrpc.php

Un peu de stats sachant que le log est effacé vers 1h du matin et qu'il
est midi environ :

grep 404 honeypot_log |awk '{print $1}'|sort -u |wc -l
191

Je vais pas déposer 200 plaintes par 1/2 journée...

A la limite, qu'on affiche lors de la demande de changement un message
disant que l'IP a été loguée (en le faisant... ou pas ! Surtout qu'il
suffit de grepper les logs du serveur web) pour "faire peur" aux neuneus
apprentis w4Rr10rZ, pourquoi pas, mais à part sur un intranet, c'est
d'utilité discutable.

JG

Bonjour,
y'a pas beaucoup de PHP dans ce message, positionner un suivi vers un
groupe plus approprié si nécéssaire...

Bilango wrote:

Bonjour à tous,
Dans le cadre de la refonte d'un site en PHP/mysql, je dois ajouter la
fonctionnalité Mot de passe oublié sur l'accès à un espace membre.
[...]

Le sgbd contient le login, et le hashage sha1 du mot de passe (oui, oui,
je sais que John G. n'est pas pour, mais c'est déjà stocké comme ca...).
bah, avec un grain de sel secret pour chaque utilisateur, je vois pas le

problème. Le sel est stoqué dans la base et utilisé pour hasher le mdp.
Si un méchant accède à cette info tu as de plus gros problèmes que les
mots de passes de tes utilisateurs.

Donc ma première idée est de mettre en place la page classique contenant
un champ entrez votre email et on vous renvoie un nouveau mot de passe.

Au moment de la validation, je pensai changer le mot de passe dans la
base en utilisant un généré aléatoirement, et envoyer ce dernier à
l'adresse email.

Or, comme les adresses email figurent aussi dans des messages sur le
site, j'ai peur qu'un petit malin ne s'amuse à changer les mots de passe
des autres. Bien sur, les membres recevront leur nouveau mot de passe,
mais ils risquent de se lasser de les modifier si cela se reproduit.
Je mettrais une contrainte unique (not null implicite) sur le champ

mail.. Je ne vois pas bien comment le petit malin s'y prendrait pour
chaner les mots de passe des autres, il peut envoyer des demandes de
changement de mot de passe a tout le monde mais pas les changer
effectivement. Si le cas se produit, bannir IP (pas efficace pour les
adresses dynamiques).

D'autres part, je n'ai pas d'information dans la base concernant le
compte qui ne soit pas visible sur le site (genre, quel est le nom de
votre chien) qui permettrait d'identifier à coup sur le demandeur. Et
comme, il y a déjà plusieurs milliers de compte déjà créé, je ne peux
ajouter cette fonction.
Je me méfierais de ce genre de questions trop simples, les blogs et

autres sites perso permettent de réaliser des attaques ciblées sur
certains utilisateurs. (ceux qui laissent leur adresse blog/site dans la
signature). Je me rappelle d'une discussion à ce propos sur fcs
http://groups.google.be/groups/search?&q=%22question+de+securite%22+group%3Afr.comp.securite.

Avez-vous des idées ou des liens pour résoudre ce problème?

Pourquoi ne pas peupler une nouvelle table "users_ng" quand
l'utilisateur se connecte, le "forcer gentillement" à fournir les
nouvelles info (login, mdp, surnom, email, question secrete, réponse, IP
dernier login, timestamp dernier login, ban, ... Suggérer/imposer de ne
pas utiliser login comme surnom). Il se connecte avec ses identifiant
actuels, rempli les nouvelles infos et seulement après il peut acceder
aux fonctions membres uniquement. Si le membre a déjà perdu son mot
passe, tant pis pour lui, il créera un nouveau compte de tt façon.

2c,
--
MaXX

"La récupération du mot de passe a été demandée le 13/08/2007 à 15:59
par l'IP 255.255.255.255 ... Si ce n'est pas vous qui avez demandé cette
opération, transmettez ces informations au webmaster".
Et il en fera quoi le webmaster ? Il déposera une plainte au BEFTI pour

tentative d'intrusion dans un SI ?

Je sors totalement du php et parle du .htaccess:

RewriteCond %{REMOTE_ADDR} ^67.15.70.[0-9]{1,3}$
RewriteRule ^.*$ - [F]

Voila ce que peut faire le webmaster :)

--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net

Je n'ai pas dit ça. La seule position que je soutiens, c'est qu'il est
plus primordial d'empêcher l'accès aux données que de les chiffrer. Cf
/etc/passwd vs /etc/shadow pour illustrer.

J'avais bien compris cela (à force de le lire ;-), mais c'était une
courte parenthèse en forme de clin d'oeil.

Donc ma première idée est de mettre en place la page classique contenant
un champ entrez votre email et on vous renvoie un nouveau mot de passe.

Envoi d'un lien valide pendant X minutes (oh, une session !) permettant
d'écraser le mot de passe actuel.

Effectivement, je vais certainement opter pour cette idée. Sur le
principe de la session par contre, je me demande si le risque n'est pas
la fermeture du navigateur par l'internaute (ou alors je n'ai pas
compris la méthode). C'est peut être un risque minime, qui peut surement
être prévenu par un message (laisser cette fenêtre ouverte) mais bon...

Au moment de la validation, je pensai changer le mot de passe dans la
base en utilisant un généré aléatoirement, et envoyer ce dernier à
l'adresse email.

Oui si colonne temporaire. Mais ne rien faire sur le mot de passe
d'origine avant d'avoir le retour du mail. Inutile dans l'absolu.

Bon sang, mais c'est bien sur... C'était pourtant évident rétrospectivement.

Avez-vous des idées ou des liens pour résoudre ce problème?

Envoyer un jeton d'autorisation de changement au lieu d'envoyer le
nouveau mot de passe. Exactement comme tout accès à une page protégée
par une session, sauf qu'on passe par un envoi mail. Noter que
l'authentification réside alors uniquement sur le fait qu'on espère que
l'attaquant n'a pas accès au mail en question (s'il est devant
l'ordinateur de la victime...).

Argh, je prendrai le risque.

Prévoir aussi de trapper les mails qui bouncent...

JG

Mes remerciements sincères.

--
Bilango

Bonjour,
y'a pas beaucoup de PHP dans ce message, positionner un suivi vers un
groupe plus approprié si nécéssaire...

Il y en a un peu dans la mise en oeuvre, même si je ne demande pas de
code tout fait. Peut être que dans fr.comp.securite, s'eut été plus
judicieux. Mais je fais confiance à la mansuétude des modérateurs de
fclp ;-)

Je mettrais une contrainte unique (not null implicite) sur le champ
mail..

Les mails sont déjà unique mais je ne vois pas en quoi c'est important
dans la procédure.

Je ne vois pas bien comment le petit malin s'y prendrait pour
chaner les mots de passe des autres, il peut envoyer des demandes de
changement de mot de passe a tout le monde mais pas les changer
effectivement.

C'était ca ma question. Je vais opter pour la création d'un champ
password temporaire qui n'updatera le vrai champ password que sur un
lien temporaire envoyé au client comme me la suggéré JG.

Si le cas se produit, bannir IP (pas efficace pour les
adresses dynamiques).

Je préférerai éviter de bannir des IP, au cas où je tombe sur celle du
proxy d'un FAI.

D'autres part, je n'ai pas d'information dans la base concernant le
compte qui ne soit pas visible sur le site (genre, quel est le nom de
votre chien) qui permettrait d'identifier à coup sur le demandeur. Et
comme, il y a déjà plusieurs milliers de compte déjà créé, je ne peux
ajouter cette fonction.

Je me méfierais de ce genre de questions trop simples, les blogs et
autres sites perso permettent de réaliser des attaques ciblées sur
certains utilisateurs. (ceux qui laissent leur adresse blog/site dans la
signature). Je me rappelle d'une discussion à ce propos sur fcs
http://groups.google.be/groups/search?&q=%22question+de+securite%22+group%3Afr.comp.securite.

J'évoquai cette question car, je crois me souvenir que les MSN et autres
voila, posent ce genre de question. Je voulais avoir des avis là-dessus.
Merci pour le lien.

Avez-vous des idées ou des liens pour résoudre ce problème?

Pourquoi ne pas peupler une nouvelle table "users_ng" quand
l'utilisateur se connecte, le "forcer gentillement" à fournir les
nouvelles info (login, mdp, surnom, email, question secrete, réponse, IP
dernier login, timestamp dernier login, ban, ... Suggérer/imposer de ne
pas utiliser login comme surnom). Il se connecte avec ses identifiant
actuels, rempli les nouvelles infos et seulement après il peut acceder
aux fonctions membres uniquement. Si le membre a déjà perdu son mot
passe, tant pis pour lui, il créera un nouveau compte de tt façon.

C'est une bonne idée. Merci.

--
Bilango

Re,

Envoi d'un lien valide pendant X minutes (oh, une session !) permettant
d'écraser le mot de passe actuel.

Effectivement, je vais certainement opter pour cette idée. Sur le
principe de la session par contre, je me demande si le risque n'est pas
la fermeture du navigateur par l'internaute (ou alors je n'ai pas
compris la méthode).

Une session n'est pas nécessairement une donnée conservée dans un
cookie... Le principe de la session, c'est de comparer une donnée reçue
avec une donnée conservée côté serveur qui est associée à des droits
d'accès aux ressoruces serveur. Donc si tu envoies un lien html dans le
mail du style change_pass.php?authid345677890ABCDefgh, il suffit de
vérifier que cet ID est présent dans, par exemple, une table de bases de
données (ou même un fichier texte vu le peu d'accès concurrents, à la
limite).

Au moment de la validation, je pensai changer le mot de passe dans la
base en utilisant un généré aléatoirement, et envoyer ce dernier à
l'adresse email.

Oui si colonne temporaire. Mais ne rien faire sur le mot de passe
d'origine avant d'avoir le retour du mail. Inutile dans l'absolu.
Bon sang, mais c'est bien sur... C'était pourtant évident rétrospectivement.

Comme je l'écrivais : inutile dans l'absolu, pour deux raisons.

1) le luser qui a oublié son mot de passe va surtout vouloir pouvoir en
choisir un lui même, et non un qui soit aléatoire. Donc inutile de
mettre en place tout un mécanisme de mot de passe écrasé par un nouveau
qui ne sera de toutes façons pas le bon !

2) ce que tu veux gérer c'est la vérification que le gars qui clique a
LE DROIT DE changer son mot de passe. Il n'y a AUCUN lien logique ni
sémantique en tre LE DROIT DE et un mot de passe temporaire.

Donc tu ne touches à rien dans la table qui stocke les mots de passe, tu
envoies un jeton d'autorisation sur un email réputé fiable, et tu
attends. Si ce jeton est demandé pendant sa période de validité, tu fais
l'update avec le nouveau mot de passe fournit, sinon... tu ne fais rien
d'autre que la purge du jeton.

C'est ça qui me broute profondément avec ce mécanisme des sessions PHP4,
c'est que les développeurs ne savent plus comment ça marche. Le
paragraphe que j'ai écrit au dessus, c'est exactement la description
d'une gestion de sessions "manuelle" telle qu'on la faisait déjà en PHP3
(et telle que je la fais encore d'ailleurs). Cf le tutoriel que je
diffuse sur saphirtech.com pour un détaillage complet.

a++;
JG