Discussion :

[Bill Fassinou]

Certains développeurs freelances et étudiants en IT ne sécurisent pas les mots de passe au stockage à moins d’y être invités
selon une étude

Des chercheurs de l’institut d'informatique de l’université de Bonn, en Allemagne, ont réalisé une étude sur la nécessité qu’accordent les étudiants en informatique et les développeurs indépendants à la sauvegarde sécurisée de mots de passe dans une base de données. Dans le rapport de fin d’étude fourni par l’équipe, il est dit que sans incitation explicite, un grand nombre des étudiants faisant partie de l’étude n’ont mis en place aucun stockage sécurisé des mots de passe. Le constat est presque pareil dans le rang des développeurs freelances qu’ils ont par la suite testé suivant les mêmes exercices. Pour réaliser l’étude, les chercheurs ont demandé à 40 étudiants en informatique de mettre en œuvre le processus d'inscription à un réseau social universitaire.

La moitié des participants ont utilisé Java (JSF) et l'autre moitié, le framework Spring. Spring offre une bibliothèque de support qui implémente le stockage des mots de passe avec un haut niveau de sécurité. Avec JSF, les participants ont dû mettre en œuvre eux-mêmes le salage et le hachage. Ensuite, pour vérifier si les participants se rendraient compte de la nécessité d'un stockage sécurisé des mots de passe sans y être invités, les auteurs ont donné à la moitié des participants une description des tâches qui ne mentionnait pas la sécurité, tandis que les étudiants de l'autre moitié ont été explicitement chargés de mettre en œuvre un programme de sécurité pour la solution.

L’équipe de recherche a pu tirer plusieurs conclusions de cela. Dans un premier temps, ils ont remarqué qu’aucun des participants non amorcés (c’est-à-dire ceux qui n'ont pas été explicitement chargés de créer une solution, sécurisée) n'a conservé les mots de passe de façon sécuritaire. Deux d'entre eux ont tenté de créer une solution sécurisée, mais ont abandonné et remis une solution non sécurisée. Sur les 20 participants qui ont été explicitement chargés de créer une solution sécurisée, 12 ont mis en œuvre un certain niveau de sécurité. Puis, dans un second temps, ils ont constaté qu’en comparant les différents frameworks (JSF vs. Spring), un plus grand nombre de participants qui ont mis en œuvre une certaine sécurité ont obtenu un score élevé pour la sécurité grâce à la mise en œuvre par défaut de Spring.

Dans les conditions de Spring, tous les participants sauf un ont obtenu la note la plus élevée de 6 points sur un total possible de 7. Dans les conditions du JSF, l'écart était beaucoup plus grand avec des valeurs allant de 2 à 6. Et enfin, une troisième conclusion renseigne que tous les participants qui ont réalisé une solution sécurisée ont utilisé le "copier-coller" pour le faire, c'est-à-dire qu'aucun des participants n'a réalisé de solution sécurisée en écrivant son propre code.

L’autre partie de l’étude a porté sur 43 développeurs freelances qu’ils ont engagés sur Freelancer.com en se faisant passer pour une petite entreprise et qu’ils ont payés par la suite. Cette fois encore, une majorité parmi ces développeurs n’a pas pensé à une manière sécuritaire de sauvegarder les mots de passe sans y être explicitement invités. « Les développeurs indépendants sont conscients que leurs clients utiliseront leur solution dans le monde réel. Cependant, la qualité des solutions était comparable à celle des solutions des étudiants », lit-on dans le rapport en ce qui concerne développeurs freelances.

Toutefois, il y a quelques précisions de la part des chercheurs au sujet des résultats ci-dessus. Lorsqu’ils ont posé la question aux étudiants de comprendre pourquoi ils n’ont pas mis l’accent sur un stockage sécurisé des mots de passe, ils ont déclaré qu’ils le feraient s’il s’agissait d’une réelle entreprise. C'est d'ailleurs cette déclaration qui a poussé les chercheurs à étendre l'étude aux développeurs freelances. Cela dit, ce qui sème un peu la confusion c'est pourquoi une grande partie des développeurs freelances qui croient travailler pour une réelle entreprise et en plus d’être payés n’ont pas pris à cœur une sauvegarde sécurisée des mots de passe ?

À un moment où le piratage de données prend de plus en plus de l'ampleur, n’est-ce pas une nécessité première chez les développeurs de penser à plus de sécurité lorsqu’il s’agit de sauvegarder des données à caractère personnel ? Pour obtenir plus d’informations sur la méthodologie utilisée et les différentes conclusions retenues par l’équipe de recherche, vous pouvez consulter le rapport dans son entièreté. L’étude a montré que les étudiants et les développeurs freelances qui y ont participé à l'étude ont presque la même manière de procéder, c’est-à-dire qu’ils ne trouvent pas nécessaire de mettre en place une sécurité autour du stockage des mots de passe à moins d’y être invités. Est-ce parce qu’ils ne sont pas informés sur la qualité que cela apporte à un logiciel ou qu’ils ignorent les risques encourus par un système où les données ne disposent pas d’une sécurité qualifiable ?

Source : Rapport de l'étude

Et vous ?

Selon vous, pourquoi les étudiants et les développeurs indépendants n'ont pas jugé utile de sécuriser le stockage de mot de passe ?
En plus du salage et le hachage, de quelle autre manière pourrait-on sécuriser le stockage de mot de passe, selon vous ?

Voir aussi

Les pires mots de passe 2018 : « 123456 » trône en tête du classement pour la cinquième année consécutive et est suivi par « password » comme en 2017

La plupart des gestionnaires de mots de passe populaires présentent des vulnérabilités pouvant entraîner le vol de mots de passe, Selon un rapport

Les mots de passe Windows NTLM à 8 caractères peuvent être piratés en moins de 2,5 heures, selon des chercheurs

A l'avenir, vos réactions cérébrales pourraient devenir des mots de passe, car elles sont uniques et vous n'aurez rien à retenir

[Pyramidev]

J'ajoute une précision importante sur l'échantillon des développeurs freelance de l'étude : il s'agit de 43 développeurs, dont 14 Indiens, 8 Chinois, 4 Pakistanais, 3 États-uniens, 3 Égyptiens, 2 Srilankais, 2 Vietnamiens, 2 Italiens ou Mexicains (l'article a mis les deux pays dans la même catégorie), 1 Bangladais, 1 Nigérien, 1 Mongol et 2 de nationalité inconnue.

Un passage amusant de l'article :

We also had one problem during the execution of our study. The project code sent to the first 17 freelancers already contained two security imports (java.security and javax.crypto). This could have inadvertently primed participants in the non-prompted conditions that security was important. Luckily for us,¹ none of these participants implemented a secure solution.

¹But unluckily for security in general.

À part ça, parmi ceux qui chiffraient les mots de passe, beaucoup ont utilisé MD5, cette magnifique fonction de hachage pour laquelle on peut faire des collisions à la demande depuis le siècle dernier.

Many freelancers also used outdated methods, but stillclaimed to have implemented a sufficient or even optimal secure solution (e.g., N5₁₀₀, N11₁₀₀, P2₂₀₀, N8₁₀₀, N10₁₀₀, P3₂₀₀). For instance, N11₁₀₀ declared, "Passwords are stored after encryption, usually MD5. This makes it secure and almost impossible to compromise."

after receiving the instruction to store user passwords securely, N3₂₀₀ said "Sure, it's a piece of cake" and added MD5 without salt or iterations in 10 minutes

P4₂₀₀ used MD5 to store user passwords securely and argued "I've used this technique many times to store passwords and have not faced any security issues."

While P8₁₀₀ and P9₂₀₀ indeed used industry standards for security and thus received 6 of 7 points, almost all of the other participants used MD5 as a "standard" for password storage

[Leruas]

Pour les freelances c'est des projets entre 100 et 200$, ils s'attendaient à quoi ? Surtout en JSF qui n'a pas de solution native de gestion des mots de passes
Étude biaisée

[Invité]

Pour les freelances c'est des projets entre 100 et 200$, ils s'attendaient à quoi ? Surtout en JSF qui n'a pas de solution native de gestion des mots de passes
Étude biaisée

Ne pas avoir de gestion native des mots de passe ne signifie pas que l'étude est biaisée, je dirais que au contraire si le but de l'étude est de se rendre compte si les développeurs vont penser au chiffrement des mots de passe ce serait biaisé si le framework avait une option toute prête pour ca.

Pour le prix c'est difficile à dire. Je suis d'accord que c'est normal d'avoir de la merde si on paye pour de la merde, il faut cependant voir comment l'offre à été posée.

[sebastiano]

J'ai un bon souvenir de mon premier jour de travail (c'était au début des anneés 2000). Un ingénieur (fraîchement diplômé), sûr de lui, finalise un formulaire d'inscription tout beau tout neuf. Il nous le montre. Ca a l'air pas mal. Il lance la mise en production. En moins d'une heure, le site a été piraté :
- Pas de contrôle des variables ;
- Pas de protection des requêtes ;
- Mot de passe stocké en clair.

[Anselme45]

J'ajoute une précision importante sur l'échantillon des développeurs freelance de l'étude : il s'agit de 43 développeurs, dont 14 Indiens, 8 Chinois, 4 Pakistanais, 3 États-uniens, 3 Égyptiens, 2 Srilankais, 2 Vietnamiens, 2 Italiens ou Mexicains (l'article a mis les deux pays dans la même catégorie), 1 Bangladais, 1 Nigérien, 1 Mongol et 2 de nationalité inconnue.

1. Réussir à tirer des conclusions d'une étude à partir de 40 "besogneux", c'est juste prendre les gens pour des crétins! 40 personnes ne reflètent en rien l'état d'une profession!

2. L'origine des "freelances" éclaire ma lanterne. Je me suis toujours demandé comme des sites à la "freelance.com" pouvez trouver des "freelances" d'accord de faire des développements qui durent des semaines pour le tarif d'une heure de travail facturé par la plus petite société d'informatique du coin. Ben, j'ai la réponse. C'est vrai que lorsque la salaire moyen mensuel tourne autour des 2 dollars, en obtenir 200 c'est l'eldorado!

Après il ne faut pas s'étonner de la mauvaise image de l'informatique en général auprès des clients finaux. Quand on fait appel à un sympathique développeur srilankais travaillant pour un coût qui ne paye même pas la facture de l'électricité engendré par son PC basse consommation pour faire le projet, nul doute que la qualité du code, le support et la maintenance du code sont assurés...

[sixpi]

Ça me fait penser aux trop nombreux mails :

Bonjour,
votre inscription c'est déroulée avec succès :
votre pseudo : 6pi
votre mot de passe : BOH*Nx.J&!2zX)iq   // oui j'utilise un générateur de mot de passe

Ou encore

vous avez demandé la récupération de votre mot de passe, le voici : BOH*Nx.J&!2zX)iq

[Tartare2240]

Ça me fait penser aux trop nombreux mails :

Bonjour,
votre inscription c'est déroulée avec succès :
votre pseudo : 6pi
votre mot de passe : BOH*Nx.J&!2zX)iq   // oui j'utilise un générateur de mot de passe

Personnellement, je considère pas forcément le premier envoi de mot de passe par mail comme une faille de sécurité. Enfin, si le mail est sécurisé hein ! Mais dans l'optique où le mail en clair n'est pas stocké dans la base pour le besoin de cet envoi (fait en live à l'inscription) je vois pas vraiment en quoi ça poserait un problème.

[BufferBob]

Personnellement, je considère pas forcément le premier envoi de mot de passe par mail comme une faille de sécurité. Enfin, si le mail est sécurisé hein ! Mais dans l'optique où le mail en clair n'est pas stocké dans la base pour le besoin de cet envoi (fait en live à l'inscription) je vois pas vraiment en quoi ça poserait un problème.

le mail est un des premiers endroits où ira voir n'importe quel pirate ou malware automatisé, pour récupérer les contacts et mots de passe qui trainent dans les mails envoyés/reçus, donc recevoir son mot de passe pour un site web en clair par mail c'est une inconséquence qui peut aggraver les choses/faciliter le boulot du pirate en cas de compromission

la deuxième chose c'est lorsqu'on perd son mot de passe et que le site web te le renvoie : ça veut simplement dire que les mots de passe ne sont pas hashés dans la base, juste chiffrés de manière réversible (dans le meilleur des cas !), et si c'est réversible pour le site web, ça l'est aussi pour le pirate et d'autant plus facilement, c'est un problème.