Les clients officiels de Ryzom migrent de la version 2.1 à la version 3.0

Posté par . Édité par Yvan Munoz, Nils Ratusznik, Benoît Sibaud, palm123 et Davy Defaud. Modéré par ZeroHeure. Licence CC by-sa
30
10
oct.
2016
Jeu

Ryzom est un MMORPG de science-fantasy basé sur un monde vivant unique : une planète-plante aux paysages envoûtants, sauvage, et peuplée de mille dangers. Vous pouvez y incarner une des quatre races humanoïdes du jeu, contribuer à la reconquête de leur civilisation perdue et influer sur l'évolution du monde.

Les clients officiels de Ryzom sont en cours de migration de la version 2.1 à la version 3.0. Cette version sera également disponible depuis le site officiel de Ryzom et depuis la Logithèque Ubuntu et l'AppStore d'Apple.

La liste des améliorations de la v3 est disponible dans la suite de la dépêche.

Image tirée du site officiel

Principales améliorations effectuées sur les clients v3

Améliorations visuelles

  • Améliorations du rendu (anticrénelage FXAA, filtrage anisotrope, flou lumineux – bloom – amélioré) ;
  • correction et régénération de toutes les textures ;
  • prise en charge de la technologie Optimus pour les cartes graphiques NVIDIA ;
  • correction des textures manquantes pour certaines bottes lorsqu'elles étaient portées avec une robe de mage.

Améliorations techniques

  • Utilisation d'OpenGL comme pilote 3D par défaut pour toutes les plateformes et cartes graphiques ;
  • mise à jour de toutes les bibliothèques externes ;
  • support du 64-bits et des dernières versions de toutes les plateformes ;
  • amélioration de la prise en charge des compilateurs (GCC 5, MinGW, Visual C++ 2012, 2013 et 2015) ;
  • amélioration de la prise en charge du HTML dans le jeu (nouvelles balises, suppression de la dépendance à libwww, correctifs, etc.) ;
  • nouvelle version multiplateforme du programme de configuration ;
  • prise en charge du format GIF ;
  • prise en charge des noms de fichiers Unicode sous Windows ;
  • correction de l'erreur 62 lors de la connexion au serveur ; un grand merci à Vojtěch Vobr, un développeur d'AVG Technologies, pour nous avoir aidés à trouver et corriger une anomalie détectée par AVG et qui empêchait certains joueurs de se connecter au jeu ;
  • amélioration du délai de connexion au serveur, qui passe de 10 secondes à 1 seconde ;
  • correction du plantage avec les cartes graphiques NVIDIA Quadro ;
  • mise en œuvre d'un nouvel outil d'installation.

Amélioration de la sécurité

  • Hachage des mots de passe en SHA-512 au lieu de DES ;
  • mise à jour du certificat SSL.

Confort et améliorations diverses

  • Amélioration du texte en jeu ;
  • générateur aléatoire de nom pour la création de personnage ;
  • nombreuses optimisations, améliorations et corrections de bogues ;
  • correction de nombreuses alertes ;
  • utilisation de tous les cœurs par défaut ;
  • détection de la quantité de mémoire disponible sur la carte graphique et utilisation de la qualité adéquate ;
  • synchronisation verticale supportée sous toutes les plateformes ;
  • utilisation de XAudio2 comme pilote audio par défaut sous Windows ;
  • importante restructuration de l'interface afin de créer un éditeur WYSIWYG ;
  • prise en charge de nouveaux styles pour les polices de caractères ;
  • nouveaux liens pour l'assistance et les forums ;
  • nouvelle icône « Ryzom » ;
  • utilisation des bottes retexturées pour les mages ;
  • ajout de la date dans le nom de fichier des captures d'écran ;
  • prise en charge des accents dans les émoticônes et affichage correct de celles-ci ;
  • nouvelle commande /playedTime (affichage du temps joué avec le personnage) ;
  • nouvelle commande /version (affichage de la version exacte du client) ;
  • correction de quelques traductions ;
  • correction de la synchronisation verticale (VSync, dite VBL Sync dans les options du jeu) sous Windows ;
  • amélioration du support des balises HTML et  ;
  • affichage d'informations supplémentaires concernant les configurations matérielle et logicielle dans le fichier journal (log) ;
  • amélioration du lecteur MP3 qui fonctionnera désormais sur toutes les plate-formes (vous devrez créer un répertoire « music » et y ranger vos fichiers musicaux) ;
  • prise en charge de polices à chasse fixe ;
  • amélioraton généralisée de l'alignement du texte ;
  • amélioration de la prise en charge des balises HTML et des attributs dans le WebIg ;
  • implémentation de la mise à l'échelle des polices ;
  • ajout d'une barre de défilement à la liste des commandes ;
  • correction de la position du curseur après sortie de la vue libre ;
  • correction de bogues mineurs et amélioration de la qualité du code.

Image tirée du site officiel

Détails du processus

Étape 1 (le 7 octobre 2016) :

  • mise à jour du client Windows officiel ;
  • mise à disposition en téléchargement sur ryzom.com de la version Windows de l'installateur Ryzom ;
  • mise à jour des clients Steam ;
  • mise à jour des clients Windows bêta en clients officiels.

Étape 2 (en ce moment) :

  • mise à disposition en téléchargement sur ryzom.com de la version Linux de l'installateur Ryzom ;
  • mise à jour des clients Linux bêta en clients officiels.

ryzom installeur

Étape 3 :

  • mise à disposition en téléchargement sur http://ryzom.com de la version OS X de l'installateur Ryzom ;
  • mise à jour du client OS X bêta en client officiel.

Étape 4 :

  • mise à disposition de l'installateur Ryzom dans la Logithèque Ubuntu ;
  • mise à jour du client Ryzom OS X et de ses données sur l'AppStore.
  • # .

    Posté par (page perso) . Évalué à 1.

    Amélioration de la sécurité

    Hachage des mots de passe en SHA-512 au lieu de DES ;

    C'est dommage de se dire en 2016 « allez on va faire en sorte de gérer proprement les mots de passe », et, malgré la littérature et la progression dans le bon sens populaire du fait qu'aucun hachage basique n'est un bon système de stockage de mot de passe, se dire que cet objectif sera accompli avec du SHA.

    • [^] # Re: .

      Posté par . Évalué à 1.

      Je n'ai pas compris si tu critiquais les mots de passes trops faibles ou bien les mécanismes de hashage mais l'idéal c'est de rendre les mots de passes transparents comme le fait sudo. Tu peux envisager de ne pas avoir de mot de passe pour ta session et de le générer automatiquement tout en automatisant l'ouverture des sessions.

      Tout cela c'est à toi de le prévoir et les systèmes modernes te donnent toute la lattitude pour le faire.

      Dans tout les cas tu es obligé d'avoir une zone de confience vis à vis des autres. Cette zone de confience c'est une partie de la faillibilité de ton système mais ce n'est pas dommage d'avoir une faiblesse c'est propre à toutes les machines. Ce qui est dommage c'est de juger qu'une chose faible n'ai pas raison d'être alors qu'elle remplit très bien le rôle qu'on attent d'elle.

      Je n'ai installé aucun service sur ma machine qui ai pour vocation d'être contacté de l'extérieur donc je suis protégé et je peu me passer d'un système de hash complexe : j'utilise md5 et dans un mois je copierai ma sauvegarde sur un support amovible.

      • [^] # Re: .

        Posté par (page perso) . Évalué à 8.

        Il parle de mots de passe stocké sur le serveur, et trouve bizarre de faire une transition de md5 vers sha plutôt qu'une transition de md5 vers quelque chose de mieux.

        (et du coup, je ne comprends pas l'inutilisation de mon message)

        • [^] # Re: .

          Posté par . Évalué à -10.

          Désolé j'étais plongé dans la lecture pationnante de toutes ces nouveautés j'en étais à

          synchronisation verticale supportée sous toutes les plateformes ;

          et j'ai presque terminé, tout ce que l'on entend sur le jeu ou que l'on voit comme artwork donne envit de rejoindre l'aventure…

        • [^] # Re: .

          Posté par (page perso) . Évalué à 1.

          Merci, au moins un qui comprend. Se dire "tiens on va migrer vers SHA au lieu de MD5, ça c'est du secure" je comprends pas comment on peut en être là.

        • [^] # Re: .

          Posté par . Évalué à -10.

          Terminé

      • [^] # Re: .

        Posté par . Évalué à 10.

        En fait, il dit que, de nos jours, les fonctions de hachages cryptographiques dédiées au hachage des mot de passe ne sont plus les mêmes que celles utilisées pour, entre autre, l'intégrité des données (comme SHA), notamment parce que les secondes ont pour but d'être le plus rapide possible tandis que les premières peuvent (et même doivent) être suffisamment lente pour gêner une recherche exhaustive. Et donc, une recherche sérieuse de 5 minutes sur Wikipédia aurait donné une liste de fonctions adéquates (genre bcrypt ou Scrypt), prenant en compte nativement un sel suffisamment long (qui empêche les attaques de type table arc-en-ciel) et des paramètres comme un nombre d'itération qui vont allonger le temps de calcul de la fonction (qui empêche donc des attaques par force brute, y compris sur des petits dictionnaires). Voilà (j'ai eu la flemme de wikipediser ce paragraphe mais ça aurait été cool) !

    • [^] # Re: .

      Posté par (page perso) . Évalué à 0.

      https://bitbucket.org/ryzom/ryzomcore/issues/206/change-the-hash-method-used-to-store

      A simple and good enough solution is to use crypt(3) with a 16 characters salt[…]. Such a salt would force the use of SHA-512 instead of DES. It's way more secure

      Au moins on se marre bien. Remarque le the [current] DES-based scheme [which] limits the password's length up to 8 characters soit-disant acceptable en 2004 mettait déjà pas mal en jambe.

      • [^] # Re: .

        Posté par (page perso) . Évalué à 10.

        Déjà 6 six commentaires pour dire à quel point c'est un mauvais choix. Et pas un capable d'expliquer et/ou de proposer une solution ou d'être constructif ou donner des références. Pauvre communauté.

        La solidité actuelle de SHA 256, ainsi que des autres pour comparer et choisir :

        https://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions
        https://en.wikipedia.org/wiki/Hash_function_security_summary
        https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_validation

        • [^] # Re: .

          Posté par (page perso) . Évalué à 10.

          Il faut avouer qu'il y a un certain manque de connaissance côté sécu sur Ryzom et compagnie (donc aussi Ryzom Core et Khaganat, et je représente en partie ce dernier). C'est pas à notre honneur. C'est un fait. Il nous faudrait mieux que des "yakafokon" : des contributeurs qui maîtrisent cet aspect. Là, par rapport à l'ampleur du code et le nombre de domaines à couvrir, même avec la meilleure volonté du monde, c'est difficile de "juste se former". Enfin, au rythme où je le fait, par exemple, je serais en mesure d'aider côté sécurité dans 10 ou 15 ans ! Donc : venez, venez !

          Les divers projets basés sur Ryzom souffrent aussi de ce qui en fait la beauté : le côté libre façon cathédrale du bazar. Les commits côté Ryzom Core sont acceptés plus ou moins vite suivant la disponibilité des quelques gestionnaires ; ils ne sont parfois pas assez testés en amont et cela entraîne des bugs en cascade ensuite. Sur Ryzom, le jeu, ces modifications mettent donc parfois beaucoup de temps à être implémenté, comme ce fut le cas pour cette absurde limite des mots de passes à 8 caractères (oui oui… moi-même j'ai mal chaque fois que j'y pense), parce que c'est aussi un jeu commercial et que les dirigeants ne peuvent pas vraiment se permettre de trop casser le client alors que les gens paient. Même si du coup, y'a parfois des failles de sécurités grandes comme la famine en Afrique ; mais tant que personne ne va voir, personne ne sais que ça existe, hein ?

          Je ne dit pas que c'est un bon choix (s'il y en a un…), mais je peux comprendre qu'avec leurs moyens limités ils aient souvent préférés ne pas toucher ce qui marchait à peu près.

          Sur Khaganat, pour le moment le mieux qu'on puisse proposer, c'est d'écrire en gros sur le client que la sécurité est basique, qu'il ne faut pas utiliser un mot de passe qui sert sur d'autres comptes et services. Je n'aime pas ne pas être sûre du service que je propose, même s'il n'y a rien de grave à perdre. En même temps, chaque fois qu'un sysadmin ou un dev passe en roulant des mécaniques sur son niveau en sécurité, soit il se sauve au bout de quelques semaines en voyant que c'est un peu plus compliqué que le code d'un mini-jeu android, soit il trouve plus intéressant de se mettre à Blender (ou l'un des centaines d'autres domaines utiles dans un mmorpg). Sans parler de ceux qui causent mais ne documentent pas, ne donnent aucun lien vers des tutos bien foutus, bref ne transmettent pas leurs compétences et ne font pas plus le travail. Ou, et ça arrive aussi, proposent des solutions "hype" mais qui s'avèrent être, après une petite journée d'investigation, trop immatures ou trop dépassées.

          Les critiques sont donc fondées, vous avez le droit de rigoler (moi, je ris un peu jaune…), du moment qu'on garde à l'esprit que ça ne changera pas tant qu'il n'y aura pas des vraies contributions sur le sujet. Allez, au boulot bande de moules !

          • [^] # Re: .

            Posté par (page perso) . Évalué à 9.

            Il faut avouer qu'il y a un certain manque de connaissance côté sécu sur Ryzom et compagnie (donc aussi Ryzom Core et Khaganat, et je représente en partie ce dernier). C'est pas à notre honneur.

            Le reconnaitre est à votre honneur.

          • [^] # Re: .

            Posté par (page perso) . Évalué à 7. Dernière modification le 11/10/16 à 13:26.

            J'admets que j'aurais pu m'y prendre autrement sur la forme (voire soyons fou sur le fond également et contribuer ! on peut rêver).

            Ceci dit quand je disais que je ne comprends pas, c'était pas un troll, je ne comprend vraiment pas. Il suffit de chercher "how to store passwords" sur un moteur de recherche pour trouver depuis des années littérallement des kilomètres linéaires de documentation ultra complète (pour qui veut les détails) ainsi que de la vulgarisation TLDR: use bcrypt en gras clignotant.

            Donc, autant avoir un code existant mauvais, je peux comprendre, mais une fois qu'on s'est dit bon ça va pas faut faire un truc propre, je comprends pas comment on peut en arriver à conclure SHA, surtout qu'on ne parle pas d'un peu mieux mais beaucoup plus compliqué et risqué à mettre en place ; on parle schématiquement de sha(oldPassword, newPassword) vs. bcrypt(oldPassword, newPassword).

            Pour l'anecdote, vers 2011 j'ai eu à modifier l'algo de stockage des mots de passe d'une application utilisée par des services publics (parce que l'existant était du SHA1 et que l'ANSSI exigeait pour 2012 d'utiliser au moins du SHA2). Niveau contraintes je pense que ça vaut bien un jeu. Je me suis dit que quitte à toucher à ça, y aurait pas mieux ? J'ai cherché 1h et j'ai découvert cette problématique, découvert bcrypt, et trouvé tout ce qu'il me fallait pour vendre à mon chef de passer directement à bcrypt.

            Ça me parait une attitude saine, qu'on peut attendre d'un dev, et j'ai pas la sensation d'être un génie d'avoir pensé et réussi ça.

            • [^] # Re: .

              Posté par (page perso) . Évalué à 2.

              J'admets que j'aurais pu m'y prendre autrement sur la forme

              Ça va, la forme était très correcte :)

              Si ma propre réponse était un peu énervée, c'est que ces histoires de sécurité et de mot de passe sur Ryzom me gonflent. C'est ça qui m'éneeeerve ! Pour autant je ne me sens vraiment pas capable, à mon niveau, d'agir ; juste de constater. Par exemple de constater qu'un mot de passe qui ne pouvait pas dépasser 8 caractères alphanumériques, c'était un fichu non-sens. Et que ce bug, corrigé, se retrouvait dans une des branches du projet qu'on avait eu le malheur de suivre. Je ne sais pas qui a géré ça, je ne veux pas savoir parce que j'aime bien la plupart des dev actifs de Ryzom Core, qui se débrouillent souvent avec deux bouts de ficelles et peu de soutien sur des trucs "qu'il faut faire c'est urgent" quand bien même ce n'est pas du tout leur domaine. Alors à côté de ça, le SHA…

              J'vais prendre mes cachets, ça me reviens. J'entre en mode berserk en pensant à ce bazar et à ma propre impuissance.

              Bref, à propos de comprendre, je crois qu'il n'y a rien à comprendre :/

              Juste à constater. Et à espérer qu'un de ces jours, vienne un messie quelqu'un qui mettra les mains dans le cambouis en sachant ce qu'il fait. D'ailleurs, n'hésite pas à passer, promis je ne mords pas vraiment !

          • [^] # Re: .

            Posté par . Évalué à 3.

            Du coup, j'ai voulu faire un tour pour voir à quoi ça pouvait ressembler le code de Ryzom et notamment ce bout de code pour les mots de passe. J'ai été incapable de trouver le dépôt, s'il existe. J'ai fouillé pendant 10 minutes sur tous les sites Ryzom sans trouver quoi que ce soit. Y a-t-il un dépôt public ou c'est moi qui suis trop mauvais ?

            • [^] # Re: .

              Posté par (page perso) . Évalué à 2.

              Je ne suis pas certain mais il semblerait que le dépôt utilisé serait celui-ci :
              https://bitbucket.org/ryzom/

              A confirmer

              La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas sentis la différence.

              • [^] # Re: .

                Posté par (page perso) . Évalué à 2.

                Je confirme, c'est le dépôt officiel de Ryzom Core ; on trouve aussi des miroirs sur github mais pas toujours bien à jour.

          • [^] # Re: .

            Posté par . Évalué à 2.

            Si on trouve un problème de sécurité potentiel dans le code, à qui écrire pour en discuter ? (Ouvrir un rapport de bug accessible publiquement ?)

            • [^] # Re: .

              Posté par (page perso) . Évalué à 1.

              Tu peux ouvrir un rapport de bug ici : https://bitbucket.org/ryzom/ryzomcore/issues?status=new&status=open

              Tu peux aussi tenter d'en discuter sur IRC, canal #ryzom (anglophone à la base mais ils sont moins regardant sur le sujet depuis que des francophones les envahissent et bossent :-° ) par contre les réponses et l'activité dépend beaucoup de l'heure et des gens présents.

              Tu es aussi le bienvenu sur le canal #khanat ou #krypte (canaux IRC de Khaganat, #krypte nous servant plus pour les sujets techniques), on cause français mais par contre notre niveau technique est assez bas. Notre compétence c'est surtout de documenter peu à peu, en apprenant au fur et à mesure :D Après, si on trouve un souci et comment le résoudre, on push vers Ryzom Core.

              • [^] # Re: .

                Posté par . Évalué à 1.

                Merci. J'ai ouvert un rapport de bug. Normalement il vaut mieux ne pas faire directement un rapport public quand il y a peut-être une faille exploitable, mais le projet ne propose pas de façon de rapporter les soucis de sécurité.

                Par ailleurs, si je peux me permettre un commentaire oblique, dans la précédente news sur Ryzom nous avons été nombreux et nombreuses à signaler un problème non-technique, à savoir le fait que la toute première image du site web ryzom.com est sexiste. Il y a eu une longue polémique sur LinuxFR, mais je remarque que le problème est toujours présent. J'ai écrit à support@ryzom.com à ce sujet, sans aucune réponse. Ce n'est pas un problème difficile à comprendre ou technique. Est-il possible de contacter quelqu'un qui est prêt à améliorer la situation ?

                • [^] # Re: .

                  Posté par (page perso) . Évalué à 3.

                  Là, je dirais qu'il n'y a rien à faire. Cette image sexiste a été repéré avant la sortie officielle, les équipes en interne ont alertés sur le fait que non, ça n'allait pas le faire. Résultat, à la sortie, elle était là. Ensuite tout le monde a pointé ça du doigt. Elle est toujours là. Pour moi, c'est juste qu'il y a un gros lourd de macho à un poste de décision et qu'il tiens à voir sa paire de fesses en pleine écran, même si c'est le seul qui veut ça. Mais comme il est à une position de chef, hein, qu'est-ce qu'il s'en moque de ce que pense les autres ?

                  Oui, je dénonce grave, pas jusqu'à balancer des noms quand même parce que je vais déjà me faire taper sur les doigts pour un commentaire de ce genre, mais bon : même si j'aime les paires de fesses aussi, je ne pense pas que ce soit le bon endroit pour en poser, et j'ai de mon côté échoué à faire bouger le problème, alors même que je connais les rouages de la machine. Je sais que Ryzom est plus lourd qu'un mammouth quand il s'agit de bouger, mais pour ce truc là, il y a pour moi une vraie volonté de bloquer de la part d'un sexiste. Voilà voilà.

                  Ou alors faut faire une pétition…

                  • [^] # Re: .

                    Posté par . Évalué à 2.

                    Merci pour ces informations qui permettent de mieux comprendre ce qui se passe. C'est difficile quand on contribue à quelque chose par passion et qu'on a en face des gens qui font de l'immobilisme. Bon courage !

                    • [^] # Re: .

                      Posté par (page perso) . Évalué à 1.

                      Ouais quand le monde comprendra que les femmes (ou les hommes après tout, ça marcherait dans les deux sens) n'ont pas de fesses, on se portera mieux. Bon jusqu'à la recrudescence des cancers du colon.

        • [^] # Re: .

          Posté par . Évalué à 3.

          Le problème est que stocker les mots de passe n'est pas le même besoin que hasher un document, et qu'une fonction sûre pour la deuxième tâche ne l'est pas forcément pour la première. Stocker un mot de passe chiffré, ça veut dire partir d'une information secrète précieuse mais souvent devinable (le mot de passe) pour aller vers une clé de vérification d'identité, de façon à ne pas pouvoir facilement retrouver l'information précieuse à partir de la clé. Pour ce besoin, on n'utilise pas une "cryptographic hash function" mais une Key Derivation Function, par exemple bcrypt, scrypt ou PBKDF2.

          • [^] # Re: .

            Posté par . Évalué à -10.

            malloc() hash() crypt() est une chaine de traitements possible, je n'avais pas différencié cette approche et pourtant cela semble tomber sous le sens. ..

            bcrypt et hash ne font pas partis de la norme ANSI telle qu'elle est décrite ici (ligne 6446) bien que le but était d'exploiter la machine et ses périphériques. On avait donc probablement pas la possibilité de faire du hardening sur de la data en général.

            Néanmoins ici ces fonctions sont toutes considérée valides en tant que "Key derivation functions supported by crypt" car elles répondent à un paradigme fonctionnel basé sur " entrée - traitement - sortie " bien qu'elles interviennent effectivement dans des domaines totalement différents et que leur fonctionnement en est relatif.

    • [^] # Re: .

      Posté par . Évalué à 4.

      C'est dommage de se dire en 2016 « allez on va faire en sorte de gérer proprement les mots de passe », et, malgré la littérature et la progression dans le bon sens populaire du fait qu'aucun hachage basique n'est un bon système de stockage de mot de passe, se dire que cet objectif sera accompli avec du SHA.

      En fait quand on lit le code on voit qu'ils utilisent une fonction sha512crypt qui fait un certain nombre d'itération et est donc une définition crédible d'une fonction de dérivation de clé (Key Derivation Function). Le nombre d'itérations utilisé semble être celui par défaut (5 000), qui est trop faible aujourd'hui (on peut lire sur internet une proposition d'une valeur de 86 000 par exemple), et cette méthode est moins sécurisée qu'un scrypt qui est pensé pour être résistant contre des matériels spécifiques, mais là on entre dans le pinaillage. L'information utile est qu'en fait il ne font pas "juste" un hachage avec SHA512 et que lire le code en question aurait permis d'éviter tout ce fil de discussion agressive.

      • [^] # Re: .

        Posté par (page perso) . Évalué à 2. Dernière modification le 19/10/16 à 00:08.

        Putain je clique sur le code censé me rassurer et je vois quoi pour rejeter une entrée trop grande ?

        /* reject large keys */
        for (i = 0; i <= KEY_MAX && key[i]; i++);
        if (i > KEY_MAX)
        return 0;

        Ah bah je suis rassuré, des optims de manipulation de chaine dégueu (avec un objectif par ailleurs fumeux dans le contexte d'un mot de passe) pour gagner quelques cycles dans un algo censé rendre intrinsèquement impossible l'optimisation du brute force : super.

        • [^] # Re: .

          Posté par . Évalué à 6. Dernière modification le 19/10/16 à 22:13.

          C'est du code du domaine public qu'ils ont repris sans regarder les détails (de toute façon éditer toi-même du code cryptographique fourni par "des gens qui s'y connaissent" serait aussi folie). En l'occurence le code se retrouve aussi dans la libc musl qui est bien considérée dans l'embarqué par exemple.

          Je ne dis pas que le code est joli, je dis que c'est du code standard que des gens de cette communauté vont écrire. Peut-être que tu réagis négativement et vulgairement car tes goûts esthétiques te font préférer d'autres langages que le C, ou un style plus haut niveau que celui des gens qui écrivent de la crypto pour leur job. Peut-être aussi que tu as cru que c'étaient les développeurs de Ryzom qui ont écrit ce code, et qu'on peut se foutre de leur gueule car ce ne sont pas "des gens qui s'y connaissent". Dans tous les cas je trouve ça moyen.

          Par ailleurs le code, un peu plus haut, explique dans un commentaire pourquoi il y a ce fragment:

          key limit is not part of the original design, added for DoS protection.

          Quand on y réfléchit, ce n'est pas forcément idiot (même si ce n'est peut-être pas non plus la meilleure façon de faire). Si je charge un mot de passe de 3Mo sur le serveur, et qu'il fait 5,000 itérations de sha512 dessus, ça fait quand même 15Go que je viens de le convaincre de chiffrer en sha512, je peux lui occuper un de ces processeurs à plein temps pendant quelques secondes.

          Mettre une limite fixée permet d'obtenir une borne supérieure sur le temps passé dans ce code, ce qui est sans doute rassurant pour le serveur. On peut pinailler sur la limite de 256 (on pourrait vouloir un mot de passe plus long que ça, c'est là ton reproche ?), mais le fait d'avoir une limite semble raisonnable.

  • # Pas mal

    Posté par . Évalué à 4.

    Vais pas critiquer la décision d'utiliser du SHA et de se focaliser sur un seul point de détail par rapport à toutes les évolutions qui sont présentées dans cette news.
    Perso je trouve ça bien qu'un projet comme celui-ci arrive à maintenir une communauté et à proposer des màj dont le travail semble conséquent, donc chapeau.

    • [^] # Re: Pas mal

      Posté par . Évalué à -10.

      A quel moment tu vois une critique de sha ? On parle du durcissement de la gestion des mots de passe, ce qui n'est pas forcément dramatique en soit. Et biensur c'est aussi un problème de société.

    • [^] # Re: Pas mal

      Posté par . Évalué à -10.

      A quel moment tu vois une critique de sha ? On parle du durcissement de la gestion des mots de passe, ce qui n'est pas forcément dramatique en soit. Et biensur c'est aussi un problème de société.

  • # Sexisme

    Posté par . Évalué à 1.

    Je trouve ça dommage de s'être senti obligé de mettre en avant les fesses d'une femme sur la page d'accueil de Ryzom pour faire venir le chaland : http://ryzom.com/

    • [^] # Re: Sexisme

      Posté par . Évalué à 2.

      C'est une bonne remarque, on en a déjà discuté dans un journal précédent et dans les commentaires ci-dessus, avec en particulier cette réponse éclairante.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.