+ Répondre à la discussion
Affichage des résultats 1 à 12 sur 12
  1. #1
    Invité régulier
    Inscrit en
    novembre 2009
    Messages
    54
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 54
    Points : 8
    Points
    8

    Par défaut Authentification + Salt ?

    Bonjour à tous,

    J'essaie de comprendre le principe de l'application d'un "salt" comme mesure supplémentaire de protection lors de l'authentification.

    J'ai lu des explications sur ce site : http://www.opensecuritylab.org/stori...ng-salt-in-php

    Mais je ne comprend toujours pas en quoi ce système sécuritaire.

    Suppossons une table

    Utilisateur
    MotDePasse
    Salt


    Mon utilisateur écrit le mot de passe : ABCDE

    Je lui applique après un salt disons : '123456789987654321';

    Ce qui me donne comme chaîne : ABCDE123456789987654321

    Ce qui donne bien entendu, un hashing différent de ABCDE, mais dans ma validation qui valide si l'utilisateur / mot de passe est bien le bon, je vais quand même recevoir le mot de passe ABCDE, lui appliquer le Salt sauvegarder en mémoire pour comparer les hash non ?

    Donc si un script essaie avec un dictionnaire, la chaine ABCDE. Ma validation, va considèrer comme correct le mot de passe.... Non ?

    Merci d'éclairer ma lanterne, car je voudrais bien améliorer la sécurité de mes usagers mais je ne comprends bien cette méthode....

  2. #2
    Invité de passage
    Inscrit en
    juillet 2010
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : juillet 2010
    Messages : 22
    Points : 4
    Points
    4

    Par défaut

    Je suis pas sûr d'avoir compris ce que tu demandes, mais si effectivement quelqu'un fournit le mot de passe correct, l'authentification va marcher...
    L'intérêt du rajout de "sel" réside dans le fait que si un attaquant récupère le hash du mot de passe (via par exemple une SQLi), il aura beaucoup plus de peine à retrouver le mot de passe : les tables qu'on peut trouver sur le net permettent souvent de retrouver un mot de passe "simple" à partir d'un hash, mais là tu complexifie la tâche puisque ton mot de passe n'est plus si simple.

    Une protection supplémentaire souvent utilisée je crois, est de composer deux hachages successifs avec du sel.
    $hashed_passwd = sha1($salt.sha1($salt.$passwd));

    en espérant avoir pu aider

  3. #3
    Invité régulier
    Inscrit en
    novembre 2009
    Messages
    54
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 54
    Points : 8
    Points
    8

    Par défaut

    Sauf que je ne comprend toujours pas à quoi ça sert.

    Si le pirate voit le hash du mot de passe. C'est qu'il a réussit à lire ma B.D.

    Donc, c'est pour évider que, si l'utilisateur utiliser le même mot de passe ailleur, que le pirate puisse lui voler ses informations sur les autres sites ?

    Ça n'empêche donc pas les attaques par dictionnaire via le login form ?

  4. #4
    Expert Confirmé Sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    24 349
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 24 349
    Points : 34 763
    Points
    34 763

    Par défaut

    C'est ça.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  5. #5
    Expert Confirmé Sénior

    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2010
    Messages
    2 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2010
    Messages : 2 700
    Points : 4 617
    Points
    4 617

    Par défaut

    Citation Envoyé par JonathanMQ Voir le message
    Ça n'empêche donc pas les attaques par dictionnaire via le login form ?
    Non effectivement le salt rend le piratage plus difficile à beaucoup de niveaux, mais pas à celui-ci. La protection contre une soumission massive de mots de passe à ton formulaire relève d'autres pratiques.
    - Réalisations
    - Interface graphique : génération en javascript d'objets défilants, texte et/ou images, mode horizontal ou vertical.

  6. #6
    Responsable Qt


    Avatar de dourouc05
    Homme Profil pro
    Étudiant
    Inscrit en
    août 2008
    Messages
    19 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 19 689
    Points : 77 624
    Points
    77 624

    Par défaut

    Certains prétendent que les mots de passe doivent être protégés à tous les coups : même dans le pire cas (c'est-à-dire que le pirate a accès à tout ton code et à toute ta base de données), il ne peut pas pouvoir les retrouver (sauf utilisation de rainbow table, de force brute, etc.). C'est à ça que servent les grains de sel : les mots hashés sont beaucoup plus long, on trouvera plus difficilement leurs équivalents en rainbow table, ça prendra plus de temps pour lancer une procédure de force brute (vu qu'on sera sûr d'une borne minimale sur le nombre de caractères : le nombre de caractères minimal imposé sur le mot de passe plus le nombre de caractères du sel, soit une belle progression pour un hash de trois caractères pris dans l'ASCII sept bits, 127^3 fois plus de mots à essayer).

    Maintenant, si tu utilises une fonction cryptographique qui est devenue très faible au fil du temps à cause de la cryptanalyse, pour lesquelles on peut utiliser d'autres techniques, plus efficaces, que la force brute, utiliser un sel ne sert plus à grand-chose, vu qu'un pirate bien équipé arrivera sans grand problème à retrouver les mots de passe ; seule solution : ne pas utiliser ce genre de fonctions cryptographiques. Exemples : MD5, SHA1. Pour trouver cette information, Wikipedia est en général une bonne source.

    Pour l'application de plusieurs couches de fonctions de hashage sur un même mot, ça semble une bonne piste selon Wikipedia : http://en.wikipedia.org/wiki/Hash_chain. Il me semble que cette technique est également utilisée par OpenXML, le format de fichier d'Office 2007 et suivants.

    Pour se protéger des attaques par dictionnaire, je ne vois pas mieux que les protections plus générales contre la force brute : une pause d'une seconde ou une demie seconde avant de tester s'il y a correspondance des mots de passe, ça évitera d'avoir des milliards d'essai par seconde (une fois que le pirate a remarqué ça, il peut passer en parallèle, il suffit alors de bloquer le nombre de connexions possibles en simultané depuis une IP... mais c'est plus dur à implémenter). Une solution très utilisée est de mettre en mémoire toutes les tentatives infructueuses : tu en autorises cinq, par exemple, toutes les heures. Ou bien tu mets un temps d'attente avant validation du mot de passe côté PHP qui augmente avec le nombre d'essais (selon une loi exponentielle, de préférence), comme c'est parfois utilisé pour les codes des autoradios.
    Vous souhaitez participer aux rubriques Qt ou PyQt/PySide (tutoriels, FAQ, traductions, sources) ? Contactez-moi par MP.

    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  7. #7
    Membre régulier
    Inscrit en
    mars 2003
    Messages
    136
    Détails du profil
    Informations forums :
    Inscription : mars 2003
    Messages : 136
    Points : 81
    Points
    81

    Par défaut PBKDF2 la solution miracle ?

    Bonjour,

    Cela fait plusieurs mois que j’essaie de cherche l'etat de l'art en sécurité notamment pour le cryptage des mots de passes.

    Voila les problèmes de sécurités pour les mots de passes :

    -Le mot de passe ne doit pas être décryptable. La raison est que souvent les utilisateurs utilisent leur même mot de passe pour plusieurs sites. Il faut éviter que si un hacker décrypte le mot de passe utilisé sur un petit site puisse utiliser le même mot de passe pour se connecter au compte en banque de ce même utilisateur. Pour cela, il faut utiliser une fonction de hash.

    -Si un hacker récupère la liste des mots de passe, il peut utiliser un table qui lui donne pour chaque hash le mot de passe correspondant. Ces tables se base sur un salt particulier. Pour contourner ce système, il faut saler le mot de passe en utilisant un salage différent pour chaque utilisateur. Le salage n'a pas besoin d'être secret. Il peut être stocké en claire dans la base de donnée. Il n'est pas nécessaire de régénérer le salage si l'utilisateur change de mot de passe. Avec cette technique, cela oblige l'attaquant à soit attaquer par force brute, soit tester par dictionnaire.

    -Pour éviter les problèmes d'attaque par dictionnaire, il faut mettre des règles sur les mots de passe, du style "minimum 3 lettres et 9 chiffres", ou "pas le mot admin, ni le même mot de passe que le login".

    -Ensuite, pour contrer la force brute, il reste à utiliser une méthode de hachage. Quel est la meilleur méthode de hachage ? Certains disent que c'est SHA256 ou SHA512. J'ai découvert grâce au magasine programmez.com que c'est PBKDF2. Il est utiliser par WPA, et par les iphone. C'est une méthode de hachage par itération. Il prend un algorithme de hachage, disons SHA1, et il rehache plusieurs fois. Le but c'est de ralentir le cryptage. Par exemple WPA fait 4096 itérations. Iphone fait 10.000 itérations. Le nombre d’itération dépends du temps de calcul de la machine pour calculer la fonction de hachage pour le processus d'identification. J'ai fait un essai pour comparer sha512 et PBKDF2 avec 4096 itérations. sha512 met 1 millisecondes, et PBKDF2 50 millisecondes. Autrement dit, un hacker mettra moins de temps pour calculer une table de hachage avec SHA512 que PBKDF2. (En 2010, le FBI n'a pas réussi a décrypter un disque dur qui utilisait ce type de cryptage).

    Après, il y a comment sécuriser l'envoie du mot de passe du navigateur jusqu'au serveur (même cryptage que la base de donnée, cryptage asymétrique, SSL, ...), comment stocker une clef privé de façon sécurisée pour décrypter le mot de passe de la base de donnée.

    Je ne comprends pas pourquoi il n'y a pas un endroit sur internet qui explique une fois pour toute ses règles, et d'autres que je ne connait pas.

  8. #8
    Responsable Qt


    Avatar de dourouc05
    Homme Profil pro
    Étudiant
    Inscrit en
    août 2008
    Messages
    19 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 19 689
    Points : 77 624
    Points
    77 624

    Par défaut

    Le problème de PBKDF2 est expliqué sur Wikipedia : http://en.wikipedia.org/wiki/PBKDF2#...ives_to_PBKDF2. On peut l'implémenter sur des circuits programmables (CPLD, FPGA, ASIC, selon les moyens) ou sur GPU et avoir quand même d'excellentes performances. D'où scrypt http://www.tarsnap.com/scrypt.html. Bon, maintenant, ça fait franchement cher en temps de calcul pour l'utilisateur lambda, il faut relativiser avec les données à protéger (soit deux tours de SHA512 avec grain[s] de sel, ça procure déjà une sécurité bien plus grande que la majorité des sites codés par des amateurs) : pour un petit site avec quelques dizaines d'utilisateurs, je ne pense pas qu'il soit utile d'y aller franchement, ça ne fait pas beaucoup de mots de passe récupérables ; pour une banque, un grand site, là, c'est différent (et les moyens disponibles pour l'implémentation seront largement supérieurs, ce qui permet plus de folies).

    Sinon, tu parles de crypter... Le principe de base est justement de ne jamais crypter un mot de passe : on ne veut pas le récupérer, d'aucune manière que ce soit. On veut juste le hasher, en obtenir une information que l'on peut comparer, qui contient toute l'information du mot de passe mais sans moyen direct de le retrouver.
    Vous souhaitez participer aux rubriques Qt ou PyQt/PySide (tutoriels, FAQ, traductions, sources) ? Contactez-moi par MP.

    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  9. #9
    Expert Confirmé Sénior

    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2010
    Messages
    2 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2010
    Messages : 2 700
    Points : 4 617
    Points
    4 617

    Par défaut

    Citation Envoyé par tulipebleu Voir le message
    Après, il y a comment sécuriser l'envoie du mot de passe du navigateur jusqu'au serveur
    Et c'est le plus important. Pirater une base de donnée nécessite soit une grosse faille de sécurité (le mot de passe d'accès qui traine sur le bureau ou dans un fichier trop facilement accessible dans l'ordinateur ou... un ordi infesté par un keylogger...) ou sinon avoir une complicité niveau serveur pour pirater la bdd. Ce n'est donc pas toujours réalisable.

    Par contre ce qui est beaucoup plus facile est de sniffer les tuyaux du web. La première des sécurités est donc de ne jamais transmettre les mots de passe en clair sur le web.
    - Réalisations
    - Interface graphique : génération en javascript d'objets défilants, texte et/ou images, mode horizontal ou vertical.

  10. #10
    Expert Confirmé Sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    24 349
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 24 349
    Points : 34 763
    Points
    34 763

    Par défaut

    La grosse vulnérabilité au sniffage de nos jours, c'est que la plupart des e-mails sont transmis en clair. Y compris ceux de la fonction "j'ai oublié mon pass, générez-en un et envoyez-le moi par mail"...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  11. #11
    En attente de confirmation mail
    Homme Profil pro
    Inscrit en
    février 2013
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : février 2013
    Messages : 35
    Points : 27
    Points
    27

    Par défaut

    Bonjour ça serais pour gueuler un peu

    Hacker == bidouilleur != pirate, okey ?
    cryptage ça n'existe pas dans notre langue, d'ailleurs, c'est même pas du chiffrement (qu'il soit symétrique ou asymétrique) c'est du hashage!
    On obtient donc une "empreinte" d'une données et en réprésentant de nouveau la donnée on peux la comparer avec l'empreinte pour savoir si l'entré SEMBLE être identique.
    Et bien oui, désolé, je casse votre délire, mais c'est la vérité, on n'est pas sur que ça soit le vrai password. Pourquoi ?
    En entrée, vous founisez une chaine de caractère de longueur variable entre 1 et l'infini, ce qui nous fait un nombre de possibilité infini, on est d'accord ?
    et pourtant vous récuperer quoi à la fin ? une chaine de caractère de longueur FIXE!! Il n'y a pas un truc qui vous gène ? et bien si! toutes les combinaisons (de l'ordre de l'infini :p ) ne PEUVENT PAS avoir chacune une empreinte identique, c'est IMPOSSIBLE!
    Cela s'appelle une collision, et les algorythmes qui commence à dater permettent de générer des colisions assez facilement, et http://en.wikipedia.org/wiki/Hash_chain facilite encore plus les choses ! De plus il existe des bdd de reverse hash de md5(md5())

    Il faut donc se tourner vers des algo comme sha256 ou wirlpool et utiliser un sel.
    Mais savez vous qu'il existe différents types de sel ?
    la plupart des gens utilise un sel statique et c'est suffisant, mais si deux utilisateurs ont le meme hash, le cracker sait que la probalité que ce password soit "fort" (cad résistant au brute-force) est faible, et qu'en plus, il auras accès à deux comptes!
    donc il serais préférable d'utiliser un sel dynamique, dont la valeur est propre (ou du moins non constant ) à chaque utilisateur comme le timestamp d'inscription.

    De plus, limiter le brute-force dans une application en réseau, c'est comment dire... un peu inutile. Vous avez déjà essayer de coder un brute-force en python/c/php ou autre ? Personnelement j'ai déjà fait dans les trois languages, c'est lent (ok, ça reste du CPU, et à l'heure actuelle les crackers utilisent le CPU/GPU qui offre des performances nettement supérieur, sans compter la mise en réseau de la puissante de calcul de plusieurs pc, voir l'utilisation des ressources d'un botnet) mais tout cela reste dépendant d'un facteur : le lag, et oui, une connexion http est beaucoup plus lente qu'un accès disque (je parle meme pas de sdd, ou de ram) mais bien sur, si l'utilisateur as "password" comme mdp, ok, il vas se faire b****

    La sécurité informatique me passionant et ayant acquéris quelques connaisances, voilà les conseils pour ceux qui ont peur du piratage des mdp :
    -Déjà pensez qu'il y a pire comme faille à corriger avant de pensez à ça.
    -Banniser le md5! peu importe le type de hash, il existe des centaines de bdd reverse hash et depuis le temps, elles sont pleines à cracker.
    -Calculer la "robustesse" d'un mot avant son entrée dans la bdd (cela as également l'avantage de faire de la prévention sur la sécurité sur internet à vos membres peu regardant sur l'originalité de leur password, il y a meme des books de password si vous voulez que je vous les file) il existe des site qui le font par exemple http://www.howsecureismypassword.net/ (c'est du js mais c'est pour le principe)
    -Eviter sha1 pour les memes raisons que md5, mais c'est acceptable avec un bon sel
    -Utiliser un sel dynamique
    -Préférez les autres variantes de sha ou whirlpool. (avec un sel dynamique bon courage pour trouver un seul mdp
    -Se connecter avec le couple email/password (deux inconnues valent mieux qu'une, et si l'email est connu, ça ne retire rien de la sécurité)
    -NE METTEZ JAMAIS CECI DANS UN SYSTEME DE CONNEXION : sleep(1) (cela utilise de la mémoire vive, et un pirate peut très facilement geler votre système)
    -Limiter les connexion PAR IP et JAMAIS par compte (sinon, un pirate qui tente de se connecter à chaque compte, bloque tous votre site :p )
    -Obliger un changement de mdp tous les x mois.
    -Pour la fonction "mdp oublié" cela reste un problème... car on considère trop vite qu'elle est seulement accesible à l'utilisateur, alors qu'un pc compromis, c'est openbar, et pour cela je n'ai pas de solution.

    Voilà, si vous avez des questions, n'hésitez pas

  12. #12
    Expert Confirmé Sénior

    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2010
    Messages
    2 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2010
    Messages : 2 700
    Points : 4 617
    Points
    4 617

    Par défaut

    Je profite de la réactualisation de ce post, pour proposer ce lien qui fourni un exemple complet pour protéger les mdp lors de leur transfert dans les tuyaux du web.

    Il s'agit, à l'aide d'un sel dynamique concaténé au mdp puis hashé côté client avant son envoi, de rendre inexploitable le post qu'un pirate pourrait sniffer sur le réseau. On peut aussi augmenter la protection en concaténant également le login au mpd et au sel avant hashage.

    C'est pas nouveau mais pas difficile à mettre en place et ça offre une protection intéressante pour ceux qui n'utilisent pas SSL, et pour ceux qui utilisent SSL cela peut servir de protection complémentaire au cas où le certificat viendrait à être piraté (ce qui s'est déjà produit).

    Je précise pour les débutants qu'en aucun cas cela procure une protection du niveau de SSL, notamment SSL protège votre session, ce qui n'est pas le sujet du script proposé dans le lien qui concerne uniquement la protection du mot de passe.
    - Réalisations
    - Interface graphique : génération en javascript d'objets défilants, texte et/ou images, mode horizontal ou vertical.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •