Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 27
  1. #1
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 120
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 120
    Points : 7 484
    Points
    7 484

    Par défaut PHP introduit une nouvelle API de gestion des mots de passe

    La RFC "password_hash" vient d'être acceptée et sera ajoutée à PHP 5.5


    Pourquoi cette nouvelle API ?
    Généralement lorsque l'on parle de hash de mot de passe les utilisateurs se tournent vers md5 ou sha, deux algorithmes qui ne devraient plus être utilisés (nombreuses rainbow tables, failles dans l'algorithme ...)

    Une solution efficace pour hasher ses mots de passe est l'utilisation de bcrypt mais malheureusement peu de développeurs l'utilisent notamment à cause de la fonction crypt() de php qui n'est pas des plus faciles à utiliser.

    Cette nouvelle API vient donc combler ce manque avec une solution simple et efficace pour protéger ses mots de passe.


    Comment ça marche ?
    La RFC propose quatre nouvelles fonctions, deux nous intéressent particulièrement puisqu'elles permettent de hasher et vérifier un hash :

    Code :
    1
    2
    password_hash($password, $algo, $options = array());
    password_verify($password, $hash);
    Pour hasher et vérifier un mot de passe, c'est donc très simple :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    $password = "motdepasse";
    $hash = password_hash($password, PASSWORD_BCRYPT, array("cost" => 10));
     
    if (password_verify($password, $hash)) {
        echo 'Mot de passe OK';
    } else {
        echo 'Erreur mot de passe';
    }
    Vous aurez remarqué la spécification d'un coût dans les options, ce coût définit la complexité du mot de passe. Plus le coût est élevé plus le hash est long à obtenir et par conséquent difficile à attaquer.

    Avec cette API, plus besoin de se soucier des salts aléatoires, tout est géré en interne, le développeur n'a plus qu'à protéger son mot de passe.

    La compatibilité future n'a pas été oubliée puisque grâce à password_needs_rehash il sera possible de rehasher un mot de passe si l'algorithme par défaut évolue.


    Je n'ai pas PHP 5.5 !
    Tout n'est pas perdu , il existe de nombreuses implémentations de bcrypt en PHP. Tel que phpass


    Toutes les infos et des exemples sur la RFC password_hash : voir
    Pry Framework php5

  2. #2
    Expert Confirmé Sénior
    Avatar de transgohan
    Homme Profil pro Baptiste ROUSSEL
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    1 758
    Détails du profil
    Informations personnelles :
    Nom : Homme Baptiste ROUSSEL
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 758
    Points : 4 735
    Points
    4 735

    Par défaut

    Sympatoche, jusqu'à maintenant j'utilisais ma propre class effectuant la même chose mais en utilisant blowfish.
    Mais sinon je vois pas tellement en quoi crypt() est difficile à utiliser...

    Edit : hum... BCRYPT = BLOW_FISH ?
    Bon au final à part normaliser ce que j'utilisais déjà ça me changera rien...
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  3. #3
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 120
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 120
    Points : 7 484
    Points
    7 484

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Mais sinon je vois pas tellement en quoi crypt() est difficile à utiliser...
    C'est pas tant la syntaxe qui est compliqué mais plutôt les arguments à lui passer qui nécessite des connaissance en cryptage pour savoir quoi utiliser.

    Là avec cette nouvelle API , pas de question à se poser , pas besoin de connaitre les différents algorithmes. Bref c'est plus simple et on évite les erreurs
    Pry Framework php5

  4. #4
    Candidat au titre de Membre du Club
    Homme Profil pro Yann Kechichian
    Développeur Web
    Inscrit en
    août 2010
    Messages
    16
    Détails du profil
    Informations personnelles :
    Nom : Homme Yann Kechichian
    Localisation : France

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

    Informations forums :
    Inscription : août 2010
    Messages : 16
    Points : 13
    Points
    13

    Par défaut

    Il existe même une librairie qui permet d'assurer la compatibilité avec les versions antérieures à la 5.5 : https://github.com/ircmaxell/password_compat

  5. #5
    Nouveau Membre du Club
    Inscrit en
    mars 2007
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 18
    Points : 36
    Points
    36

    Par défaut

    Je comprend pas comment le salt peut être géré en interne ?

    C'est une chaîne qu'on définis dans le php.ini ? En cas de changement de serveur comment ça se passe pour conserver le même grain ?

    Et la fonction password_verify() elle fait juste un password_hash($password) puis un === ou bien c'est plus complexe que ça ?

  6. #6
    Rédacteur/Modérateur

    Avatar de Nathanael Marchand
    Homme Profil pro Nathanael Marchand
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 614
    Détails du profil
    Informations personnelles :
    Nom : Homme Nathanael Marchand
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 614
    Points : 8 020
    Points
    8 020

    Par défaut

    Il manque une parenthèse dans le dernier exemple, juste avant le point virgule : ("cost" => 10);

    Par contre, j'ai du mal à voir comment password_verify fonctionne. En supposant que password_hash est paramétrable (puisqu'on a l'air de pouvoir passer l'algo et la complexité), je vois pas comment on peut faire la comparaison pour savoir si le password est bon car il faut réhasher avec les mêmes paramètres et comparer ceci or password_verify lui ne prend pas de paramètres.
    Si quelqu'un peut éclairer ma lanterne ca serait top!

  7. #7
    Membre chevronné
    Inscrit en
    décembre 2004
    Messages
    431
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 431
    Points : 607
    Points
    607

    Par défaut

    J'imagine que la valeur du hash contient quelques infos sur la manière dont il a été calculé, permettant de vérifier par la suite ?
    Ou bien il existe, parallèlement à l'algo de chiffrage, un algo de vérif qui profite de quelques particularités mathématiques de la méthode de chiffrage ?
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  8. #8
    Membre chevronné Avatar de Grabeuh
    Homme Profil pro Mathieu Savelli
    Développeur Web
    Inscrit en
    février 2009
    Messages
    113
    Détails du profil
    Informations personnelles :
    Nom : Homme Mathieu Savelli
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : février 2009
    Messages : 113
    Points : 664
    Points
    664

    Par défaut

    La chaine retournée par password_hash() contient à la fois le l'algo + l'indice de complexité + le sel + le hash.
    Code :
    1
    2
    3
    4
    5
    "$2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi"
    //$2a pour l'algo blowfish
    //$07 pour une complexité de 7
    //$usesomesillystringfor est le salt, il commence par $ et la chaine fait 22 caractères au total en comptant le $. Si lors du hashage on met une chaine plus longue, elle est tronquée.
    //le reste est la chaine "rasmuslerdorf" hashé par l'algo
    C'est le fonctionnement classique de crypt, dont la nouvelle API doit être une surcouche simplifiée.
    Et oui, pour effectuer la comparaison, on repasse le mot de passe en clair à la moulinette et on le compare au hash. Les informations de cryptage (algo, complexité et sel) sont extraites de la chaine du hash.

  9. #9
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 120
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 120
    Points : 7 484
    Points
    7 484

    Par défaut

    Citation Envoyé par Nathanael Marchand Voir le message
    Il manque une parenthèse dans le dernier exemple, juste avant le point virgule : ("cost" => 10);
    Merci c'est corrigé

    Citation Envoyé par Nathanael Marchand Voir le message
    Si quelqu'un peut éclairer ma lanterne ca serait top!
    Grabeuh l'explique très bien dans sa réponse précédente , le hash retourné par la fonction comprend toutes les infos nécessaire pour le comparer.

    Pour ceux que ca interesse une implémentation de bcrypt en php : https://github.com/grunk/Pry/blob/ma...rypt.class.php ca peut aider à comprendre le principe
    Pry Framework php5

  10. #10
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2011
    Messages
    56
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : septembre 2011
    Messages : 56
    Points : 54
    Points
    54

    Par défaut

    Donc si je comprend bien, avec cette nouvelle méthode, en BDD on stocke à la fois l'algo + l'indice de complexité + le sel + le hash.

    Mais si une personne mal intentionnée récupére ma BDD et même si elle a toute ces infos, il lui sera impossible de déchiffrer et de retrouver le mot de passe en clair ?

    Pour ma part, j'ai toujours stocké le hash dans la BDD et le sel dans mon code source... N'est-ce pas mieux ainsi ?

    Et que pensez-vous de la solution :

    Code :
    1
    2
     
    $mon_hash = sha1("v'la_du_gros_sel".md5("sel_de_mer"."PASS"));

  11. #11
    Rédacteur/Modérateur

    Avatar de Nathanael Marchand
    Homme Profil pro Nathanael Marchand
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 614
    Détails du profil
    Informations personnelles :
    Nom : Homme Nathanael Marchand
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 614
    Points : 8 020
    Points
    8 020

    Par défaut

    Citation Envoyé par grunk Voir le message
    Merci c'est corrigé


    Grabeuh l'explique très bien dans sa réponse précédente , le hash retourné par la fonction comprend toutes les infos nécessaire pour le comparer.

    Pour ceux que ca interesse une implémentation de bcrypt en php : https://github.com/grunk/Pry/blob/ma...rypt.class.php ca peut aider à comprendre le principe
    Ca me va bien comme réponse! Merci

  12. #12
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 120
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 120
    Points : 7 484
    Points
    7 484

    Par défaut

    Mais si une personne mal intentionnée récupére ma BDD et même si elle a toute ces infos, il lui sera impossible de déchiffrer et de retrouver le mot de passe en clair ?
    Il ne peux pas retrouver le mot de passe en clair puisqu'un hash n'est pas réversible. Tout ce qu'il peux faire c'est éventuellement un brute force mais comme cet algo est conçu pour être très lent (un seul hash peut prendre de quelques ms à pls seconde selon la complexité) , ça va être très très très long.

    Après ca ne protège pas des utilisateurs négligents qui utilisent des mdp du genre "azerty" ou "123"
    Pry Framework php5

  13. #13
    Nouveau Membre du Club
    Inscrit en
    mars 2007
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 18
    Points : 36
    Points
    36

    Par défaut

    Merci pour les infos

    ça me semble très sympa comme méthode de fonctionnement, je vais étudier ça d'un peu plus près.



    Pour ma part, j'ai toujours stocké le hash dans la BDD et le sel dans mon code source... N'est-ce pas mieux ainsi ?

    Et que pensez-vous de la solution :
    Le soucis c'est que là tu va utiliser un grain de sel commun à toute ta base de donnée. Sur un petit site avec quelques dizaine ou centaine d'utilisateurs c'est pas vraiment un problème, mais sur un site avec plusieurs milliers de comptes, ça vaut le coup de se créer des raimbow table avec le grain de sel que tu à mis dans ton code source et de pouvoir ainsi facilement retrouver tous les mots de passes.

    Si tu utilise un grain de sel différent à chaque fois il faudra tester tous les mots de passe possible pour chaque utilisateur et ça sera beaucoup trop long pour être faisable.


    Après l'idée de stocker le grain de sel à autre endroit de la BDD ne me semble pas complètement idiot car ce n'est pas rare que la BDD soit piraté mais pas le code source de l'application. Une solution qui combine tous les avantages c'est de faire un truc du genre $hash = md5('GDS_Code_Source' . $user['gds_bdd'] . $password);

    Comme ça le pirate doit avoir accès a la BDD + au code source et il ne pourra même pas se créer de raimbow table vu qu'il y'a un grain de sel par compte.

  14. #14
    Invité régulier
    Inscrit en
    juin 2008
    Messages
    7
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations forums :
    Inscription : juin 2008
    Messages : 7
    Points : 5
    Points
    5

    Par défaut

    Je suis étonné que les clés du tableau d'option ne soient pas des constantes.

  15. #15
    Expert Confirmé Sénior


    Homme Profil pro Denis
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    5 009
    Détails du profil
    Informations personnelles :
    Nom : Homme Denis
    Âge : 21
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 5 009
    Points : 14 910
    Points
    14 910

    Par défaut

    Si je comprend bien, plutôt que d'envoyer le hash de son mot de passe, le client va envoyer son mot de passe au serveur afin que ce dernier puisse recalculer le hash ?

    Je ne suis pas expert en sécurité mais ça veut dire qu'à un moment ou un autre, le serveur est capable de retrouver le mot de passe en clair et je doute que ce soit une bonne chose... non?

  16. #16
    Membre confirmé
    Homme Profil pro Mathieu Le Luët
    Ingénieur développement logiciels
    Inscrit en
    novembre 2010
    Messages
    150
    Détails du profil
    Informations personnelles :
    Nom : Homme Mathieu Le Luët
    Âge : 26
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2010
    Messages : 150
    Points : 241
    Points
    241

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Si je comprend bien, plutôt que d'envoyer le hash de son mot de passe, le client va envoyer son mot de passe au serveur afin que ce dernier puisse recalculer le hash ?

    Je ne suis pas expert en sécurité mais ça veut dire qu'à un moment ou un autre, le serveur est capable de retrouver le mot de passe en clair et je doute que ce soit une bonne chose... non?
    Je ne suis pas expert non plus, mais je suis d'accord avec Neckara. Une attaque de type man in the middle permet ici facilement de récupérer un mot de passe (sauf erreur de ma part). Le mieux n'est-il pas d'encoder le mot de passe côté client avant envoi ?
    Pensez au et un petit vote si mon post vous a été utile .

  17. #17
    Membre chevronné Avatar de Grabeuh
    Homme Profil pro Mathieu Savelli
    Développeur Web
    Inscrit en
    février 2009
    Messages
    113
    Détails du profil
    Informations personnelles :
    Nom : Homme Mathieu Savelli
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : février 2009
    Messages : 113
    Points : 664
    Points
    664

    Par défaut

    Citation Envoyé par matll Voir le message
    Je ne suis pas expert non plus, mais je suis d'accord avec Neckara. Une attaque de type man in the middle permet ici facilement de récupérer un mot de passe (sauf erreur de ma part). Le mieux n'est-il pas d'encoder le mot de passe côté client avant envoi ?
    Déjà, si ton utilisateur est tombé dans le panneau d'une attaque par phishing et a rentré son mdp sur une page qui n'est pas la tienne, ça ne changera strictement rien au fait que le pirate aura son mot de passe en clair et pourra l'utiliser sur ta page. Ou pire, il peut lire le code source de ton JavaScript servant à effectuer le hashage et le reproduira sur sa page d'attaque, ce qui fait qu'il aura le mot de passe et l'utilisateur ne se rendra compte de rien.

    La première chose qu'on apprend en sécurité, c'est qu'il ne faut JAMAIS faire confiance au client. Les données malicieuses, intentionnelles ou non, viennent dans 99% des cas du client.
    Tu as la main sur le code qui est situé sur ton serveur et si ton application est compromise de l'intérieur, tu es en mesure de réagir. Par contre, tu ne sais pas qui est ton client ni comment il agit car le protocole HTTP fait que tu n'as que les informations qu'il veut bien te donner, et ces informations peuvent de toute façons être falsifiées.

    Encoder le mot de passe côté client revient à considérer comme des faits des suppositions impossibles à vérifier, ou alors qui te demanderont de gérer plusieurs cas selon que le mot de passe sera envoyé en clair ou en hashé et donc compliquera inutilement ton travail de développeur :
    • Le client est un navigateur utilisant Javascript (adieu les lecteurs optiques pour personnes malvoyantes ou certains terminaux mobiles bas de gamme)
    • Javascript est activé (adieu les entreprises où le DSI ou l'admin ou même l'utilisateur lui-même un peu trop paranoïaque a bloqué le JS)


    Les seuls moyens suffisamment efficaces à ce jour de se protéger contre les attaques man in the middle sont une connexion sécurisée type SSL et une sensibilisation des utilisateurs aux questions de sécurité des applications web.
    Pour rendre ceci encore plus efficace, une authentification forte à 2 facteurs : ajouter au mot de passe un code à usage unique et limité dans le temps envoyé par SMS, par une clé type RSA SecurID ou encore par une application spécifique pour smartphone. Si le voleur a le mot de passe, il n'aura pas l'élément physique nécessaire à l'attaque et pourra difficilement automatiser l'attaque à cause du laps de temps de validité du code.

    Mais comme toujours, sécurité et facilité d'utilisation sont généralement antagoniste, et plus on rajoute des couches pour protéger son site, plus on le rend fastidieux à utiliser (et surtout compliqué à maintenir)
    Et surtout, aucune sécurité n'est inviolable, car tout programme informatique est contournable, soit par un autre programme, soit par ingénierie sociale.

    Citation Envoyé par Neckara
    Je ne suis pas expert en sécurité mais ça veut dire qu'à un moment ou un autre, le serveur est capable de retrouver le mot de passe en clair et je doute que ce soit une bonne chose... non?
    Mettons que le propriétaire du serveur en fasse un usage illégal et vole les mots de passe de ses utilisateurs.
    S'il veut le voler pour l'utiliser ailleurs (vu que la plupart des gens utilisent le même mot de passe un peu partout, de leur compte facebook à leur banque en ligne) , pourquoi attendre que l'utilisateur retape son mot de passe une nouvelle fois ? Il enregistrera la version en clair dès la création du compte.
    S'il veut usurper l'identité d'un utilisateur sur son propre site, il n'a qu'à modifier le mot de passe et lui donner la valeur qu'il veut, et ensuite remettre l'ancien hash à la place, ni vu ni connu.

    De toute façons, il faut bien qu'à un moment, le serveur puisse faire la comparaison. Et comme je l'a dit plus haut, le client n'est pas digne de confiance. C'est donc forcément au serveur de s'occuper de rehasher le mot de passe pour pouvoir la faire. Car tu es seul à avoir la main dessus (du moins, en théorie) est tu es donc capable de juger de la confiance que tu peux accorder à ton propre code.

  18. #18
    Expert Confirmé Sénior


    Homme Profil pro Denis
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    5 009
    Détails du profil
    Informations personnelles :
    Nom : Homme Denis
    Âge : 21
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 5 009
    Points : 14 910
    Points
    14 910

    Par défaut

    Je sais qu'il ne fait jamais faire confiance au client, mais dans ce cas là envoyer le hash ou le mot de passe revient au même niveau sécurité.

    Pour les spécificités côtés clients hors navigateur utilisés (JavaScript activé ou non, etc.), personnellement je ne m'en occuperais pas (juste mettre un petit message) quitte à perdre une petite partie du public (bon après je ne suis pas professionnel).
    Mais rien ne dit que le JavaScript n'est pas obligatoire pour l'utilisation du site ou que le client utilise bien du JavaScript (ex : client en C++).

    Mais dans mon raisonnement, je pensais que d'envoyer le hash plutôt que le mot de passe réduit le "moment" où il serait possible (mais très faiblement probable) de retrouver le mot de passe.
    De plus comme on ne peut jamais garantir une sécurité à 100%, si jamais une faille est découverte, le mot de passe n'est pas mis en danger.

  19. #19
    Membre Expert
    Avatar de gene69
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    1 633
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 633
    Points : 2 122
    Points
    2 122

    Par défaut

    je me souviens que j'avais écrit un systeme de échange de mdp "sécurisé" (lol) sur du http avec un nomus pour vérifier la formule hash(hash(password) xor nomus) en provenance d'une lib js du client. Pas de mdp stocké en clair, et pas de mdp qui circulent en clair. la sécu s'arrêtait là.

    parce qu'envoyer simplement le hash sur le réseau fait que l'on transforme une empreinte avec un super niveau d'entropie en un mot de passe en clair de longueur fixe. on ne doit envoyer que des "transformés" le réseau. Celui qui comprends pas qu'un hash peut être bruteforcé ou rejoué... est une proie.
    PHP fait nativement la validation d'adresse électronique .
    Celui qui a inventé mysql_connect(...) or die() est déjà mort plusieurs fois.
    Soyez moderne: mysqli_connect() or throw Exception(mysqli_connect_error());

    PHP: un problème ? décrivez le avec ceci.

    Utilisez le bouton résolu!

  20. #20
    Candidat au titre de Membre du Club
    Inscrit en
    janvier 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 10
    Points : 10
    Points
    10

    Par défaut

    Ce qu'il ne faut pas lire quand même... la cryptographie, ça ne s'improvise pas. Je recommande la lecture de "Applied Cryptography" et de "Secret and Lies" de Schneier pour éviter de raconter des bêtises à ce sujet

    MD5 (et encore davantage SHA1) n'ont aucun problème de sécu à ce jour pour ce qui est de leur utilisation pour le hachage de mot de passe. La dernière cryptanalyse dont j'ai science sur les attaques par pré-image (retrouver un antécédant à un condensat) était de l'ordre de 2^123, alors qu'on peine à atteindre (en fait, on en est loin) les 2^100 en terme depuissance de calcul. Ce n'est pas le cas de leur usage lorsqu'il y a risque d'attaques par *collision*, qui est ce jour considéré comme triviales pour MD5.

    Hacher le mot de passe coté client est inutile : le secret n'est plus le mot de passe, mais son condensat : apport en capacité d'authentification : zéro-toto. De toutes les manières, si la sécu vous importe sur votre mécanisme d'auth (et elle devrait), utilisez TLS. On peut avoir des certificats pour 0 à 15 euros par an, qui suffisent amplement pour un petit site perso.
    Se substituer à TLS est TOUJOURS une mauvaise idée.

    Concernant le salt : n'utilisez jamais de sel constant sur plusieurs utilisateurs. Un par user.
    Privilégiez des salts vraiment aléatoires (pas rand(om)(), donc). Prévoyez un salt qui complète la taille du bloc de votre algo de hachage, au mini, et mieux un salt qui fasse au moins la taille du bloc (les tailles de blocs sont dispos dans toute bonne doc sur les-dits algo). Idéalement, faites un open de urandom sur les systèmes unix, voire de /dev/random si vous avez un générateur d'entropie à disposition (je ne parle pas de votre femme, messieurs :p) : le PRNG de PHP a été prouvé maintes fois peut fiable : autant l'éviter comme la peste pour la crypto.

    "Mais pour qui il se prend, celui là ?" Pour qqn qui fait ça à longueur de journée, de se renseigner, lire et se former pour donner les meilleurs conseils sécu à ses clients

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
  •