splithash (demande d'avis de mathématiciens) pour une fonction de hash

samυncle · Le 02/10/2012, à 01:23

Bonjour

J'aimerais vous présenter une idée que j'ai eu. Je ne sais pas si c'est une bonne idée (ça me semble une bonne idée) mais comme l'un des principes en hachage est:

Never try to invent your own crypto, always use a standard that has been designed by experts.

Bah je demande votre avis.
L'idée de base est de stocker de manière aléatoire le sel dans le hash. On peut l'utiliser avec des fonctions de hash de base comme SHA512, on peut aussi très bien cascader plusieurs fois la fonction de hash, ce n'est qu'a la fin du processus que splithash intervient, donc c'est assez souple d'utilisation. Il y a deux mode, le mode insertion et ajout (fonctionnement très similaire).

Exemple
Comment ça marche:
L'utilisateur rentre un mot de passe, comme admin1234
On a une clé de 36 caractères hex qu'on stocke de la manière la plus sécurisée possible: a42bb…
On tire au hasard un nombre de 0 à 63, genre 8, on ajoute 2 2
On prend un salt au hasard entre 17 et 32 caractères en hexa: 606c a607 7956 7b40 73
Dans notre cas on a 18 caractères donc on fait 18 - 16 ce qui donne 2
On fait hash(pass + sel) (hash peut être n'importe quelle fonction, genre SHA512, ça peut aussi être plusieurs itérations, comme 1000 fois sha512), dans notre cas ça donne le résultat suivant:
60b9a9d15618f769e65859ee5c4147489e9faf981520980a0cc3f4d510aa94287b475ba3d028dda445e4798aa25adbf75c4d9c94f1db0d1fb12fd3072f7db9ad

Maintenant on va stocker notre sel dans le hash en splitant le hash en 2 + en mettant les informations pour retrouver ou est notre sel
On a un décalage de 10, en hexa ça donne 0a. On fait un XOR avec notre clé ce qui donne, ae
On chiffre la longueur du sel + sel avec la suite de la clé, (je me suis pas amusé a faire le XOR ici) 2606ca60779567b4073

Selon les modes de fonctionnement soit on insère la position + le sel à la place du hash, ce qui fait qu'il garde la même longueur, soit on les ajoute.
En mode insertion:
aeb9a9d152606ca60779567b4073147489e9faf981520980a0cc3f4d510aa94287b475ba3d028dda445e4798aa25adbf75c4d9c94f1db0d1fb12fd3072f7db9ad
Pour décoder, on décode la position sur le premier octet, on se rend à cette position, on décode la longueur du sel puis le sel et on le récupère comme ça. Après c'est du hachage normal

Avantages supposé:
- On cache le sel, avec le mode insertion rien ne permet de le distinguer d'un hash normal. On ne prend pas plus de place. Le même champ peut être utilisé dans la base de donnée
- On a 64 positions possible du sel, + 32 longueurs possibles. Ça nous fait 1024 possibilités de sel. C'est assez bon (en temps normal on stocke le sel en clair).
- On évite tout pré calcul comme avec des tables arc-en-ciel. On est obligé de brute forcer chaque hash. Deux mots de passe identiques donneront un hash totalement différent
- On crypte le sel, ce qui complexifie le processus de sa découverte

Faiblesses:
- Je ne sais pas dans quelle mesure enlever des octets à SHA512 est nuisible à sa sécurité (en mode insertion)
- Je ne sais pas si ça ralenti vraiment une personne et dans quelle mesure exactement
- faiblesse au niveau du XOR de la position (je vais tenter de corriger ça)
- Il faut garder la clé secrète (bon ça c'est valable pour tout chiffrage)

Dernière modification par samυncle (Le 02/10/2012, à 01:26)

Pylades · Le 02/10/2012, à 02:40

Il n’y a pas un principe de sécurité qui dit qu’il ne faut jamais faire confiance à l’obscurité de l’algorithme ?

samυncle · Le 02/10/2012, à 02:45

Πυλάδης a écrit :

Il n’y a pas un principe de sécurité qui dit qu’il ne faut jamais faire confiance à l’obscurité de l’algorithme ?

oui et il est pas obscure. Vu que je le décrit ici.

maxpoulin64 · Le 02/10/2012, à 03:13

Humm, je suis loin d'être un expert, mais il me semble que si quelqu'un tombe sur ton truc final, vu que les informations pour décoder la position du sel dans le hash y est, bah il est facile de faire une conversion "gros machin" => hash + sel, puis après t'es revenu au problème de départ, donc ça ne me semble vraiment pas pertinent du tout à part peut-être dissimuler le salage. Mais quelqu'un qui s'introduit dans ton système, il aura aussi accès sans trop de problèmes à ta fonction d'encodage/décodage, donc useless.

Ta sécurité reviens pas mal à ta situation initiale, mais en un peu moins bon puisque tu réduis en plus la taille du hash (donc moins de possibilité, donc table arc-en-ciel un peu plus petite). Garder le hash complet + le sel dans un autre champ augmente le nombre de possibilité (16^(taille du hash+taille du sel)), alors que dans ton cas, il "suffit" de 16^(taille du hash final) pour faire une table. Et enfin, il me semble que l'ajout de sel pour chaque mot de passe haché est déjà très suffisant pour l'instant, étant donné qu'il faut une table par sel utilisé.

La seule sécurité ajoutée, c'est vraiment la clé secrète, dans la mesure où elle reste secrète bien sûr. Déjà XOR est pas ce qui a de plus sécuritaire (suffit de connaitre des bouts de données pour la forcer), mais comme j'ai dis, à moins que tu sécurise mal ta base de donnée, il y a de bonnes chances qu'un intrus ait aussi accès au code de l'application et donc ait aussi accès à la clé secrète pour décoder les hash de la BDD.

(J'espère que ce post est pas trop le bordel, j'ai un peu de mal à expliquer ce genre de chose que je maitrise pas vraiment à la base)

nesthib · Le 02/10/2012, à 04:11

À mon avis c'est une très mauvaise solution… rien qu'à cause de la diminution de taille de ton condensat tu diminues de 112 bits la sécurité, et pire, tu permets des attaques par collision. Je ne saurais pas calculer la possibilité d'une attaque mais a priori rien ne suppose que la complexité de génération d'une collision soit linéaire. Il peut être beaucoup plus facile de créer une clé par collision lorsqu'il manque quelques bits que seulement le facteur brut qui en est enlevé (sachant qu'ici on est déjà à un facteur 2^112).
OK, ici tu préconises une solution robuste comme le SHA-512, mais pour comparer objectivement il faut comparer à la sécurité déjà apportée par le SHA-512 lui-même. En d'autres termes, si tu faisais la même chose avec du MD5, est-ce qu'au final ta solution ne rendrait pas la fonction de hachage plus vulnérable qu'elle l'est déjà ? Essaie de générer des condensats MD5 en ajoutant 20% de degré de liberté… c'est royal (en encore je ne te parle que de force brute, s'il s'avère qu'on peut forger une attaque sur les bits manquants il peut être, comme je le dis plus haut, beaucoup plus facile de trouver une collision).
Pour le côté « secret » de la position du sel, ça ne revient ni plus ni moins qu'à faire de la stéganographie… avec les défauts que cela comprend. Je ne dis pas que la stéganographie est toujours une mauvaise solution, mais dans ce cas ça l'est. Tu fais ici clairement de la sécurité par l'obscurité (car le principe de ta solution repose sur le fait que l'attaquant ne sait pas qu'il y a un sel caché), ce qui est donc nul (j'entends au niveau de la sécurité) d'un point de vue strictement cryptographique.

Dr Le Rouge · Le 02/10/2012, à 08:33

J'aurais bien fait un post à rallonge mais nesthib m'a grillé ^^

En gros : ça n'apporte pas grand chose niveau sécurité (un facteur 1000 c'est sympa mais, comparé à la complexité d'une attaque sur SHA-512, c'est rien du tout) et, en plus, ça peut grandement faciliter une attaque (étant donné que le nombre d'octet provenant vraiment du hash est plus faible). Ça ne me surprendrait pas du tout que l'attaque de SHA-512 soit facilitée par un facteur bien supérieur à 1000 ; du coup, tu y perds.

Après, si tu ajoutes ton sel sans « écraser » de données (mode ajout ?), pourquoi pas ? Tu n'affaiblis pas ton hash en tout cas, donc tu as toujours au moins la sécurité qu'il t'apporte. Sécurité qui devrait suffire pour un moment ^^

Grünt · Le 02/10/2012, à 09:50

Il ne faut jamais enchaîner plusieurs fonctions de hashage (identiques ou pas), ça diminue à chaque fois la taille de l'espace de destination de ta fonction. L'ensemble des "hashs de hashs" est plus petit que l'ensemble de tous les hashs possibles.

samυncle · Le 02/10/2012, à 20:36

Alors j'ai pas mis le mode ajout mais en effet lui est non destructif. Donc tout les désavantages de perte de bits dans le HASH sont résolut.

Grünt a écrit :

Il ne faut jamais enchaîner plusieurs fonctions de hashage (identiques ou pas), ça diminue à chaque fois la taille de l'espace de destination de ta fonction. L'ensemble des "hashs de hashs" est plus petit que l'ensemble de tous les hashs possibles.

Oui et non. Je ne le fait pas dans mon cas mais ça peut se faire (dans ce cas on s'arrange que ça soit le plus lent possible pour bruteforcer). T'as un cas intéressant de 10K de MD5 . Et pour le moment bien que ça soit du MD5 ben on arrive pas a le casser.

Joss17 · Le 02/10/2012, à 21:32

Pour le sel, effectivement, il te faut l'ajouter, mais le rendre «secret» à un intérêt faible. Je doute que tu puisse de toute manière le rendre véritablement non découvrable tout en le stockant dans la db (sinon comment tu va le retrouver dans ta propre application ?)
Si tu veux une sécurité ad hoc pour un site web, tu fais un sel par utilisateur dans la db, que tu concatène avec un sel général qui n'est pas dans la base mais dans un fichier, puis tu passe ça avec le mot de passe dans un hmac sha512.

a+

Dr Le Rouge · Le 03/10/2012, à 07:46

Et si tu veux être tranquille pour encore plus longtemps, SHA-3 vient d'être choisi

Marie-Lou · Le 03/10/2012, à 07:57

Je ne comprends rien à ce que vous dites mais je suis de tout cœur avec vous dans cette période difficile, les mecs.

Dr Le Rouge · Le 03/10/2012, à 21:38

Roooo, c'est pas si méchant les fonctions de hachage. Wikipedia a tout ce qu'il faut et on devrait être en mesure de répondre à tes questions si tu te penches sur le sujet.

Allez, ça te fera une raison de procrastiner de plus

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/10/2012, à 01:23

splithash (demande d'avis de mathématiciens) pour une fonction de hash

#2 Le 02/10/2012, à 02:40

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#3 Le 02/10/2012, à 02:45

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#4 Le 02/10/2012, à 03:13

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#5 Le 02/10/2012, à 04:11

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#6 Le 02/10/2012, à 08:33

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#7 Le 02/10/2012, à 09:50

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#8 Le 02/10/2012, à 20:36

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#9 Le 02/10/2012, à 21:32

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#10 Le 03/10/2012, à 07:46

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#11 Le 03/10/2012, à 07:57

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

#12 Le 03/10/2012, à 21:38

Re : splithash (demande d'avis de mathématiciens) pour une fonction de hash

Pied de page des forums