Pages :
Bonjour à tous

J'ai un site (association) qui a une partie publique et une partie privée.
Pour l'instant, la partie privée (réservée aux membres de l'association) est faiblement protégée par des mots de passe en clair. Compte tenu de ce que contient le site, cela nous a satisfaits pendant plus de 15 ans.
Comme le "progrès" est inéluctable, sauf à avoir un site impossible à maintenir, je suis maintenant contraint d'avoir une protection par mots de passes cryptés, tout cela pour pouvoir migrer vers une version d'Apache qui supporte PHP7.

La gestion des mots de passe se fait actuellement de la façon suivante (en PHP):
1) assignation d'un mot de passe temporaire, généré par un algorithme perso, à l'inscription d'un nouveau membre
2) le membre reçoit ce mot de passe par courriel, il s'en sert pour se connecter et donner son nouveau mot de passe
3) quand il l'a perdu, il demande qu'on le lui envoie à nouveau, ce que le programme fait en retrouvant l'utilisateur par son adresse courriel.

Je comprends que le nouveau système ne permet pas de renvoyer leur mot de passe aux utilisateurs, puisqu'en fait le programme ne le connait pas: tout ce dont il dispose c'est d'une chaîne cryptée qu'il est inutile de renvoyer à l'utilisateur, puisque ce qu'il doit envoyer c'est un mot de passe avant cryptage.

Je vais donc être obligé de modifier le système de gestion des mots de passe.

Auriez vous un modèle de gestion de mots de passe de ce genre à proposer pour que je n'aie pas à réinventer la roue? Je ne parle pas de code PHP, mais surtout d'une approche du problème qui ait fait ses preuves: inscription, confirmation, possibilité de retrouver un mot de passe perdu.

Merci de votre aide
Modifié par PapyJP (02 May 2016 - 10:39)
Je pense que tu as bien compris le principe. Ce que l'on voit souvent :

1 - Inscription avec choix de mot de passe
2 - Envoi d'un mail de confirmation avec un lien pour valider le compte et par ce bias que l'adresse e-mail est bien la bonne car c'est la clé pour récupérer son mot de passe plus tard
3 - Mot de passe perdu, l'utilisateur saisit son e-mail et on lui renvoie par mail une url temporaire lui permettant de modifier son mot de passe.

Ou si tu préfères générer le mot de passe

1 - Inscription sans choix de mot de passe
2 - Mot de passe envoyé par mail
3 - Mot de passe perdu, l'utilisateur saisit son e-mail et on lui renvoie un nouveau mot de passe par mail.
Salut,

Si j'ai bien compris tu veux stocker le mot de passe encrypte au lieu d'en clair dans ta bdd ? Smiley murf
Modifié par Tintin75 (02 May 2016 - 03:21)
Tintin75 a écrit :
Salut,

Si j'ai bien compris tu veux stocker le mot de passe encrypte au lieu d'en clair dans ta bdd ? Smiley murf

Tout à fait, c'est une bonne pratique à observer aujourd'hui. Ce qui implique comme le précise PapyJP que le site n'est pas capable de te retourner ton mot de passe, et donc si un site le fait, on comprend rapidement qu'il ne suit pas cette pratique, et est susceptible lors d'un éventuel piratage de sa base de se faire voler les mots de passe en clair.

Sinon @PapyJP, tout est dit je pense dans la réponse de bzh.
Il faut le crypté en MD5, au lieu le mémoriser en clair, il dit de le crypté et le tour est joué. En php c'est possible, j'ai vu un tas de tuto sur le net.

Je vois pas le problème de PapyJP Smiley murf
Modifié par Tintin75 (02 May 2016 - 09:12)
Merci de vos réponses
On trouve effectivement sur internet de bons exemples de cryptage MD5 en PHP, ce n'est pas vraiment ça le problème.
Le problème, c'est qu'il faut CHANGER quelque chose dans le site d'une association! Ça veut dire que les membres de l'association vont devoir changer leurs habitudes sans réelle nécessité, simplement parce que je tiens à faire évoluer la version de PHP pour ne pas rester sur une techno ancienne qui risque du jour au lendemain de n'être plus supportée.
Il est vrai que la technique actuelle présente des faiblesses, mais la nature des informations contenues dans la partie privée du site ne nécessite pas une très forte protection. La chose la plus sensible est l'adresse courriel et le numéro de téléphone des membres, mais nous savons tous hélas que ceux qui veulent obtenir ces informations y parviennent très facilement.
PapyJP a écrit :

Le problème, c'est qu'il faut CHANGER quelque chose dans le site d'une association! Ça veut dire que les membres de l'association vont devoir changer leurs habitudes sans réelle nécessité, simplement parce que je tiens à faire évoluer la version de PHP pour ne pas rester sur une techno ancienne qui risque du jour au lendemain de n'être plus supportée.

Par contre, je ne comprends pas le rapport entre le fait de devoir changer la philosophie de gestion des mots de passe et ton changement de version de PHP.
Rien ne t'empêche de toujours enregistrer en clair tes mots de passe même avec une version 73 de PHP !?
Tintin75 a écrit :
Il faut le crypté en MD5

NOOOOOOOOO ! Pas de MD5, pas de SHA1, pas de SHA256 pour des mots de passe, ce sont des méthodes de hashage beaucoup trop faibles !
La seule manière acceptable de stocker des mots de passe aujourd'hui avec PHP est la fonction native depuis PHP 5.5 password_hash(), c'est la seule !
Si tu es en dessous de PHP 5.5 il faut mettre à jour Smiley biggrin , si ça n'est pas possible, tu peux utiliser crypt() avec les bonnes méthodes de chiffrage (PHP >= 5.3).
Si tu es obligé d'utiliser une version de PHP antérieure à 5.3, tu changes d'hébergeur immédiatement.

Sinon, le processus est celui auquel tu pensais
1 - génération de mot de passe aléatoire à l'inscription de l'utilisateur (stockage du mot de passe hashé)
2 - envoi de ce mot de passe en clair (non enregistré en db) par email (avec option de délai de validité)
3 - obligation lors de la première connexion de changer de mot de passe
4 - mise à jour du mot de passe hashé en db

Mot de passe oublié :
1 - lors de la demande de re-génération de mot de passe, on demande l'adresse mail associée, on vérifie l'existence du mail
2 - enregistrement d'un token généré aléatoirement et une durée de validité en db
3 - envoi d'un mail avec un lien contenant ce token
4 - arrivé sur la page du lien on vérifie la validité du token (chaine et délai)
5 - affichage du formulaire de changement de mot de passe
J'en avais discuté avec Gordon sur un autre forum : https://forum.3wa.fr/t/procedure-mot-de-passe-oublie/221
Sinon, je n'ai pas de script tout fait et je pense que ça sera difficile de trouvé qqchose adaptable à ton besoin précisément.
J'ai une procédure sur Codeigniter, mais c'est un peu long, je vais voir pour la standardiser et l'exposer sur GitHub.
SolidSnake a écrit :

Par contre, je ne comprends pas le rapport entre le fait de devoir changer la philosophie de gestion des mots de passe et ton changement de version de PHP.
Rien ne t'empêche de toujours enregistrer en clair tes mots de passe même avec une version 73 de PHP !?

C'est un effet de bord auquel je ne m'attendais pas:
1) je demande à l'hébergeur comment faire pour passer à PHP7
2) il me répond qu'il faut migrer le site vers un nouveau serveur
3) je dis OK et il me fait la migration
4) je découvre que ce nouveau serveur n'accepte plus les mots de passe "en clair"
Je me retrouve donc dans une situation très désagréable: pour pouvoir (plus tard) passer à PHP7 je dois d'abord changer ma gestion des mots de passe!!!
MatthieuR a écrit :

NOOOOOOOOO ! Pas de MD5, pas de SHA1, pas de SHA256 pour des mots de passe, ce sont des méthodes de hashage beaucoup trop faibles !

Dans le contexte de ce site, je me moque complètement de la force du hashage.
Le principe du site, c'est qu'il y a des documents dans le site qu'on ne peut accéder que si on est membre de l'association. Actuellement c'est fait simplement en mettant dans le .htaccess du répertoire une protection par mot de passe. Lorsqu'on veut accéder à un fichier protégé par un lien vers ce fichier, c'est Apache qui vérifie les droits d'accès.
Tout ce qui passe par un mécanisme différent de la protection Apache n'est pas approprié à ce mode de fonctionnement.
Voici ce que dit la page correspondante sur le site de l'hébergeur: il s'agit de créer un fichier .htpasswd de la forme suivante:

martin:$apr1$tQqqRlvz$70soamNFTNl54OnSV.RWr.
jean:$apr1$yMWZ093W$DKAVAi5.XRx1ofwF5T..E0
sophie:$apr1$92x5vRxN$vivxTZtZfcqRmRBvL1ASF/

Ce que je veux faire, c'est créer un gérer un fichier de ce genre par PHP;
Actuellement, j'y mets les mots de passe en clair, ce que je comprends c'est qu'il faut maintenant les mettre en crypté, et je crois comprendre que l'algorithme pour ce faire est
$password = crypt($clearTextPassword, base64_encode($clearTextPassword));

Je veux bien utiliser autre chose, mais quoi?
PapyJP a écrit :
4) je découvre que ce nouveau serveur n'accepte plus les mots de passe "en clair"

Ha ha, la blague (même si ce n'est pas une mauvaise chose, loin de là).
Mais comment c'est foutu ? Comment il détecte que ces sont des mots de passe dans ta base ? Parce que ta colonne s'appelle password ?

Sinon, je plussoie avec Matthieu et son password_hash()
Modifié par SolidSnake (02 May 2016 - 11:07)
SolidSnake a écrit :

Ha ha, la blague (même si ce n'est pas une mauvaise chose, loin de là).
Mais comment c'est foutu ? Comment il détecte que ces sont des mots de passe dans ta base ? Parce que ta colonne s'appelle password ?

Sinon, je plussoie avec Matthieu et son password_hash()

Comme je l'ai expliqué plus haut, il n'y a pas de base de données dans ce mécanisme, tout juste un fichier .htpasswd qui est utilisé par le système de protection d'accès d'Apache.
Il n'est donc pas question d'utiliser autre chose que ce que Apache attend.
PapyJP a écrit :
Comme je l'ai expliqué plus haut, il n'y a pas de base de données dans ce mécanisme, tout juste un fichier .htpasswd

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah d'aaaaaaccooooord !
Ah ben, je comprends mieux d'un coup Smiley cligne
Et qu'attend Apache comme type de mot de passe hashé ?

En fait, quand ton utilisateur créer un compte ou change son mdp, tu mets à jour ton fichier .htpasswd, c'est ça ? Comment procèdes-tu pour ceci ?

Ça m'a pas l'air super pratique... tu veux pas tenter une petite gestion d'utilisateurs, ça peut être assez simple et tu auras BEAUCOUP plus de flexibilité sur les données accessibles ou pas, sur la gestion des mots de passe, la reconnaissance des utilisateurs, etc...
Tintin75 a écrit :
Il faut le crypté en MD5, au lieu le mémoriser en clair, il dit de le crypté et le tour est joué. En php c'est possible, j'ai vu un tas de tuto sur le net.

Je vois pas le problème de PapyJP Smiley murf


Le Md5 etait titre d'exemple, il y a des methodes plus performantes.

Je suis de l'avis de Matthieu sur sa solution.
MatthieuR a écrit :
tu veux pas tenter une petite gestion d'utilisateurs.

Si, c'est justement ce qu'il veut faire, pour palier son ancien système avec htpasswd.

Comme d'hab, je conseille l'excellent tuto de Grafikart, où il parle entre autre de cette gestion des mots de passe.
SolidSnake a écrit :

Si, c'est justement ce qu'il veut faire, pour palier son ancien système avec htpasswd.

J'ai pas l'impression Smiley sweatdrop , PapyJP a précisé "Il n'est donc pas question d'utiliser autre chose que ce que Apache attend."...

Je pense que ça n'est pas du tout pratique, c'est pour cela que je propose une vraie gestion d'utilisateurs en bonne et due forme.
Si c'est OK pour aller dans ce sens, en effet le tuto du très pédagogue Grafikart est une référence et permet de poser les bases.
Il y a aussi des tutos avec du code sur le net qui traite du sujet. Moi j'aime bien les tutos avec le code car ça permet de mieux comprendre car on a le code sous les yeux.

Grafikart est une très bonne méthode pour apprendre, l'explication est claire.

Courage PapyJP Smiley lol
En fait j'ai vérifié que http://www.htaccesstools.com/htpasswd-generator/ génère bien le mot de passe comme Apache le veut,
La même page dit qu'on peut le faire en PHP avec http://www.htaccesstools.com/articles/create-password-for-htpasswd-file-using-php/ mais le code qui est donné dans cette page ne donne pas le même résultat, donc ça ne marche pas.
Je suppose que ce bout de code est proche de ce que je voudrais, mais entre "proche" et "bon" il y a une ÉNHAURME différence...

Je pense que je vais faire de "l'informatique expérimentale", mais j’aimerais mieux un bout de code qui marche!
Pages :