Espace membre PHP : stockage mot de passe et email, cryptage?

WRInaute accro
Bonjour,

Je suis en train de créer un espace membre en PHP.
Pour le mot de passe, je le stocke en base mais bien évidemment pas en clair.
J'avais pensé à stocker un hash mais je trouve ça contraignant : impossible de le décoder pour le fournir de nouveau en cas d'oubli (forcé de redemander un nouveau pass).

Comment faites vous / comment font les sites pour stocker les mots de passe "brouillés" mais proposer de le recevoir par email en clair ?

Je pense partir sur une solution de cryptage avec clé. Qu'en pensez vous ?

De même, stockez vous les adresses email en clair ou cryptées ?
L'avantage est qu'il est possible de décrypter.

Je veux avant tout la sécurité de mes utilisateurs...

Merci
 
WRInaute passionné
Bonjour,

Si tu veux une option qui permette aux membres de récupérer leur mot de passe, tu n'as guère le choix.
Hormis créer ta propre fonction de cryptage/décryptage, les données seront toujours en clair ou très facilement retrouvables.

Après, y'a peu d'importances si t'es le seul à avoir accès aux bases et que tu ne laisses pas des failles béantes sur ton site :)
 
WRInaute discret
Tu continues à stocker ton mot de passe en hash et tu demandes à l'utilisateur de le recréer si jamais il l'oublie. C'est la manière la plus propre pour gérer ceci!

Une des choses que je déteste le plus au web est qu'un site m'envoie mon mot de passe par mail. Cela veut dire qu'il l'ont stocké en clair et ça ne fait pas très sérieux.
 
WRInaute accro
Haroeris a dit:
Tu génères un nouveau mot de pass et tu l'envoie par mail avant de le crypter.

Oui c'est comme ça qu'on fait. C'est souvent un hash md5 couplé avec un hash key secret. Qd le membre perd son mot de passe, jamais on ne lui donne son ancien mot de passe, vu qu'on ne le connais pas (juste la version hashée) (on va pas non plus faire un brute force) on en génère un nouveau.
 
WRInaute accro
Je viens de vérifier parmi tous les sites où je suis inscrits, effectivement crypter ne se fait plus depuis pas mal d'années visiblement. Le hash semble plus à la mode.

Je vais donc hasher le pass ++ et crypter le mail. Si quelqu'un tombe sur la base je lui souhaite bien du courage pour l'exploiter !

EDIT : quand je pense que des scripts de NL comme phpList stockent login, pass et email sans aucun hashage ni cryptage...
Un hack et c'est la blacklist SMTP immédiate.
 
WRInaute passionné
milkiway, si quelqu'un accède à toute ta base, les mots de passe hashés sera bien le dernier de tes problèmes...
 
WRInaute impliqué
Non, j'utilise un cryptage md5 + un cryptage avec clé, ce qui rend bien plus long un cassage par force brute.
On ne peut pas revenir en arrière théoriquement.
 
WRInaute impliqué
Haroeris a dit:
Non, j'utilise un cryptage md5 + un cryptage avec clé, ce qui rend bien plus long un cassage par force brute.
+1
et o peut rajouter un sleep de 5 secondes entre chaque tentative de connexion, histoire de pimenter le truc :wink: :mrgreen:
 
WRInaute impliqué
honolulu a dit:
Haroeris a dit:
Non, j'utilise un cryptage md5 + un cryptage avec clé, ce qui rend bien plus long un cassage par force brute.
+1
et o peut rajouter un sleep de 5 secondes entre chaque tentative de connexion, histoire de pimenter le truc :wink: :mrgreen:

Oui, même si il faut bien différentier les deux niveaux de protection , le md5 ne va protéger que si la base de donnée est hackée et que le pirate à récupéré la liste des mots de passe.
celui ci doit donc utiliser un force brute pour arriver a les casser.

Mais aussi indestructible que soit le cryptage, il reste bien faible si le mot de passe en lui même est simple c'est pourquoi il peut être plus rapide d'appliquer le force brute directement sur le formulaire, c'est la que en effet limiter le nombre de tentative par minute est très utile.
 
WRInaute accro
Encore une question mais sur la regénération de passe.

La procédure suivante laisse t elle une faille (fonctionnelle) ?

J'ai perdu mon mot de passe.
Je me rends sur une page où je dois indiquer mon adresse email.
Si elle est valide et qu'elle correspond bien à un compte, je reçois par mail directement un nouveau passe.
Dans ce mail, je dois cliquer sur un lien de confirmation de changement de mot de passe.
=> Je le fais, tout est validé et j'ai mon nouveau passe (en clair dans le mail, hashé et crypté en base)
=> Je ne clique pas ou je clique 48h après la demande de regénération, j'obtiens un refus

Je pose la question car parfois il faut d'abord valider qu'on a fait la demande pour suelement là recevoir le nouveau passe.
 
WRInaute impliqué
Ça me parait parfait oui, il faut juste veiller a ce que la clé de confirmation ne puisse pas être prévisible, sinon ca permettrait de changer les mot de passe d'un membre sans qu'il le veuille
 
WRInaute accro
Merci.

La clé de validation est générée comme ceci :
md5($login.'un texte inventé'.$password);

Avec login en clair et password hashé MD5 + crypté.

Comme on ne peut pas avoir deux login identiques, ça devrait le faire.

Merci.

Dans tous les cas je pense que ce topic servira ;)
 
WRInaute accro
En fait j'ai encore (encore) une question !
Que faire des personnes qui ne confirment pas leur compte. Au final, elles utilisent un pseudo pour rien.

Vous en faites quoi vous ? Suppression au bout de X jours sans validation ?
 
WRInaute impliqué
milkiway a dit:
En fait j'ai encore (encore) une question !
Que faire des personnes qui ne confirment pas leur compte. Au final, elles utilisent un pseudo pour rien.

Vous en faites quoi vous ? Suppression au bout de X jours sans validation ?


Suppression au bout de un mois
 
WRInaute accro
honolulu a dit:
Haroeris a dit:
Non, j'utilise un cryptage md5 + un cryptage avec clé, ce qui rend bien plus long un cassage par force brute.
+1
et o peut rajouter un sleep de 5 secondes entre chaque tentative de connexion, histoire de pimenter le truc :wink: :mrgreen:

5 secondes entre chaque tentative de log c'est illusoire et inutile.

Avec vous déjà essayé de brute forcer un compte via un formulaire de log online ? vous en avez pour 100 ans, donc hormis un coup de chance c'est la dernière technique que vous risquez de rencontrer (au pire lisez vos log si vous n'en êtes pas convaincu). Un simple système anti aspirateur peut bloquer ce genre d'attaque.

Le md5 n'est pas si irréversible que cela. Il existe plusieurs techniques pour les reverser. Les plus communes sont les suivantes :

- dictionaire vous allez faire tomber plus de 50% de vos utilisateurs avec ça.
- dictionnaire dérivé on va gagner environ 10% d'utilisateurs avec ça mais ça va prendre du temps (beaucoup).
- brute force. avec un programme local en C (donc rapide) vous aurez a moins de 6 caractères le mdp pas mal de résultat (souvent ceux du dico + les inconditionnels des dates) avec cette technique sur un échantillon 'réel' je trouve environ 75% de la liste en moins de 24H
- google. Les Hash md5 sont utilisés dans plein de truc pour formater des données de façon unique moralité google est un allié précieux pour trouver un Hash si on fouille un peut dans les résultats pour les interpréter.

L'ajout d'une salt key est souvent illusoire. Il faut comprendre que si votre base est tombée au point qu'on ai les Hash, on aura aussi la salt key, ou aussi l'ago de 'masquage' donc on retombe dans le cas classique de reverse ci dessus.

C'est donc la base qu'il faut blinder au travers du logiciel qui l'utilise (le site, vos scripts) et faire confiance a son hébergeur pour que le filtrage se fasse bien au niveau de l'accès du serveur SQL.

Pour les communication de MDP par mail, c'est sans solution a ma connaissance vue que le mdp va forcement transiter en clair. Mais, combien de site offrent une connection https sur leur formulaire de login ? Donc le reniflage est toujours la meilleur des solutions.

Que faire des personnes qui ne confirment pas leur compte. Au final, elles utilisent un pseudo pour rien.
Moi je laisse si je n'ai pas de souci de place ça empêche une nouvelle inscription avec le même pseudo.

Ça me parait parfait oui, il faut juste veiller a ce que la clé de confirmation ne puisse pas être prévisible, sinon ca permettrait de changer les mot de passe d'un membre sans qu'il le veuille

ça je comprend pas l'utilité (confirmer un changement de pass) :
- si tu est le proprio légitime du compte tu aura le mail donc le nouveau pass donc pas de souci.
- si tu n'est pas le proprio légitime du compte mais que tu as deviné le mail qui sert de login (voir le pseudo) alors tu pourra changer le pass mais soit tu as la boite et la confirmation est inutile, soit tu ne l'a pas et c'est le proprio légitime qui sera informé du changement..

pour l'inscription en revanche ... normal et oui effectivement appliquer un algo perso pour crypter l'url de confirmation est une bonne idée perso j'utilise une date dans la chaîne (super précise donc non prédictible)
 
WRInaute accro
zeb a dit:
ça je comprend pas l'utilité (confirmer un changement de pass) :
- si tu est le proprio légitime du compte tu aura le mail donc le nouveau pass donc pas de souci.
- si tu n'est pas le proprio légitime du compte mais que tu as deviné le mail qui sert de login (voir le pseudo) alors tu pourra changer le pass mais soit tu as la boite et la confirmation est inutile, soit tu ne l'a pas et c'est le proprio légitime qui sera informé du changement..
Merci pour ton intervention.

En fait, un jour j'ai tout simplement eu un robot qui s'est excité à demander pour des millions d'adresses mail un nouveau mot de passe.

Si tu ne fais pas de confirmation, un beau jour tu veux te confirmer et on te dit que tes identifiants ne sont pas valables, pas cool!
 
WRInaute impliqué
zeb a dit:
ça je comprend pas l'utilité (confirmer un changement de pass) :
- si tu est le proprio légitime du compte tu aura le mail donc le nouveau pass donc pas de souci.
- si tu n'est pas le proprio légitime du compte mais que tu as deviné le mail qui sert de login (voir le pseudo) alors tu pourra changer le pass mais soit tu as la boite et la confirmation est inutile, soit tu ne l'a pas et c'est le proprio légitime qui sera informé du changement..

pour l'inscription en revanche ... normal et oui effectivement appliquer un algo perso pour crypter l'url de confirmation est une bonne idée perso j'utilise une date dans la chaîne (super précise donc non prédictible)


Il faut quand même être prudent pour éviter un changement massif des mots de pass des utilisateurs.
Tout le monde ne lit pas ses mails, et parfois les mails ne sont plus valides pour les vieux comptes.
 
WRInaute accro
Il faut quand même être prudent pour éviter un changement massif des mots de pass des utilisateurs.
Tour le monde ne lit pas ses mails, et parfois les mails ne sont plus valides pour les vieux comptes.
peut être restreindre cette fonctionnalité par IP et par jour .
 
WRInaute accro
C'est une excellente idée. Merci pour toutes ces interventions constructives.

Si vous avez quelque part un ensemble de scenarii de tests, ça m'intéresse beaucoup.
L'air de rien, il commence à y avoir un paquet de situations à tester.
 
Discussions similaires
Haut