coson Posted February 7, 2014 Share Posted February 7, 2014 Bonjour, La sécurité des nos boutiques, devrais être une préoccupation majeure des développeurs et des utilisateurs finaux, je ne suis pas développeur mais j’espère susciter suffisamment votre intérêt avec ce sujet. Afin d’améliorer considérablement la sécurité des formulaires de création de compte, du login des utilisateurs, ainsi que de l’accès au Backoffice, je me suis toujours posé la question, pour quel raison les développeurs Prestshop n’ont pas encore intégré le chiffrement et ou le HASH, contre les éventuels attaques des hackers ? Pour mieux comprendre l’enjeu et les possibilités techniques de mise en place, je vous invite à consulter les recherches suivantes : http://guillaume-affringue.developpez.com/securite/chiffrement/?page=3#LIII Ce débat et ouvert à tous (développeurs ou simples utilisateurs) et je compte sur votre participation, en espérant qu’une solution concrète sera proposée rapidement, dans notre intérêt commun. Cordialement, Daniel. Link to comment Share on other sites More sharing options...
SMorillon.com Posted February 7, 2014 Share Posted February 7, 2014 Bonjour, Tous les mots de passe sont crypté en md5 dans la base de données avec la technique du grain de sel... Vous indiquez ne pas être développeur, qu'es ce qu'il vous fait donc pensez que Prestashop n'est pas sécurisé sans avoir vu son code ? Bonne journée. Link to comment Share on other sites More sharing options...
coeos.pro Posted February 7, 2014 Share Posted February 7, 2014 je dirais même mieux : les mots de passe ne sont pas cryptés mais hashés, c'est pour ça que l'on ne peut pas récupérer un mot de passe, et quand on clique sur "mot de passe oublié" un nouveau mot de passe est généré et envoyé à l'email du client. Tu n'es pas développeur et apparemment le type qui a fait l'article que tu cites non plus. Le MD5 est déprécié et NE DOIT PLUS ETRE UTILISE. Link to comment Share on other sites More sharing options...
Prestaspirit Posted February 7, 2014 Share Posted February 7, 2014 Bonjour, Curieux comme affirmation pour un non développeur ? Prestashop est largement sécurisé coté front pour les données qu'il renferme, coté admin vous pouvez aussi suivre les recommandations de la doc Prestashop pour votre partie administration Établissement d'une authentification de base (.htaccess) ou utiliser ce module si vous ne souhaitez pas ou ne pouvez pas mettre les mains dans le code Module Secure Admin Link to comment Share on other sites More sharing options...
coson Posted February 7, 2014 Author Share Posted February 7, 2014 Bonjour, Tous les mots de passe sont crypté en md5 dans la base de données avec la technique du grain de sel... Vous indiquez ne pas être développeur, qu'es ce qu'il vous fait donc pensez que Prestashop n'est pas sécurisé sans avoir vu son code ? Bonne journée. Bonjour, Curieux comme affirmation pour un non développeur ? Prestashop est largement sécurisé coté front pour les données qu'il renferme, coté admin vous pouvez aussi suivre les recommandations de la doc Prestashop pour votre partie administration Établissement d'une authentification de base (.htaccess) ou utiliser ce module si vous ne souhaitez pas ou ne pouvez pas mettre les mains dans le code Module Secure Admin je dirais même mieux : les mots de passe ne sont pas cryptés mais hashés, c'est pour ça que l'on ne peut pas récupérer un mot de passe, et quand on clique sur "mot de passe oublié" un nouveau mot de passe est généré et envoyé à l'email du client. Tu n'es pas développeur et apparemment le type qui a fait l'article que tu cites non plus. Bonjour a tous, Je tiens à vous remercie pour vos réponses mais j’ai l’impression que vous n’avez pas bien compris la question ou je me suis mal exprimé …. Je constate que le mot de passe est "envoyé en claire " et n’est pas HASHE cote Client", ce qui pose un réel problème de sécurité ! Les travaux de Guillaume Affringue indique plusieurs exemples des hachages « avant envois « avec de protocoles beaucoup plus sécurises tes que les SHA128 ou SHA254 bits. Lien : http://guillaume-affringue.developpez.com/securite/chiffrement/?page=3#LIII Je ne parle pas du Hash dans la base de donné qui est en MD5, aujourd’hui particulièrement faible et vulnérable …. J’attends vos réactions à ce post. Daniel. Link to comment Share on other sites More sharing options...
Prestaspirit Posted February 7, 2014 Share Posted February 7, 2014 Encore une fois vous affirmez sans démontrer! Ou voyez vous que le mot de passe client est stocké ou affiché en clair sur la boutique? A aucun moment vous retrouverez ce mot de passe tel qu'il a été indiqué à l'inscription sur le site et si vous parlez justement de cette envoi du mot de passe c'est à vous de mettre en place un protocole SSL sur votre boutique. Link to comment Share on other sites More sharing options...
coeos.pro Posted February 7, 2014 Share Posted February 7, 2014 Je ne parle pas du Hash dans la base de donné qui est en MD5, aujourd’hui particulièrement faible et vulnérable …. ça y est, tu m'énerves ! Je constate que le mot de passe est "envoyé en claire " et n’est pas HASHE cote Client", ce qui pose un réel problème de sécurité ! et ensuite ? il faudrait que quelqu'un intercepte le flux de données entre mon ordi et mon FAI ou le serveur de la boutique, qui a les moyens de faire ça ? (la NSA ok, mais qui d'autre), et tout ça juste pour voir tes commandes passées sur archiduchesse ? si mon ordi est vérolé un haschage coté client est totalement inutile et inefficace. 1 Link to comment Share on other sites More sharing options...
SMorillon.com Posted February 7, 2014 Share Posted February 7, 2014 (edited) il faudrait que quelqu'un intercepte le flux de données entre mon ordi et mon FAI ou le serveur de la boutique, qui a les moyens de faire ça ? (la NSA ok, mais qui d'autre) Se placer entre un ordi et un serveur est "relativement simple" : il suffit d'être connecté en Wifi sur le même réseau et regarder tout ce qui passe sur le réseau (les cas les plus simple sont dans les Mc Do ou pendant une conférence par exemple). et tout ça juste pour voir tes commandes passées sur archiduchesse ? C'est clair : il faut toujours prendre en compte le risque et le risque sur un Prestashop n'est pas énorme : pas de numéro de carte bleu ou autres données sensibles. si vous parlez justement de cette envoi du mot de passe c'est à vous de mettre en place un protocole SSL sur votre boutique. Comme le dit Prestaspirit, il suffit de mettre en place un SSL pour avoir du https mais il faut payer pour ça et aujourd'hui seul les banques ou les gros groupes l'ont... Edited February 7, 2014 by SMorillon.com (see edit history) Link to comment Share on other sites More sharing options...
coson Posted February 7, 2014 Author Share Posted February 7, 2014 ça y est, tu m'énerves ! et ensuite ? il faudrait que quelqu'un intercepte le flux de données entre mon ordi et mon FAI ou le serveur de la boutique, qui a les moyens de faire ça ? (la NSA ok, mais qui d'autre), et tout ça juste pour voir tes commandes passées sur archiduchesse ? si mon ordi est vérolé un haschage coté client est totalement inutile et inefficace. Le hachage cote client permet de préserver le mot de passe (SANS SSL) à toute interception en réseau local, wifi etc… Petite histoire : Yahoo avant de sécuriser l’accès aux comptes email, utilisait du hachage cote client …. De plus l’accès à la boutique et à l’historique de transactions est très dangereux si vous vendez des par exemple des produits numériques … Link to comment Share on other sites More sharing options...
coson Posted February 7, 2014 Author Share Posted February 7, 2014 Encore une fois vous affirmez sans démontrer! Ou voyez vous que le mot de passe client est stocké ou affiché en clair sur la boutique? A aucun moment vous retrouverez ce mot de passe tel qu'il a été indiqué à l'inscription sur le site et si vous parlez justement de cette envoi du mot de passe c'est à vous de mettre en place un protocole SSL sur votre boutique. Le hachage cote client permet de préserver le mot de passe (SANS SSL) à toute interception en réseau local, wifi etc… Petite histoire : Yahoo avant de sécuriser l’accès aux comptes email, utilisait du hachage cote client …. De plus l’accès à la boutique et à l’historique de transactions est très dangereux si vous vendez des par exemple des produits numériques … Link to comment Share on other sites More sharing options...
SMorillon.com Posted February 7, 2014 Share Posted February 7, 2014 (edited) De plus l’accès à la boutique et à l’historique de transactions est très dangereux si vous vendez des par exemple des produits numériques … Je pense que nous n'avons pas la même définition du mot dangereux... Dans le cas que vous citez, cela peux entrainer une perte de chiffre d'affaire... de la même façon que si un client transmet les fichiers numériques à son voisin... Edited February 7, 2014 by SMorillon.com (see edit history) Link to comment Share on other sites More sharing options...
Whoami Posted February 7, 2014 Share Posted February 7, 2014 (edited) Salut, C'est clair : il faut toujours prendre en compte le risque et le risque sur un Prestashop n'est pas énorme : pas de numéro de carte bleu ou autres données sensibles. A l'heure actuelle, je trouve que Prestashop possède une sécurité qui est en rapport avec la cible...Excepté un concurrent un peu riche, un cracker qui s'amuse ou une boutique facilement exploitable, quel blackhat va aller s'emm*** à contourner tout un tas de sécurités même "assez simples", pour aller récupérer une base de client peut-être minime, pour après tout décortiquer sans connaitre le salt de la boutique, pour à l'arrivée aucune donnée bancaire ?Bien sûr le débat de savoir si machin est plus sécurisé que bidule est toujours d'actualité (et même s'il est vrai que des "nouvelles méthodes de cryptage" sont plus sécurisées, ça ne veut pas dire que Salt + MD5 ne l'est pas...), mais le besoin en "grosse sécurité", comparé au temps passé à le produire, est-il vraiment pertinent dans le cadre de 99% des boutiques utilisant Prestashop ?De plus, à l'ère du social engineering à outrance, est-il bien intéressant de parler d'attaques MITM qui ne vont concerner qu'une cible relativement faible ?Enfin le MITM c'est bien et oui ça peut fonctionner... mais on sait tous que le plus gros code d'erreur du monde est le Code 18 (communément appellé "bug de l'interface-chaise-clavier") et personnellement si j'étais dans le milieu, ce serait invariablement la ou j'attaquerai en premier. Quelle sécurité peut contrer le fait que l'utilisateur te donne (in)directement ses identifiants ? Edited February 7, 2014 by Whoami (see edit history) 1 Link to comment Share on other sites More sharing options...
SMorillon.com Posted February 7, 2014 Share Posted February 7, 2014 Je ne connaissais pas le code 18 mais j'adore !!! Quand on sait que le mot de passe le plus utilisé est 123456... il vaudrait mieux apprendre aux utilisateurs à choisir un bon mot de passe avant de chercher les failles dans le système... Link to comment Share on other sites More sharing options...
coson Posted February 7, 2014 Author Share Posted February 7, 2014 Je ne connaissais pas le code 18 mais j'adore !!! Quand on sait que le mot de passe le plus utilisé est 123456... il vaudrait mieux apprendre aux utilisateurs à choisir un bon mot de passe avant de chercher les failles dans le système... Salut, A l'heure actuelle, je trouve que Prestashop possède une sécurité qui est en rapport avec la cible... Excepté un concurrent un peu riche, un cracker qui s'amuse ou une boutique facilement exploitable, quel blackhat va aller s'emm*** à contourner tout un tas de sécurités même "assez simples", pour aller récupérer une base de client peut-être minime, pour après tout décortiquer sans connaitre le salt de la boutique, pour à l'arrivée aucune donnée bancaire ? Bien sûr le débat de savoir si machin est plus sécurisé que bidule est toujours d'actualité (et même s'il est vrai que des "nouvelles méthodes de cryptage" sont plus sécurisées, ça ne veut pas dire que Salt + MD5 ne l'est pas...), mais le besoin en "grosse sécurité", comparé au temps passé à le produire, est-il vraiment pertinent dans le cadre de 99% des boutiques utilisant Prestashop ? De plus, à l'ère du social engineering à outrance, est-il bien intéressant de parler d'attaques MITM qui ne vont concerner qu'une cible relativement faible ? Enfin le MITM c'est bien et oui ça peut fonctionner... mais on sait tous que le plus gros code d'erreur du monde est le Code 18 (communément appellé "bug de l'interface-chaise-clavier") et personnellement si j'étais dans le milieu, ce serait invariablement la ou j'attaquerai en premier. Quelle sécurité peut contrer le fait que l'utilisateur te donne (in)directement ses identifiants ? ça y est, tu m'énerves ! et ensuite ? il faudrait que quelqu'un intercepte le flux de données entre mon ordi et mon FAI ou le serveur de la boutique, qui a les moyens de faire ça ? (la NSA ok, mais qui d'autre), et tout ça juste pour voir tes commandes passées sur archiduchesse ? si mon ordi est vérolé un haschage coté client est totalement inutile et inefficace. Encore une fois vous affirmez sans démontrer! Ou voyez vous que le mot de passe client est stocké ou affiché en clair sur la boutique? A aucun moment vous retrouverez ce mot de passe tel qu'il a été indiqué à l'inscription sur le site et si vous parlez justement de cette envoi du mot de passe c'est à vous de mettre en place un protocole SSL sur votre boutique. Si ce hachage cote client est inutile pour quoi il est utilisé par certains sites très sérieux…… Un mot en hash SHA 1 intercepté sur des réseaux peux sécurises (universités, wifi, entreprises), protège mieux qu’un mot de passe envoyé en claire ! De plus, le SSL, ce n’est pas donné à tous les boutiques … J’souhaite savoir si vous aurez l’amabilité de mettre en place ce type de protection pour les formulaires, l’identification, pour cette communauté des utilisateurs SVP ? Merci à vous. Link to comment Share on other sites More sharing options...
coson Posted February 22, 2014 Author Share Posted February 22, 2014 Si ce hachage cote client est inutile pour quoi il est utilisé par certains sites très sérieux…… Un mot en hash SHA 1 intercepté sur des réseaux peux sécurises (universités, wifi, entreprises), protège mieux qu’un mot de passe envoyé en claire ! De plus, le SSL, ce n’est pas donné à tous les boutiques … J’souhaite savoir si vous aurez l’amabilité de mettre en place ce type de protection pour les formulaires, l’identification, pour cette communauté des utilisateurs SVP ? Merci à vous. Si ce hachage cote client est inutile pour quoi il est utilisé par certains sites très sérieux…… Un mot en hash SHA 1 intercepté sur des réseaux peux sécurises (universités, wifi, entreprises), protège mieux qu’un mot de passe envoyé en claire ! De plus, le SSL, ce n’est pas donné à tous les boutiques … J’souhaite savoir si vous aurez l’amabilité de mettre en place ce type de protection pour les formulaires, l’identification, pour cette communauté des utilisateurs SVP ? Merci à vous. Bonjour, J'attends toujours une réponse de votre part ! Merci pour votre patience. Daniel. Link to comment Share on other sites More sharing options...
SleT Posted February 24, 2014 Share Posted February 24, 2014 Les attaques MITM sont très rares pour les particuliers qui utilisent un réseau privé et c'est aux utilisateurs de faire attention, pas au vendeur. Les transactions qui ont besoins d'être sécurisé le sont, le reste non. Si on part dans cette optique, tous les sites avec une auth devrait être hashé avant... Pourquoi? Parce que 80% des internautes utilisent le même mot de passe partout (sans jeu de mot) et que du coup si vous en trouvez un vous les trouvez tous. il n'y a aucune raison de faire ça à moins d'avoir vraiment du contenu spécifique, et encore... Conclusion, les clients et les gens en général ne devrait simplement pas se connecter sur des reseaux publics pour faire des transactions ou se connecter avec des user / password, et si ils le font, c'est à leur risque et péril. Link to comment Share on other sites More sharing options...
ckarone Posted February 24, 2014 Share Posted February 24, 2014 Oui bien d'accord avec les autres intervenants et j'ajouterai qu'un certificat SSL n'est pas si cher (hors EV barre verte) : ssl pas cher. Ckarone Link to comment Share on other sites More sharing options...
wamania Posted April 20, 2015 Share Posted April 20, 2015 Bonjour, J'interviens, peut-etre un peu en retard, mais je viens de voir ce fil dans mes stats, et je me devais de répondre ! Je suis l'auteur de l'article susmentionné. Déjà pour commencer : Tu n'es pas développeur et apparemment le type qui a fait l'article que tu cites non plus. Je suis bien développeur, et le md5 est bien déprécié, il l'était déjà qd j'ai écris l'article en 2007.... Après, faut relativiser - Le grain de sel empêche l'utilisation de dico, donc md5 ou sha-xxx, ça change pas gd chose. Mais à l'époque, on utilisait généralement que le md5, sans grain de sel, quasiment partout. Déjà que c'était pas rare de voir des bases avec des mots de passe en clair, alors le grain de sel.... et clairement un md5 sans grain de sel, c'est un mot de passe en clair... - L'article date de 2007 ! A cette époque, un certificat valait encore un bras et une jambe, et comme je le rappelle au début, les hubs étaient encore très répandus, rendant une attaque du man in the middle très simple. Pendant mes tests à l'époque, j'ai choppé un paquet de mot de passe d'un paquet de monde dans ma boite... Sur les mutualisés, c'était de toute façon impossible de mettre un certificat, hormis peut-être chez certains hébergeurs contre 2 bras et une jambe. Maintenant c'est très différent. Tout ce que j'ai dit dans cet article a un intérêt "pédagogique" au mieux, je n'utilise plus tout ça. - Un certificat se paie moins de 100€/an, on peut même en trouver vers les 30€ me semble-t-il. - OVH propose pour 50€/an des certificats sur ses mutu. Donc je confirme : - je suis bien développeur - il est inutile de compliquer l'interface avec un hash client pour un manque qui n'en est plus un. PS: ça y est, tu m'énerves ! un modérateur, c'est pas fait pour ... modérer ? Link to comment Share on other sites More sharing options...
coeos.pro Posted April 21, 2015 Share Posted April 21, 2015 md5 = 3,4028236692093846346337460743177e+38 de combinaisons = environ 340.000.000.000.000.000.000.000.000.000.000.000.000 de combinaisons (j'espère que je n'ai pas oublié de 0). md5 sans grain de sel, c'est un mot de passe en clair ok, trouve moi un mot de passe donnant ce md5 : 0802ee90f4ef9e40d8ae8f54fe69d84d et je te donnerai raison, sinon, ben c'est moi qui aurai raison. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now