News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Base de Données - Membres - Sécurité ?

Started by Yvanoph, March 11, 2019, 12:08:17 PM

Previous topic - Next topic

Yvanoph

Bonjour / Bonsoir à toutes et tous, ayant installé récemment une demi douzaine de Forum en Version 2, je constate qu'il y a un "salt" en matière de protection des mots de passe.

Bon, il est évident qu'une protection en "MD5" puis en "SHA1" ne valent rien, tout le monde de conscient s'en est aperçu depuis longtemps puisqu'il existe des "rainbow tables" capables de nous transformer tout mot de passe en clair en quelques dixièmes de seconde ?
Donc là dessus a été greffé un "salt", comme dit plus haut !
Le problème est qu'il est depuis peu possible de trouver des "rainbow tables" de "salt", et nous retombons dans le même éternel souci...

Je compte donc outre la "pincée de sel" "poivrer" le total, via un deuxième "salt" ? Et, histoire de rendre quasi inviolable le tout, tout simplement faire usage de "bcript" en surcouche ? En principe, il faudrait alors au bas mot une trentaine de jours pour décoder un tel mot de passe ?
Néanmoins, je compte compliquer la chose en rajoutant une autre variable dans le mot de passe tapé par le Membre, à savoir soit son adresse courriel, qui lui est unique, soit son pseudo ?
Ce qui en gros donnerait quelque chose dans le genre :

bcript($salt1.sha(Indentifiant.motDePasse).$salt2);

En principe cet exemple est plus fiable puisque l'Identifiant ne change pas ? Alors qu'une adresse courriel peut l'être à tout instant, le mot de passe devenant alors caduque de suite... Et obligerait donc à demander au Membre de le changer de suite, mais avez le risque que ce ne soit pas réalisé de suite en cas de micro coupure intempestive ?

Donc question, dans quels fichiers, afin de ne pas perdre de temps à les ouvrir tous les uns après les autres pour les consulter, est-il fait appel à l'identification ? S'il y a d'autres endroits que les LogInOut, Register par exemple ? Voire quelle est le nom de la fonction appelée ?


Cordialement, Yvanoph---
SMF V - 1.1.20 Thème personnel "Boréal"

maximus23

Bonjour,

Il y a un patch non officiel pour le php 7.2 qui lui travaille avec Crypt / LibSodium / etc....

Un plus haut niveau est conçu pour la nouvelle version 2.1 de Smf.

Les fichiers concernés pour le pass sont :

Sources/Load.php

Sources/LogInOut.php

Sources/Profile-Modify.php

Sources/Profile.php

Sources/Register.php

Sources/Subs-Auth.php

Les plus important pour la génération sont Load et Subs-Auth les autres c'est pour l'utilisation du pass.

:)
Pas de support par PM ou Courrier...Veuillez utiliser le forum pour vous avoir une réponse rapide à votre demande d'aide. Merci.
Amitiés et à Bientôt...
No support by PM or Mail...You will get better and faster responses in the support forums. Thank you.
Have a nice day...

Yvanoph

Et tout aussi content de vous revoir ?

Bon, et bien il y en a plus que je ne le pensais initialement, mais bon, rien d'impossible à qui veut !

Par contre, php en V-7.2, réellement fiable et stable ? J'ai toujours des doutes quant à ces MàJ et dois encore traîner en 7.0 sur mes Serveurs... D'autant qu'un système qui fonctionne bien n'a logiquement pas à être mis à jour ? Normalement complété d' "AddOns" les plus divers soit, pour le reste je n'en vois pas l'utilité...
D'ailleurs depuis que je suis passé en 7.0 pour php, mes Tags perdent systématiquement les Majuscules au moment de leurs créations ! Obligé d'aller les reprendre directement ligne par ligne dans la Base, pffff, le progrès recule à grand pas quoi...
Néanmoins question,Crypt est aussi ardu et fiable que Bcript ?

Quant à la Version 2.1 de SMF, existe t-il un "UpDate" depuis une V-2.0.15 et est-elle fiable et stable ? D'autant que, comme pour mes autres Forums, j'allais m'attaquer aux css pour les habiller à ma mode et mes goûts, donc autant que je fasse les MàJ adéquates AVANT de tout modifier ? Mais dommage, je venais juste de finir de modifier les php à ma façon, pffff...
Et les mots de passe sont ils toujours bâtis sur la concaténation d'un MdP et d'un "salt" ou  bien sont ils devenus plus complexes, genre ce que je pensais faire ci dessus ?


Dans tous les cas, encore merci pour le retour, cordialement, Yvanoph---
SMF V - 1.1.20 Thème personnel "Boréal"

maximus23

Bonjour,

Pour la mise à jour en 7.2 tu regardes sur le forum tu auras les infos et en principe c'est une mise à jour qui sera certainement suivie par Smf. Si tu ne vois pas je te mettrai le lien :)

Moi ici il tourne sur quelques sites ou les hébergeurs sont passés en 7.2 et cela ne pose pas de soucis majeurs.

La seule chose à bien vérifier est d'avoir des modules bien à jour car c'est là en général que les choses se gâte en cas de soucis.




Pour la 2.1 c'est une RC pour le moment et on sait faire une mise à jour à partir de la version 2.0.15 de Smf mais il faut l'utiliser avec parcimonie car certains bugs peuvent toujours subsister.

De plus entre RC il faut toujours repartir de zéro car pas de mise à jour à partir du gestionnaire de paquets.

Pour ce qui est du pass c'est du Bcrypt / sha512 / Salt

Tu peux voir les infos du code si tu regardes sur GitHub.

Je ne sais pas quelle sera la codification finale car cela avance très vite au niveau sécurisation avec le php 7.3 qui va arriver aussi à un stade de standard normal.

:)

Pas de support par PM ou Courrier...Veuillez utiliser le forum pour vous avoir une réponse rapide à votre demande d'aide. Merci.
Amitiés et à Bientôt...
No support by PM or Mail...You will get better and faster responses in the support forums. Thank you.
Have a nice day...

alexetgus

Il ne faut pas oublier les fichiers JavaScript. Les mots de passe ne partent pas en clair sur le réseau, un JS en sort le hash.

Sinon, je ne vois pas à quoi ça sert de se casser la tête à avoir des hash "in-devinables" ne figurant dans aucune liste.
Le minimum, c'est d'avoir du SSL. Si tout transite en clair, c'est perdu d'avance.
Ensuite, des mots de passe complexes ne figurent dans aucune liste. On pourrait avoir un sha65536, ça ne changerait rien du tout face à des mots de passe comme 123456 ou password...

Pour finir, si un mec réussit à mettre les yeux sur la base de données, c'est pas les hash qui me poseront du souci.
Un hacker ne s'emmerdera pas à décoder les hash des membres si il a accès à la base... ::)

Yvanoph

Bonjour,

@maximus23, pas de souci, point ne vais employer php V-7.2 tant qu'il n'est "béton" ?
De même, point de Version SMF en RC, courant après le temps hélas...
Et sur la demi douzaine de Forums mis en ligne en V-2.0.15, il y en a au moins deux qui ne doivent dans aucun tomber en rideau sur quelque fonction appelée ?

En parlant de "rideau", en testant par principe tous mes Boutons, je viens de m'apercevoir que celui pour s'inscrire me renvoie une 500 !
N'ayant touché qu'aux fichier.template.php et aux css en relation (N'ayant pas le temps de tout modifier, tant en php que css qu'html, comme je l'avais fait pour mon thème "Boréal" !), j'avoue, vue de loin, ne pas voir d'où pourrait provenir la boulette...
Auriez vous une idée, un indice ?

@alexetgus, merci pour le retour, mais JAMAIS je ne passerais par un SSL, pour X raisons :
- Pollution INADMISSIBLE de la #Planète par des allers et retours à des distances impensables ?
- Ralentissement "abomifreux" du transfert par un protocole bien trop lourd...
- Espionnage GARANTI quand nous savons QUI est derrière la délivrance des certificats (Pourquoi croyez-vous que la demande de suppression des accents a été exigée PARTOUT, demande que SEULE la #France a fait la stupidité d'accepter, au principe fallacieux de "simplifier les choses"...) ?

D'autant qu'il y a bien plus facile à faire ? Tout simplement, comme je l'ai fait, un accès à ... l'accès via un mot de passe à trente deux caractères plus d'autres choses, le tout crypté en trois couches...
De même en ce qui concerne l'accès à la DB, elle même située sur un autre Serveur, via un .htaccess qui n'autorise qu'une seule IP...
Pourquoi faire compliqué ::) quand il est possible de régler le problème simplement à la base O:) ?

Enfin, effectivement, j'avais vu les appels au javascript dans les fichiers .php, mais il est vrai que pour celui qui ne sait pas, autant prévenir ;) !


Encore MERCI pour les retours, cordialement, Yvanoph---
SMF V - 1.1.20 Thème personnel "Boréal"

alexetgus

Quote- Pollution INADMISSIBLE de la #Planète par des allers et retours à des distances impensables ?
- Ralentissement "abomifreux" du transfert par un protocole bien trop lourd...
- Espionnage GARANTI quand nous savons QUI est derrière la délivrance des certificats

Alors là, je ne suis pas certain que tu ais compris les subtilités du SSL...
Enfin bon, si tu préfères le clair, tu n'as pas à redouter l'espionnage, hein ? ::)

alexetgus

Pour en revenir à ton souci de hash, pourquoi ne pas utiliser de hash très peu utilisés et, donc, ayant un minimum de chances de se retrouver sur le net ?

Tu as le choix, sha224, sha384 (quoi que).
Le sha224 pourrait être ta solution.

Le seul souci, c'est que ce hash n'est pas implémenté par PHP, tout du moins, pas à ma connaissance.
Tu serais donc obligé de l'obtenir avec des commandes shell via exec() ou shell_exec()
Mais bon, c'est rapide à faire et relativement simple à sécuriser.


Ton souci m'intéresse, donne nous des nouvelles ! ;)

Advertisement: