Il n'y avait pas "We have 3 antivirus to protect our website", en plus dans un coin ?

Par curiosité je suis aller regarder cet algo, et c'est le principe de base de PBKDF2 de réperer le hash, 1000 étant la valeur minimum recommandée à sa création...

Par antivirus, on parle de protection contre les virus, ou protection contre les hackers ?

Et si c'est contre les hackers, les gentils, les méchants, ou les 2 réunis ? :D

Et une fois repéré le hash, il s'enfuit et se cache ailleurs?

Il est hash'ment bien caché

donc en gros, avec 10 000 hashs, ça fera un code à peu près deux fois plus protégé (en ln10)

C'est un PEBKAC ou pas alors?

Désolé, mais là CTLP, carrément !

Explications : en sécurité des mots de passe informatiques, un des plus gros ennemis est la rapidité des ordinateurs. Si un pirate arrive à récupérer le hash du mot de passe, il peut tenter de casser par force brute. Avec une seule passe, la vérification d'un mot de passe est hyper méga rapide (de l'ordre du millionième de seconde), il peut alors tester énormément de mots de passe en très peu de temps. Alors qu'avec plusieurs milliers de passes, vérifier un mot de passe peur prendre beaucoup plus de temps (selon la puissance de l'ordinateur et le nombre de passes nécessaires).

Le nombre de passes à appliquer dépend également de la complexité de l'algorithme utilisé : plus l'algorithme est rapide, plus il faut de passe. Pour ma part j'utilise SHA512, avec 50 000 passes sur un service que je suis en train de développer.

1 000 hashs, c'est déjà un peu PEBKAC, alors 10 000...

On peut aussi mettre en place une sécurité avec un temps minimum entre deux essais autorisés, qui augmente de façon exponentielle après chaque échec.

La théorie c'est bien joli, mais le nombre de combinaisons reste bien trop grand pour qu'une attaque par brute force soit efficace. Pour peu que ton mot de passe soit autre chose qu'un bête mot du dictionnaire.

Pas vraiment :
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-[...]

Et pour répondre à Acorah, si l'attaquant a récupéré les hash, il n'a pas besoin de s'imposer lui-même un temps d'attente.

(désolé c'est moi le posteur du message ci-dessus, j'ai oublié de me connecter avant de poster...)

Ah oui, et puis je viens de revérifier mon code, je ne fais pas 50 000 passes, j'en fais 500 000.
Avec 500 000 passes, la vérification d'un mot de passe prend environ 265 milisecondes sur mon serveur (Xeon E3-1220 à 3.10GHz).

Avec 10 000 passes, ça prend entre 0,8 et 1,1 milisecondes.

Avec 1 000 passes (le minimum de la fonction sha512 que j'utilise), on peut tester 1750 mots de passe par seconde, avec du code en Python sur un serveur d'entrée de gamme (les perfs entre 1000 et 10000 ne changent pas des masses)

Je ne parle pas des cas où un pirate essaie de se connecter à un service en ligne, je parle du cas où un pirate a accès au hash (après avoir piraté la base des mots de passe d'un site, ou par un (mal)heureux hasard quelconque : on ne peux jamais tout prévoir).
Donc impossible d'imposer un temps minimum, quand il a toutes les cartes en main.

Si, comme tu dis, l'attaquant a récupéré les hashs, il a suffisamment accès au système pour ne plus en avoir besoin : il fait déjà ce qu'il veut.

A priori ce n'est pas un PEBKAC, RFC2898 sur le PBKDF, chap 4.2:
"For the methods in this document, a minimum of 1000 iterations is recommended"

Pour les 3 antivirus, j'imagine : 1 pour la protection contre les virus, 1 contre les gentils hackers, et 1 contre les méchants hackers.

Bonjour, je suis l'auteur de ce PEBKAC... et je vous prie de voter "C'est toi le PEBKAC".

Je me suis un peu trop empressé dans la soumission de mon second PEBKAC ici sur le hachage. :p

Apparemment il me manquait une notion sur le chiffrement ayant 'appris' par le passé qu'il était inutile de hacher plusieurs fois une même donnée...

Sauf que l'algo PBKDF2 donne tort à ce qui me fut conté jadis. (http://en.wikipedia.org/wiki/PBKDF2)
Comme quoi en fait même 10000 fois ne semble pas assez aujourd'hui. :p

Donc quand je comprends pas quelque-chose je ferais mieux de la fermer. ;)

PEBKAC avoué à demi pardonné?

> le nombre de combinaisons reste bien trop grand pour qu'une attaque par brute force soit efficace

Partons sur 26 lettres de l'alphabet, 10 chiffres, une dizaine de caractères accentués facilement accessibles au clavier et une quinzaine de caractères bizarres facilement accessibles au clavier.
Ça donne 61 caractères pour chaque rang.

Pour un mot de passe de 6 caractères (pas très inhabituel chez les gens "normaux"), ça fait :
61^6 = 51 520 374 361 mots de passe possibles.

Sur un serveur d'entrée de gamme dont la location est à 30 EUR par mois (voir un autre message plus bas à propos de mon serveur), avec un programme mono-thread on vérifie 1750 mots de passe par seconde : un tel serveur avec un seul processeur Xeon E3 à 3,1 GHz (d'entrée de gamme, rappelons-le) aura donc fait le tour de TOUS les mots de passe en 341 jours : moins d'un an.

Chez OVH, on peut louer à environ 200 EUR par mois un serveur qui a 6 coeurs : Intel Xeon E5-1650 à 3,2 Ghz. Je n'ai pas de stats, soyons raisonnables et disons qu'avec un seul coeur de ce processeur on peut faire 2000 vérifications par seconde. Avec 6 coeurs, on en fait donc 12000 par seconde (et encore, il faut voir si l'hyperthreading ne permettrait pas d'aller encore plus vite, peut-être pas le double mais un peu plus vite quand même)

On a alors fait le tour de TOUS les mots de passe de 6 caractères en moins de 2 mois.

Je résume : pour 400 euros, on peut casser TOUS les mots de passe de 6 caractères en 2 mois s'ils sont hashés en SHA512 1000 à 10000 fois. Tout cela sans s'y connaitre dans les techniques avancées de cassage de mots de passe, qui font pâlir n'importe quelle attaque par force brute comme celle que je théorise ici.

Et les sites qui annoncent ces chiffres (1000, 10000), ils le font pour mettre en avant leur sécurité, en disant qu'ils sont trop biens. Imaginez alors tous ces sites qui utilisent encore MD5 avec une seule passe !


Je tiens également à souligner, comme l'explique l'article donné par DooMeeR, qu'il y a des techniques bien plus efficaces que la force brute, qui vont exponentiellement plus vite (dictionnaires, etc).

Il est quand même nécessaire de saler le mot de passe, bien que si lors d'une attaque l'attaquant parvient à récupérer le sel (en récupérant le code source par exemple), ça n'a plus d'intérêt.
Par contre, c'est le CPU du serveur qui doit en prendre un coup avec plusieurs milliers de passes.

En réponse à vualatele, message ci-dessus :

> Si, comme tu dis, l'attaquant a récupéré les hashs, il a suffisamment accès au système pour ne plus en avoir besoin : il fait déjà ce qu'il veut.

Eh bien non, pas nécessairement.
D'une part, le pirate peut n'avoir eu accès qu'aux hashes. Imagines une authentification centralisée avec le protocole LDAP, il peut avoir réussi à exploiter une faille sur le serveur LDAP pour récupérer la liste des hashes, mais pas réussi à casser le serveur principal qui héberge l'application. Il peut alors casser les mots de passe pour accéder au service. (et ce n'est là qu'un seul exemple, qui me vient immédiatement à l'esprit).

D'autre part, énormément de monde utilise le même mot de passe sur plusieurs services. Si on a réussi à casser le mot de passe d'un utilisateur sur un service, on a de fortes chances de réussir à pénétrer les comptes de ce même utilisateur sur d'autres services...

Sinon avec une mégabasedelamortquitue de relations "password"->"500000ème hash", ça sera tout aussi rapide que "password"->"1seul hash".

Et puis sinon, il faut aussi connaitre le Salt pour commencer tes boucles de hash.

J'ai tout lu, et je ne change pas d'avis. Je n'ai jamais dit que "le moindre petit algo de hash rend un mot de passe incrackable", il ne faut pas lire de travers. L'article parle d'un MD5, pas de salt, et la grande majorité des mots de passe crackés font 6 lettres ou moins.

Evidemment que ces choses là sont passables par n'importe qui. Mais que je vous ponde un mot de passe comme celui évoqué par le strip de xkcd à la fin de l'article, dites moi sincèrement QUI peut bruteforcer ça (sans ingénierie sociale, un mot de passe inconnu) en un temps raisonnable ? Bien sûr avec plusieurs passes, un algorithme plus costaud, et un salt.

Enfin bon, il y a quand même d'autres algos qui permettent de sécuriser un peu sans avoir besoin de boucler 10000 fois.

> L'article parle d'un MD5, pas de salt, et la grande majorité des mots de passe crackés font 6 lettres ou moins.

Le changement d'algorithme ne fait que rendre les vérifications plus lentes, ça ne facilite ou complexifie pas nécessairement le cassage. Là où avec MD5 un cassage prend un quart de seconde, ça prendra peut-être 5 ou 10 secondes avec un algo bien blindé.

> que je vous ponde un mot de passe comme celui évoqué par le strip de xkcd à la fin de l'article, dites moi sincèrement QUI peut bruteforcer ça (sans ingénierie sociale, un mot de passe inconnu) en un temps raisonnable

dis-moi sincèrement QUI utilise des mots de passe comme ça dans la vraie vie ?

Le pirate, s'il arrive à casser 100000 mots de passe de 6 caractères il est content, il aura bien quelque chose d'intéressant dans le cas, il y a bien un gars quelque part qui a une responsabilité X ou Y et qui a "mal" sécurisé son mot de passe. Et tant pis pour celui qui a un mot de passe de 40 caractères...

> Sinon avec une mégabasedelamortquitue de relations "password"->"500000ème hash", ça sera tout aussi rapide que "password"->"1seul hash".

Non car les hash sont salés. Les rainbow tables sont totalement inutilisables, sur des hashes salés : essaye de hasher un mot de passe avec un sel, tu n'auras pas deux fois le même hash.

Un hashage sans sel, c'est en effet complètement inutile, autant stocker les mots de passe en clair...

------

Tu as édité ton message pour parler du sel, donc :

> Et puis sinon, il faut aussi connaitre le Salt pour commencer tes boucles de hash.
Le sel est inclus dans le hash, ce n'est pas un problème de le connaître. Mais 500 000 boucles, ça peut vouloir dire 500 000 sels différents, pour chaque mot de passe... tu ne peux pas avoir une rainbow table dans ce cas.

Une rainbow table, ça peut prendre des semaines, des mois ou des années à être construit, et si tu changes le sel ne serait-ce que d'un caractères, il faut la reconstruire entièrement.

Tu peux en citer ?

Je connais un peu la sécurité (ce n'est pas mon cœur de métier, disons que je côtoie ce domaine, je ne peux donc pas dire que je suis un grand expert), je n'ai jamais vu d'algo de hashage qui n'ait pas besoin de nombreuses boucles pour bien sécuriser un mot de passe (je rappelle que l'objectif c'est de ralentir les vérifications hein, pas de rendre le mot de passe plus sécurisé en soi).

J'ai récemment approfondi le sujet pour avoir un bon algo pour sécuriser le service en ligne que je développe, je n'ai rien trouvé qui n'ai pas besoin de plusieurs milliers de passes.

@tiramiseb : un fois un hash en main, comment peux-tu savoir quelles sont les algos qui ont été successivement utilisés pour le générer et aussi combien passes ont été faites ?
Quand t'as ça A --md5--> B, tu retrouves A avec B car tu reconnais md5.
Mais s'il y a par exemple c'est A --md5--> B --moulinetteperso--> C --md5--> D, tu peux retrouver C avec D mais ça ne va pas t'avancer à grand chose.

Oui, je prêche pour ma paroisse.
Mes mots de passe sont sécurisés, et ne font pas partie des schémas simplistes évoqués par l'article.

Alors certes, des millions de Michu se feront avoir dans l'histoire, mais moi, je n'y peux rien. Et on ne peut pas tous les former/obliger à faire plus compliqué. Que peut-on faire alors ? Education, algorithmes plus complexes, bio-authentification, un peu de tout ?

Je pense que je peux mériter un bashage en règle. ;)

Mais je prends ma revanche en postant autre chose sur cette même application, et qui cette fois-ci révèle d'un vrai PEBKAC. :)

Puis si mon erreur d'interprétation peut servir à d'autres ce n'est pas plus mal.

Vos jeux de mots sont vraiment hash'ier.

S'enfuit hash'val

Noname gagne un bouton de porte plaqué or pour son jeu de mot épiquement pourri x2!

Il parait que bcrypt c'est bien comme algo pour stocker du mot de passe (plus résistant que PBKDF2).
Pour ce qui est du cassage de mot de passe, la force brute est un processus un peu long, mais pour les gens que ça intéresse, la recherche hybride, notamment avec *oclhashcat* permet de combiner dictionnaire et transformations usuelles, avec la puissance de calcul des GPU. Les chiffres déchirent.

> @tiramiseb : un fois un hash en main, comment peux-tu savoir quelles sont les algos qui ont été successivement utilisés pour le générer et aussi combien passes ont été faites ?

Le plus simple est de te montrer ça, tu comprendras mieux :

 ~$ python
 [...]
 >>> from passlib.hash import sha512_crypt
 >>> sha512_crypt.encrypt("mot de passe", rounds=1000)
 '$6$rounds=1000$xvSeBV4RaqD0fF2O$RvX4x2kJAVq/R4/WrkwG7Q2GsPeCV.vQPUWF3xqQ8yRjLehhQVmycoSu1U7chCRDup1vRaS3Hu/5joVoTMey5/'
 

$6$ => sha512 (enfin, je crois que c'est ça qui donne cette indication...)
$rounds=1000$ => je pense que c'est explicite :)


> Quand t'as ça A md5> B, tu retrouves A avec B car tu reconnais md5.
> Mais s'il y a par exemple c'est A md5> B moulinetteperso> C md5> D, tu peux retrouver C avec D mais ça ne va pas t'avancer à grand chose.

Si tu intercales une moulinette perso, ça peut complexifier la chose, carrément oui. Ça ne rend pas le mot de passe inviolable, mais ça complexifie.

Cela dit, comme tu le vois ci-dessus on utilise généralement le même algo, que l'on lance un certain nombre de fois sur la chaîne (et je crois que c'est souvent avec le même sel sur toutes les passes, ça rend la chose assez sécurisée tant que le sel est différent pour chaque génération d'un mot de passe).


> Que peut-on faire alors ? Education, algorithmes plus complexes, bio-authentification, un peu de tout ?

Voilà, tu l'as dit : un peu de tout.
- on demande aux gens de faire gaffe : il y a 15 ans, les mots de passe habituels c'était genre le nom du chien, la date de naissance du gamin... maintenant c'est plus compliqué que ça, avec des caractères bizarres
- on utilise des algorithmes plus complexes
- parfois on utilise de la biométrie

Mais bon, moi je n'aime pas la biométrie, ça reste facilement falsifiable : ça peut être un complément, mais pas la seule base d'authentification.

Ce n'est pas TOUS les mots de passe, mais 1 mot de passe, sinon c'est que tout tes mots de passe utilisent le même salt et dans ce cas la PBKDF2 ne sert pas à grand chose.

Dans le cas d'un salt unique pour tout les mots de passe. Il suffit d'appliquer ta fonction sur le mot de passe que tu teste et de voir dans la liste des hash si un hash match celui qui tu as obtenu.

Dans le cas d'un salt par mot de passe. Il faut hasher ton password en test avec le salt, effectuer une comparaison, puis recommencer pour le salt suivant. Dans ce cas ta vitesse de test sera hash/s / nb de salt

| essaye de hasher un mot de passe avec un sel, tu n'auras pas deux fois le même hash.
Tu veux dire avec un sel différent, parce qu'avec le même sel, j'obtiens la même chose.

| Le sel est inclus dans le hash
On ne doit pas parler pas de la même chose. Ou alors tu veux dire "Le sel est utilisé pour faire le hash".

| Avec 1 000 passes on peut tester 1750 mots de passe par seconde
Donc tu connais les 1000 sels utilisés ? Tester toutes les combinaisons possibles c'est pareil que de créer une rainbow table.

> Ce n'est pas TOUS les mots de passe, mais 1 mot de passe

Oui tu as raison, j'ai malheureusement dépassé le temps d'expiration de la possibilité d'éditer mon mot de passe. Mon résumé aurait dû être :

pour 400 euros, on peut casser N'IMPORTE QUEL mot de passe de 6 caractères en 2 mois s'il est hashé en SHA512 1000 à 10000 fois.

> bien que si lors d'une attaque l'attaquant parvient à récupérer le sel (en récupérant le code source par exemple), ça n'a plus d'intérêt.

Le sel n'est pas dans le code source.
Un sel fixe dans un code source, c'est aussi peu sécurisé que pas de sel du tout.

Le sel est généré aléatoirement lorsque l'on hashe le mot de passe.

Le sel est embarqué dans le hash, ce n'est pas un problème car son objectif est de rendre inutile les rainbow tables, c'est tout : le pirate ne va pas régénérer une nouvelle table pour chaque sel différent qu'il rencontre, pour chaque mot de passe.

Sinon, y'a aussi la possibilité que l'utilisateur ne connaisse plus son mot de passe, et s'authentifie avec une carte et un code pin... Mais vu le mal qu'on a à le mettre en place dans les hôpitaux, c'est pas gagné ! (Le personnel hospitalier a parfois du mal à comprendre pourquoi il ne peut plus utiliser le mot de passe du collègue parce qu'il a perdu le sien, et que non, une carte ne se prête pas, et que non, non, non, on ne va pas modifier les dossiers patients sous le nom d'un autre....)

http://hashcat.net/oclhashcat-plus/ mouais, pour les algos de hashage sa envoi du paté. Pour bcrypt, sa ne fait pas rêver.

Scrypt est aussi intéressant on peu régler la conso mémoire afin d'empêcher l'utilisation de hardware spécialisé.

> Tu veux dire avec un sel différent, parce qu'avec le même sel, j'obtiens la même chose.

En effet, je parle de hasher avec un algo qui utilise du salage : le sel sera automatiquement généré différemment par la fonction qui utilise l'algo.

> On ne doit pas parler pas de la même chose. Ou alors tu veux dire "Le sel est utilisé pour faire le hash".

Il y a plusieurs possibilités pour générer le sel. Mais dans tous les cas, au moment de vérifier le mot de passe (que la vérification soit légitime ou non) on ne connaît pas le sel, il est donc d'une manière ou d'une autre :
- soit connu ou calculable à l'avance
- soit embarqué dans le hash

Bon, là on atteint les limites de mes connaissances dans ce domaine, donc je ne saurais pas être beaucoup plus précis.

> | Avec 1 000 passes on peut tester 1750 mots de passe par seconde
> Donc tu connais les 1000 sels utilisés ?

Je parle là de tests effectués sur mon serveur, juste avant d'écrire le message.
J'ai simplement utilisé le module "timeit" de python et lancé la vérification d'un mot de passe

 >>> timeit.timeit("from passlib.hash import sha512_crypt; sha512_crypt.verify('mot de passe', '$6$rounds=1000$xvSeBV4RaqD0fF2O$RvX4x2kJAVq/R4/WrkwG7Q2GsPeCV.vQPUWF3xqQ8yRjLehhQVmycoSu1U7chCRDup1vRaS3Hu/5joVoTMey5/')", number=1750)
 0.9925789833068848
 >>> timeit.timeit("from passlib.hash import sha512_crypt; sha512_crypt.verify('mauvais mot de passe', '$6$rounds=1000$xvSeBV4RaqD0fF2O$RvX4x2kJAVq/R4/WrkwG7Q2GsPeCV.vQPUWF3xqQ8yRjLehhQVmycoSu1U7chCRDup1vRaS3Hu/5joVoTMey5/')", number=1750)
 1.482956886291504
 

Là on voit bien que je n'ai pas donné tel ou tel sel. J'ai juste donné un mot de passe et un hash, l'algo se débrouille tout seul pour vérifier. Le hash étant différent à chaque fois qu'on le génère, il y a bien un composant aléatoire. Le sel (aléatoire, donc) n'étant pas fourni lors de la vérification, il est forcément embarqué dans le hash, pour que la vérification puisse se faire.



Par contre, je constate là qu'il faut 1 seconde pour avoir 1750 succès, mais 1,48 secondes pour avoir 1750 échecs... Il faudrait revoir mes estimations à la hausse, mais bon c'est un test hyper basique avec du matériel d'entrée de gamme et sans optimisation : un pirate saura de toute manière faire quelque chose qui soit des centaines, voire des milliers de fois plus rapides (dictionnaires, utilisation de GPU, etc)

que dis-je, un jeu de mots hippique !

Le problème de la carte, c'est que ça peut se perdre.

Mais :
- si le PIN est différent pour chaque carte
- si la perte d'une carte est immédiatement indiquée à l'instance responsable de la sécurité
- si la carte peut être invalidée simplement et rapidement
Alors c'est une alternative viable.

@tiramiseb : plutôt que d'augmenter indéfiniment le nombre de passes de SHA512 (500000 ça fait vraiment beaucoup, 265 ms pour tester un mot de passe, il ne faut pas avoir des centaines de milliers d'utilisateurs) en te basant sur un mot de passe à 6 caractères, déjà tu ferais bien de forcer tes utilisateurs à avoir un mot de passe de 8 caractères minimum.

Ensuite ton calcul est un peu faux, les 26 lettres de l'alphabet en majuscules et minuscules ça fait 52 caractères. Donc, si je reprends ton calcul avec 61+26=87 caractères possibles, et 8 caractères minimum, ça fait 3282116715437121 combinaisons (3 millions de milliards).

À une vitesse de 1 million de vérifications par seconde (soit beaucoup plus que ce que tu annonces), ça fait 38000 jours pour tester toutes les combinaisons, soit plus de 104 ans.

Bref, je ne dis pas que tu as tort, mais passer à 500000 passes induit quand même une forte charge serveur si tu as plein d'utilisateurs, et il est extrêmement plus efficace d'augmenter la taille minimale du mot de passe (passe à 10 caractères au lieu de 8 pour être tranquille pour longtemps).

Le PIN n'est différent pour chaque carte que s'il y a moins de 10 000 cartes. Ou alors il faut augmenter sa taille.

Merci pour ces bons arguments FBM.

Je me demandais justement si c'était vraiment utile ces 500 000 passes (et ces 250ms par vérification), tes arguments vont bien dans le sens de la simplification.

En effet j'ai oublié les majuscules et les minuscules. Et bien sûr, si on augmente le nombre de caractères on augmente exponentiellement le nombre de possibilités.
En plus, mon code limite déjà à 6 caractères, ça ne serait pas compliqué de monter ce chiffre à 8. J'ai encore du mal à peser le pour et le contre, entre le confort des utilisateurs et la sécurité de leur mot de passe. Je pense que tes arguments vont finir de me convaincre de passer à 8.

Par contre, là on parle encore de force brute, alors que ce qui est fragile ce n'est pas le nombre de caractères, c'est l'enchaînement de caractères utilisé par les gens.

Et, évidemment, un pirate essaiera de casser "azerty123" (9 caractères) avant de plancher sur "#{@|" (4 caractères), le premier étant plus susceptible d'être utilisé par n'importe qui.
Et ça, quelle que soit la complexité de l'algorithme, on ne peut rien y faire : il faut éduquer les utilisateurs.

C'est le cas. Le PIN est unique par carte. La carte peut être invalidée rapidement par un mec de la DSI. Au bout de 3 PIN faux (paramétrable), la carte est invalidée. Si qqun perd sa carte, il peut quand même se connecter grâce à un système de Q&R (souvent 10, mais paramétrable aussi, ça décourage de perdre sa carte quand à chaque fois que tu changes de poste, tu dois te retaper les 10 Q&R...)
Ca marche assez bien, et au final, c'et pratique !

Edit : vualatele, en effet. Le code est à 4 chiffres, mais comme au bout de 3 faux PIN la carte n'est plus valide, il faut avoir un sacré bol pour tomber sur le bon en 3 coups (les codes sont aléatoires)

Cette solution me semble alors élégante lorsqu'elle peut s'appliquer, alliant la simplicité du "mot de passe" (4 chiffres, facile à retenir, même si uniquement 10000 combinaisons possibles comme le dit vualatele) à un blocage rapide en cas de problème.

Malheureusement, sur un site web ce n'est pas faisable ;)

La difficulté à casser un mot de passe ne dépend que de sa longueur et de sa complexité.

Partant du principe que le pirate dispose de l'algo de hashage, peu importe que l'on fasse 10 000 ou 100 000 passes, un mot de passe du genre "minou" ou "1234" sera toujours trouvé rapidement !

Comme mentionné plus haut, tu rajoutes par exemple une moulinette perso entre 2 algos connus et c'est déjà plus sécurisé.
Chacun peut rajouter sa sauce, donc je ne peux pas t'en citer. Tant que personne n'a ton code source, il sera très difficile de savoir comment obtenir le résultat.

| Partant du principe que le pirate dispose de l'algo de hashage
@vualatele : effectivement, mais il faut déjà l'avoir.

Le code PIN ne fait pas forcément 4 chiffres! Le mien en fait 6.

Dans le cas d'une application en javascript (ce qui est le cas pour l'application en question), l'algo devrait être accessible en clair. ^^;

Effectivement, la solution s'applique pour les applis (lourdes ou web) en entreprise. Ça serait coûteux de te mettre un serveur SSO chez toi :)

ROB, je parle des cartes CPS et CPE (Carte de Professionnel de Santé et Carte de Personnel d'Établissement) dont le code PIN fait 4 chiffres. Mais il en existe sans doute avec des PIN plus longs...

@FBM Cela risque surtout de poser problème si des millier d'utilisateur se connectent en même temps.

J'ai entendu dire que l'étape d'authentification de l'utilisateur ne se faisait qu'une fois par session (voire moins si il reste loggué). Pour moi ce coût reste raisonnable.

D'ailleurs certains site on des réaction différentes suivant un mot de passe faux et un mot de passe juste, dans le premier cas la requête prend 2 à 3 secondes dans le second, c'est quasiment instantané.

Grâce à toi, j'ai quand-même eu l'occasion d'apprendre plein de choses grâces aux nombreuses réactions ci-dessus. CTLP, mais avec le sourire. :)

De toute façon, un pirate n'a pas besoin du mot de passe d'origine, juste d'une chaîne qui donne le même hachage. Si il n'est pas salé, ce n'est pas un problème.

Sans avoir un salt différent à chaque itération (et différent pour chaque mot de passe), hasher plusieurs fois un mot de passe est totalement stupide. Ça a au contraire l'effet inverse puisque la plupart (voire tous ?) des algorithmes de hashage ont des possibilités de collision (et ne me sortez pas l'exemple du sha-1, ce n'est pas parce qu'on en a jamais détecté qu'il n'y en a pas). En hashant plusieurs fois le même mot de passe, on augmente d'autant plus la probabilité de collision et on réduit donc mécaniquement la sécurité de son hash.

Par exemple (avec des chiffres simples qui ne correspondent pas à la réalité), si votre algorithme à une probabilité de collision de 1%, sur 10000 combinaisons possibles, on à la probabilité de collision suivante (arrondies) pour chaque passage :
- Passe 1 : 100/10000 collisions
- Passe 2 : Il ne reste que 9900 combinaisons différentes. Pour cette passe, ça fait 99/9900 collisions
- Passe 3 : Il ne reste que 9801 combinaisons différentes. Pour cette passe, ça fait 98/9801 collisions
- Passe 4 : Il ne reste que 9702 combinaisons différentes. Pour cette passe, ça fait 97/9702 collisions
...
- Passe 50 : Il ne reste que 3553 combinaisons possibles
- Passe 70 : Il ne reste qu'une seule combinaison possible

En relisant le message initial, je vois que l'email est utilisé comme salt, donc constant (qu'il soit utilisé à chaque passe ou non ne change rien).

Donc je confirme, c'est un PEBKAC.

C'est vrai, mais remarque que les recouvrements doivent être si rares que c'est limite plus facile de trouver le mot de passe, surtout si c'est un mot de passe faiblard.

Erreur de conception selon mon papa : il vaut mieux hasher coté serveur et sécuriser l'envoi du mot de passe en SSL, non ?

Je ne suis pas d'accord avec l'exemple en python de tiramiseb : le hash à proprement parler, c'est 512 bits (dans le cas de sha512) et si tu fais correctement ton application, tu stockes uniquement ça. Là c'est le framework Python et sa façon d'afficher les objets qui est en cause. Si tu récupères juste le hash, tu ne peux pas deviner le nombre d'itérations, même si la longueur est peut-être une indication de l'algorithme utilisé.

Je viens de recevoir un coup de file de Mme Disse Hélène, elle en a MARRE que vous la citiez en permanence sur ce site !

Même si ta théorie est correcte (on l'appelle le birthday paradox), ce n'est pas un problème, parce qu'avec SHA1, et donc 160 bits en sortie, pour avoir 50% de chance de tomber sur une collision, il faut générer 2^80 hashes, soit... 1208925819614629174706176.

Lu à voix haute, ça fait environ 1 million de milliards de milliards de hashes. En en produisant 1 milliard par seconde (ce qui est beaucoup), il faudrait 38 millions d'années pour produire ce nombre de hashes SHA1.

Donc même avec 10000 passes, on est LOIN d'avoir une chance de tomber sur une collision. Et c'est pour le SHA1. Avec des algos qui ont 256 bits ou plus en sortie, on ne risque pas de voir une collision avant que le soleil explose.

Non, c'est bien 10000 fois plus protégé, puisque le principe est qu'un attaquant devra hasher aussi souvent pour générer la clé (pas en brute force, mais en attaque par dictionnaire). Et donc au lieu de faire un milliard de mots de passe potentiels, il n'en fera que 100 000.

Pas en force brute (ce serait plus ou moins identique quelque soit le nombre de hash), en utilisant un dictionnaire ou une expression régulière basée sur des dictionnaires.

Le fameux logiciel qui utilise PDBKDF2 avec 10000 hashages SHA256, ça serait pas iOS4 des fois ? du coup, j'ai envie de dire OUAIIIIIS ! C'EST APPLE les PEBKAC !!!!! (on est encore trolldi, non ?)

Pour le repérer, facile, il essaye toujours de capturer des pokemons.

Enfin déjà cracker du SHA256, faut en vouloir... si jamais t'as un doute, utilise le SHA512 mais bon hasher 10.000 fois...

faux mon chère Matthieu ...

le fait de hasher implique une diminution des possibilités pour l'enregistrement. en effet, quelque soit les données d'entrées, tu vas avoir la même quantité de sorties (n caractères fixes pour le hash).
Si tu repasse encore une fois en hash cette chaine, tu vas encore diminuer les possibilités.

Donc, plus tu le fait, plus le risque de collision est important (deux mots de passe différents donnant le même hash).

J'vois pas le rapport avec la maison close...

Faux, mon cher vimath, puisque dans PBKDF2 le mot de passe source est réinjecté a chaque itération, et une collision sur une des itérations intermédaire n'implique pas une collision sur le résultat final.