Bonjour
 
Je suis en train de développer un site web avec espace membre. Je me pose des questions (peu être un peu trop ?) sur la sécurité du couple identifiant/motdepasse.  
 
1) le stockage du mdp : vous le cryptez ? ou vous le laissez en clair en base ?  
2) en cas de perte de l'identifiant et du mot de passe, quelle est la meilleure stratégie pour renvoyer ces informations à l'utilisateur ?  
- lui demander son adresse email et renvoyer le tout dans un email ? Beaucoup de sites font ça (hardware.fr ou ma mutuelle santé par exemple). J'y vois une faille : identifiant et mdp dans le même email. Ca me paraît pas terrible. Mais peut être que c'est la solution.  
- lui envoyer 2 emails séparés ? l'un avec le pseudo , l'autre avec le mdp ? Pour ne pas faire d'association entre les ces 2 informations.  
- gérer un système de question/réponse secrète (du style le nom de famille de ma femme) ? Pour mettre un niveau de sécurité supplémentaire ?  
- systématiquement envoyer un nouveau mot de passe ? (de toute façon si il est crypté en base, normalement y a pas moyen de le décrypter, donc faut en recréer un systématiquement)
 
Bref vous lisez : pas mal d'interrogations. Quelle est la meilleure stratégie ? J'ai cherché sur google, j'ai pas trouvé mon bonheur.  
 
Merci pour vos suggestions et retours d'expérience.  
Dominique
 
 

 
N'ya-t'il pas uen section Programmation ?
 

 
Hashé en md5, voire sha1.
 

 
Pour le renvoyer, il faut soit le stocker en clair, soit utiliser un cryptage réversible. Si tu le hash, il faudra en recréer un à la demande.
Si tu ne veux pas envoyer l'identifiant et le mot de passe, tu demandes l'adresse ET l'identifiant, mais ça pose problème lorsque l'on a oublié l'identifiant....
 

 
Si l'e-mail est piraté, il suffit de lrie les 2 mails, donc aucune sécurité.
 

 
Voir plus haut

Ce sujet a été déplacé de la catégorie Windows & Software vers la categorie Programmation par Je@nb

Pour mes applis que je développe depuis plusieurs années, j'ai une adresse mail, un identifiant et un mot de passe, tous les 2 hashés en md5.
En cas de perte, l'utilisateur rentre son adresse mail, je vérifie que l'adresse mail existe dans ma BD, je réinitialise l'identifiant et le mot de passe que j'envoie par mail. Charge à l'utilisateur après coup de modifier à sa convenance l'identifiant et/ou le mdp.
 
Le chiffrement (que t'appelles cryptage, mais c'est pas le bon terme en fr), ça permet certes la réversibilité, mais ça pose le pb du stockage de la clé Le hash, c'est plus simple à mettre en oeuvre et en plus, ça garantit aux utilisateurs qu'un admin indélicat ne pourra pas découvrir leur identifiant/mdp (sauf si l'utilisateur met un identifiant/mdp trop "faible" et qu'on le trouve via une rainbow table, mais là, c'est de la faute à l'utilisateur...).

Un hash md5 ou sha-1, c'est à peine mieux que de stocker un mot de passe en clair. Avec l'augmentation de puissance des ordinateurs, un hash md5 d'un mot de passe de 6-10 caractères se crack en quelques minutes par force brute.
 
Il existe des fonctions écrites exprès pour le stockage de mot de passe. Fais une recherche sur "PBKDF2", "bcrypt" ou "scrypt", ce sont des fonctions prévues pour ça, et il en existe des implémentations dans la plupart des langages.

Si t'es assez malin tu n'utilises pas la fonction brute de décoffrage, mais une combinaison de transformations que seule ton appli va utiliser.  
 
Comme cette combinaison est spécifique à ton appli, la probabilité que des rainbow table (dictionnaires) soient publiées sur le net tend vers 0.
 
genre : hash1(hash2('toto')) ou hash1('toto').'salt'.hash2('toto')
 
Du coup je suis pas sûr que casser des clés de 512 à 4096 bits soit si facile que ça.

 
NON ! En matière de sécurité, c'est une des pires conneries à faire ! On améliore rarement la sécurité en mélangeant des algos au hasard, c'est même généralement le contraire.
 
Il vaut 100 fois mieux utiliser une solution éprouvée, comme les algos que je cite plus haut pour le cas présent. Ils ont été conçus par des gens qui s'y connaissent vraiment, et ont été suffisamment étudiés pour qu'on connaisse assez précisément leurs forces et leurs faiblesses.

Après, faut voir aussi la criticité de l'appli et quels genres de pirates sont susceptibles de t'attaquer. Ils sont pas tous super forts et si y'a pas d'argent à faire directement ou indirectement en t'attaquant ton appli, ça va pas trop les intéresser... J'ai rarement entendu que le site web du club de tricot de Corrèze c'était fait hacker ça BD de membres...

 
Mauvais raisonnement.
 
Peu importe l'importance des données du site lui-même, un pirate va chercher à récupérer des logins. Les utilisateurs étant en majorité pas très malins, ils ont tendance à réutiliser les même mots de passe un peu partout. Du coup, si j'arrive à obtenir des infos de la bd de membres du club de tricot de Corrèze, il y a bien des chances que ça me donne accès à beaucoup plus de choses, autrement plus critiques (comptes Facebook ou email, par exemple)
 
C'est pas un cas théorique ça, j'ai vu une base de données d'un site de fan de Twilight (pas un truc super critique, donc) être utilisée comme point de départ d'une attaque beaucoup plus importante.

On se se pose jamais assez de questions sur la sécurité
Le mieux est de s'inspirer de sites un peu sérieux (j'entends par la professionnels et éprouvés niveau sécurité)
Un guide pour t'aider : http://stackoverflow.com/questions [...] entication
Edit : pour la fonctionnalité mot de passe perdu, je préfère quand même que le site envoie un lien à durée limitée à l'adresse email vérifiée lors de l'inscription. Ce lien permet alors de redéfinir directement le mot de passe sur ton site, le tout en https bien sur.

Hello
Pour ma part, sha1 + salt généré aléatoirement.
Lors d'un oubli de mdp, l'utilisateur reçoit un lien par email qui lui fait modifier le mot de passe.

 
On a effectivement un point de divergence.    
 
Ce qu'il faut bien comprendre avec les hashs, c'est qu'ils s'apparentent à une fonction de cryptage à sens unique, dépourvue de clé privée.  
Et ça, c'est une énorme faille de sécurité.
 
Dans le cas d'un cryptage à clé privée, connaitre la fonction cryptage importe finalement peu, puisque tout repose sur un élément secret à savoir la clé privée. Dans le cas du hash, il n'y a pas d'élément privé. Connaitre la fonction de hash revient à connaitre toute la logique de transformation.  
 
Le nombre de fonctions de hash disponibles est ridiculement limité (41 avec php). Utiliser un hash brut de décoffrage revient donc à utiliser une fonction de cryptage avec une clé privée ne pouvant prendre qu'une quarantaine valeurs différentes...  
 
C'est pourquoi les hashs ne sont pas, contrairement à une croyance populaire, irréversibles.
 
Les rainbow tables (ou dictionnaires) permettent de retrouver instantanément le mot originel à partir de son empreinte hashée, pour peu qu'elle ait été référencée. Il suffit de faire tourner en boucle un générateur de password et de stocker dans une table le couple pass=>hash, puis de proposer une IHM qui à partir du hash va retrouver le pass. C'est un développement accessible à n'importe quel newbie, je codais déjà des algos comme ça quand j'étais en 3ème.
 

 
Voir la définition d'une Rainbow Table :
http://en.wikipedia.org/wiki/Rainbow_table
 
Aujourd'hui, chaque algo de hash dispose de plusieurs rainbow tables sur Internet.
Certains services online proposent jusqu'à 750 000 000 de hashs pré-computés.
 
La pire chose que tu puisses faire en matière de hash est d'utiliser un algo de hash standard.    
 
Le meilleur algo de hash, c'est celui que personne ne connait.
Donc, un algo de hash custom et/ou avec un grain de sel (salt).
 
CQFD.  
 
 
Après, tu peux effectivement utiliser une fonction de cryptage et non une fonction de hash, mais dans ce cas tu t'exposes aux foudres de la CNIL (dès lors que des informations sensibles peuvent être décryptées).

Sur le plan théorique, tu as raison. Cela dit, une table de 750 000 000 de hashs pré-computés, si c'est certes beaucoup de combinaisons, on est loin de ce qu'il faudrait pour trouver tous les mdp.
 
Si on se limite à des mdps avec des minuscules/majuscules/chiffres, ça fait un jeu de caractères possibles de 62 caractères (26 minuscules, autant de maj et les 10 chiffres). Avec une mdp de juste 6 caractères, ce qui est faible aujourd'hui, on est déjà à 56 800 235 584 combinaisons, ce qui est très loin de tes 750 millions de hashs
 
Perso, j'ai pas trouvé une table de hash qui avait mon mdp, ce depuis 9 ans...
 
Alors, si tu rajoute dans ton mdp des caractères spéciaux, des espaces et des accents, je te dis pas le nb de combinaisons que ça fait en plus rien qu'avec 6 caractères...
 
Edit : même en se limitant aux minuscules et les 10 chiffres, soit 36 caractères, un mdp de 6 caractères fait quand même 2 176 782 336 combinaisons..[table][tr][td]
[/td][/tr][/table]

Certes, mais ton mot de passe de RoXxoR / HaKerZ, ce sera rarement celui de madame Michu. La pauvre dame utilisera une date de naissance, 123123 ou pouet !
 

 
 
http://bigbrowser.blog.lemonde.fr/ [...] -internet/
 
L'espace adressable n'emporte (malheureusement) pas l'espace occupé

C'est pourquoi il faut utiliser un sel lorsqu'on hash le password... Et là tes tables, bein elles servent à rien
Et surtout, utiliser une fonction de hash que personne ne sait reverser, et surtout pas je ne sais quel assemblage de fonctions faites dans son coin

Cyberdenix : tu ne sais absolument pas de quoi tu parles.  
 
Honnêtement, j'ai qu'une chose à te dire : tu ferais mieux de la fermer au lieu d'étaler ton incompétence en donnant des conseils dangereux. Tout ton message, c'est absolument n'importe quoi. Ce que tu proposes, c'est de la sécurité par l'obscurité, et s'il y a une chose à retenir de ce genre d'approches, c'est que ça ne marche pas.
 
Pour stocker correctement ses mots de passe de façon sûre sans se prendre la tête : https://gist.github.com/3707231

Non.

Ce qui est sans importance, les fonctions de hachage dédiées aux mots de passe le prennent en compte

Cette déclaration n'a strictement aucun sens.
 

Et celle ci est tout simplement fausse, pouvoir brute-forcer un cleartext ne signifie pas que la fonction est réversible.

C'est aussi quelque chose qui peut être trivialement mitigé via un sel aléatoire. Sel aléatoire que toutes les fonctions de hachage de mot de passe (pbkdf2, bcrypt, scrypt) non seulement supportent mais génèrent et appliquent par défaut si on ne leur demande rien.

Non, tu n'auras pas de RT pour bcrypt ou scrypt parce que ça n'a aucune valeur: ces fonctions génèrent automatiquement 48 bits ou plus de sel aléatoire par mot de passe, une RT est sans intérêt aucun.

C'est du grand n'importe quoi, la pire chose que tu puisses faire en matière de crypto c'est ton petit bazar perso sans rien connaître ou comprendre au domaine, ça assure principalement que ton truc sera complèment pêté et qu'un mec un peu malin pourra passer à travers en 10mn.

Bravo, cette seule déclaration the qualifie comme cryptographiquement incapable, l'un des principes au coeur de la cryptographie est justement que même si l'algorithme est connu et public il doit être résistant, si ton truc ne tient que tant que le tiers ne connait pas l'algo, il ne sert à rien.

Cette barre de rire quand même les posts de merde plein d'assurance de Cyberdenix

Histoire d'en remettre une couche :
http://crackstation.net/hashing-security.htm
http://codahale.com/how-to-safely-store-a-password/
http://stackoverflow.com/questions [...] words?lq=1

Et la liste est longue.

Merci pour la découverte de ce topic.
Le mec est encore en 2007 on dirait, le moment où il a découvert les rainbow table juste avant qu'elles ne deviennent obsolètes grâce aux CG de oufs roxor qui permettent de bruteforcer les algos peu cher.

Pas exactement obsolètes, mais elles sont relativement simples à mitiger avec un simple sel (sel que tout le monde n'utilise pourtant pas, cf leak LinkedIn où les mdp étaient du sha1 non salté)

Pour bien montrer la puissance de la chose, voici un exemple:

Ce sont des millions de hash par seconde, donc une simple carte dispo dans le commerce à 600€ permet de tester 10 milliards de mdp/s en md5. Et ça augmente linéairement avec le nombre de cartes/machines.

Et il est important de noter que le "brute-force" ne signifie pas "stupide", un brute-forcer moderne ne commence pas à "a" pour itérer sur tous les caractères, puis ajouter un caractère de plus et tout re-tenter. À la place, ils partent d'un dictionnaire (customisé pour le site) — d'où le danger des bases de MDP leakées, parce qu'elles donnent le genre de mdp existant dans le monde réel et permettent donc de customiser la recherche en fonction de données effectives — puis appliquent divers patterns de recombinaison et substitutions. Pour une démonstration du genre de trucs dont on parle, https://community.qualys.com/blogs/ [...] -passwords

Pour appuyer le fait que plus le temps passe et les bdd tombent et plus les dictionnaires s'améliorent : http://arstechnica.com/security/20 [...] r-assault/

Putain mais ouais, c'est évident quand tu y réfléchis 2 secondes mais ça m'avait jamais frappé (en plus, mon MDP de l'époque avait dû être bien leaké ; heureusement que j'utilise KeePass depuis le début de l'année...)

C'est pas si vieux que ça, parce qu'idéalement il faut un dico de départ utile et mettre en place les algos de substitutions. Cf Volkhen qui retrace l'histo de l'approche.

J'ai un peu lu tout ça et suis tombé de lien en lien sur http://blog.agilebits.com/2011/06/ [...] passwords/
Vous utilisez quelle technique ? Perso j'ai un master password pas exceptionnel (10 caractères alphanum) mais difficile à trouver ; j'hésite à passer sur un truc type "diceware".

EDIT : c'est HS avec le reste du topic mais bon

 
Avec KeePass j'ai pas cette contrainte.
Tu peux définir un load factor pour ton fichier, ce qui rend le bruteforce très compliqué.
Faut 2 secondes pour décrypter la db sur mon PC.

Ba j'utilise KeePass aussi mais j'avais pas vu le load factor (dans Database Settings, c'est ça ?)

EDIT : après, c'est config-dépendant. Le gars qui chope ta DB et qui a 3 ou 4 CG en SLI/CrossFire avec lui, il s'en foutra un peu de ton load factor

 
Pas vraiment. Le load factor, ça augmente le temps de calcul de façon exponentiel, ajouter du hardware, ça le diminue de façon plus ou moins linéaire.

 
Oui c'est config-dependant, mais c'est pareil avec tous les systèmes de loadfactor à ma connaissance.
Et ça a quand même un impact sérieux

perso j'ai un master de 14c, qui ne m'est pas lié (c'est juste une phrase que j'ai gardé). Tous les mdp autres je les fait générer par keychain en 24c.

24c t'y vas quand même Y a des sites (me souviens pu lesquels) qui font chier quand tu dépasses genre 12c ou 16c...
Perso je scotche à 15, ça me va

C'est le même prix, chuis juste trop feignant pour pousser le slider plus loin

Je résous le problème en allant ailleurs

Site de la sécu. Uniquement des chiffres, pas trop et qui ne soit pas ta date de naissance histoire de faire croire qu'il y a de la sécurité.
Il faudrait faire fusiller toute la chaîne des gens responsables de cela.

Cela dit, y'a pire : http://korben.info/savoir-trouver- [...] anque.html
Apparemment, on peut faire "sauter" les serveurs vocaux des banques avec qq mots bien choisis et y'aurait pas de protection