Spirit Of Hack

il y en a un, qui est dû au hashage. Comme la plupart des sites (et c'est une bonne pratique) vont hasher ton mot de passe à l'inscription, fournir un hash en entrée (qui sera donc ensuite hashé lui-même par dessus) élève au carré la probabilité de collisions et ce, quel que soit l'algo. Pour détailler un peu plus, j'avais écris sur un forum un truc un peu plus long à ce sujet ( http://www.zdnet.fr/actualites/les-10-mots-de-passe-a-ne-surtout-jamais-employer-39711315.htm#comment-28078864 )

La probabilité de collision est ce danger selon lequel il n'est pas nécessaire de connaitre le bon mot de passe pour accéder au compte.

disons qu'un principe de base en sécurité est surtout de ne jamais se satisfaire d'une probabilité très très (et autant de "très" qu'on veut)...faible. Parce que quel que soit le score de proba, ça veut surtout dire que c'est possible.

Et un peu dans la même idée, ce qui parait faible aujourd'hui ne présage pas de ce que sera demain. Je m'explique : même si on constate aujourd'hui que forcer un algo de hash à la recherche d'un clair correspondant peut prendre des siècles, ce n'est pas non plus une valeur de sécurité. Je le dis avant que d'autres pensent que, bon, SHA-x ça va, on est pas couchés si on veut s'y attaquer. Je réponds : oui, _aujourd'hui_. Et demain ?
Quand CUDA est sorti pour le grand public on est passés quasiment du jour au lendemain de dizaines de millions de mots de passe par seconde à plusieurs centaines pour MD5 (je ne veux pas parler ici de la sécu de MD5, c'est juste pour prendre une base d'exemple connue de tous)

Quant à utiliser un autre algo ( je comprends : "que celui de la base du site"), je vois difficilement comment étant donné qu'à priori quand l'utilisateur s'inscrit il n'est pas censé savoir ou prédire quel algo va se cacher derrière et s'y adapter en fonction (c'est à dire : en choisir un autre dans ton plugin si j'ai bien compris ce que tu voulais dire).

Enfin, concernant le fait d'y opérer une transformation, même si je trouve l'idée de départ d'un mot de passe unique mais qui s'adapte au contexte séduisante je me dis qu'avec toutes ces opérations (salt avec le domaine, hash, manip' (s ?) du hash) on a peut être aussi bien (et vite) fait de tout simplement revenir au bon vieux générateur aléatoire qui, en plus, présente l'intérêt de pouvoir élargir le charset (on en a pas parlé, de ça !).

le mieux si tu réfléchis réellement à une nouvelle méthode de sécurité serait éventuellement d'en rédiger un RFC. C'est ce qu'on fait dans les développements de projets quand il s'agit de présenter et demander les avis autours d'une modification majeure, ca permet de bien expliquer dans le détail et de façon claire et complète l'ensemble de ce à quoi on pense.

On devrait donc y trouver la description de la problématique actuelle ou des champs (besoins) non couverts par les solutions déjà disponibles, en quoi la solution qui est proposée pourrait y apporter des réponses pertinentes, l'étude de tous les aspects de la question, des exemples théoriques avec mises en situation, éventuellement des schémas simples (ca doit rester en txt) si nécessaire, des références vers les notions citées qui sont importantes...
En bref, une mise à plat complète qui permet à chaque personne souhaitant y réfléchir d'avoir tous les éléments. Un exemple de ce genre de document : http://fz-corp.net/repository/echo_proposal.txt

Merci pour l'info, je n'avais en effet pas vu ce logiciel.