[LeHuron]

Hello all,

Comme une communauté c'est aussi fait pour s'entre aider, j'ai besoin de votre culture les kopains.
Connaissez vous (hormis le logiciel Crack qui fait du brute force), un **No Sms** prog qui permette d'inverser crypt si on connait le $SALT (ou tout du moins de retourner un ensemble de solutions).
Ou mieux encore, connaitriez-vous un site qui fait office de base de connaissance pour inverser la-dite fonction ?

Merci d'avance,
@+

[zours]

A cause du salt, justement, ça se reverse pas si facilement. T'échapperas pas au BF.

[LeHuron]

Briseur de rêves..

[_o_]

Connaissez vous (hormis le logiciel Crack qui fait du brute force), un **No Sms** prog qui permette d'inverser crypt si on connait le $SALT (ou tout du moins de retourner un ensemble de solutions).

Absolument pas, car le sel est ajouté justement pour compliquer la tache du méchant pirate.

Une bonne fonction de hash a pour propriété, entre autre¹, de générer des hash radicalement différents pour des valeurs peu différentes (on appelle cela l'effet avalanche). Le but est justement de ne pas pouvoir «deviner» les caractères composant la valeur par tâtonnement.

Mais deux problèmes sur un hash simple :
1) Sur un fichier de hash de mots de passe forcément accessible en lecture, si un attaquant connaît le mot de passe de l'utilisateur X, et que le hash du pass de l'utilisateur X est identique à celui de l'utilisateur Y, alors les mots de passe sont identiques.
2) Tout le monde connaît les rainbow tables qui permettent la correspondance entre des hash (md5, sha pour ne citer qu'eux) et des mots de passe usuels, courts, et/ou contenant des caractères simples (alphanumériques en général).

D'où l'utilisation du sel, concaténé au mot de passe par exemple, et unique pour un utilisateur, qui permet de compliquer le boulot du pirate. Le sel de chacun est d'ailleurs stocké en clair, car sans cela, le système ne serait pas capable de réaliser l'authentification, mais cela n'a pas d'importance, grâce à l'effet avalanche. D'où, si l'on reprend les deux points ci-dessus :
1) Deux utilisateurs ayant le même mot de passe auront des hashs différents (car le sel est différent). Certains proposent par exemple d'utiliser simplement le login de l'utilisateur comme sel.
2) Le sel augmente sensiblement la taille de la chaîne utilisée pour le hash. De plus, le sel peut contenir des caractères non standards. Deux caractéristiques qui rendent beaucoup plus aléatoires la recherche inversée par rainbow tables. Pour info, les tables accessibles librement sur Internet ne contiennent que les empreintes pour les mots de passe de 8 caractères alphanumériques ou moins, pour des raisons de taille de stockage et de temps de traitement (mais si quelqu'un a une url infirmant ce que je viens d'écrire, qu'il me la transmette ).

En conclusion, le sel, correctement utilisé, peut compliquer sérieusement le crack d'un mot de passe.

¹: il y a bien évidemment d'autres caractéristiques indispensables, parmi lesquelles notamment l'impossibilité de construire à volonté des collisions.

[LeHuron]

Merci pour ta réponse _O_.
C'est clair et instructif
Y a plus qu'à BF (suis un acharné) ou à chopper le mdp avant chiffrement.

[Folcan]

Et si on sait que le sel est créé par exemple a partir du login, ya moyen de reverser jusko hash d'origine et de retrouver le pass avec une rainbow ?

[_o_]

Et si on sait que le sel est créé par exemple a partir du login, ya moyen de reverser jusko hash d'origine et de retrouver le pass avec une rainbow ?

Il n'y a pas de hash d'origine. Au lieu de faire l'empreinte du mot de passe seul, on calcule l'empreinte de la concaténation du sel et du mot de passe.

Exemple en md5 :
Sans sel : password => 5f4dcc3b5aa765d61d8327deb882cf99
Avec sel : selpassword => ba840f4cf3309d3caeaaa5015755a254

Tu peux essayer de retrouver le mot de passe en fonction du hash sur les sites connus (j'ai un peu fait exprès de choisir des tailles appropriées). Le hash sans sel est récupérable (8 caractères alphanumériques), l'autre non (en tout cas pour moi, mais je ne doute pas que certains aient des bases privées plus intéressantes), probablement à cause de sa taille. On remarque également l'effet avalanche : des chaines d'entrée à peine retouchées engendrent des empreintes complètement différentes.

Note bien que le sel de chacun doit être disponible en clair pour le processus réalisant l'authentification : le système demande le mot de passe à l'utilisateur, le concatène au sel, calcule l'empreinte et la compare à celle stockée dans ses données. [Edit : Suivaient des bêtises que je me dois de censurer]

Le truc intéressant aussi, c'est que du coup, il n'y a pas besoin de demander à l'utilisateur de choisir des caractères tarabiscotés pour son mot de passe (au risque que le téléphone de l'administrateur soit en perpétuel dérangement, croulant sous les demandes d'utilisateurs ayant oublié leur mot de passe). Il suffit d'utiliser une fonction de génération de sel utilisant elle-même des caractères spéciaux. Mais là dessus je dois louper quelque chose, parce que j'ai rarement vu une méthode de ce style mise en oeuvre, alors que ça me parait très intéressant.

/me va stf(u|w).

Edit: une URL résumant pas mal le principe, en abordant aussi le principe de sel secret : http://en.wikipedia.org/wiki/Salt_%28cryptography%29

[offw0rld]

Nop avec un grain, les rainbows table sont inutilisable, en revanche ça simplifie le bruteforce pour tout les users ayant des passe trop cour.
Par contre, un user peut recupéré un passe grace a une injection sql, et ne pas connaitre le sel.
Puis si l'attaquant a un accès au moins au ftp, et qu'il découvre le grain en regardant la fonction d'authentification, il est plus simple de la modifier pour enregistrer les passes en clair.
Mais la plupart des scripts kiddies ne regarde que le fichier config, et lance le bruteforce.
Donc un grain de sel renforce vraiment bien la sécurité, surtout pour une si simple implémentation.
Ensuite il doit bien y avoir d'autre délire pour cacher le grain.