IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les développeurs auraient du mal à implémenter correctement le chiffrement dans leur application
Parce qu'ils n'ont pas reçu de formation spécifique

Le , par Stéphane le calme

25PARTAGES

5  1 
VeraCode, une entreprise spécialisée dans la sécurité des applications, a publié le sixième volume de son état des lieux de la sécurité des logiciels. Cette sixième édition s’est concentrée sur l’industrie verticale. Pour établir ses statistiques, Veracode s’est appuyé sur des milliers d’applications (208 670) et plus d’un trillion de lignes de code qui ont été analysés par sa plateforme cloud.

La qualité du code s’est avérée être le vecteur de vulnérabilité le plus observé dans les industries. Avec 56 %, l’industrie de construction observe le pourcentage le moins élevé de ce type de vecteur tandis que l’industrie de la santé observe 80 %.

Les problèmes liés au chiffrement ont occupé la seconde place du classement des catégories de vulnérabilité par industrie verticale. Ces problèmes incluent par exemple des informations sensibles stockées en clair, une force de chiffrement inadéquate, une entropie insuffisante, une vérification des signatures numériques inadéquate, etc.


Les développeurs rajoutent beaucoup de bibliothèques de chiffrement à leur code, en particulier dans des secteurs comme la santé ou les services financiers, mais ils le font mal, explique Chris Wysopal, le Directeur technique de VeraCode. De nombreuses organisations ont besoin d’utiliser le chiffrement en raison des règlements de protection des données, mais le rapport suggère que leurs développeurs ne possèdent pas la formation nécessaire pour le mettre en œuvre correctement.

« Ceci va montrer combien il est difficile de mettre en œuvre le chiffrement correctement », a déclaré Wysopal. « Il s’agit en quelque sorte d’un problème endémique auquel beaucoup de gens ne pensent pas », estime-t-il. Beaucoup de développeurs croient qu'ils savent comment mettre en œuvre un chiffrement, mais n’ont pas reçu de formation spécifique en chiffrement et ont un faux sentiment de sécurité, estime-t-il. Par conséquent, même s’ils finissent avec des applications où le chiffrement est présent, les attaquants sont toujours en mesure d'obtenir des données sensibles. Et cela ne concerne même pas les cas où les développeurs décident de créer eux-mêmes leurs propres algorithmes de chiffrement.

« Le choix du langage pour le développement logiciel peut avoir un grand impact sur les applications. Bien que certains langages et modèles de programmation éliminent complètement certains problèmes de sécurité (par exemple, les problèmes de gestion d’un tampon commun à C / C ++ sont complètement éliminés en Java ou en .NET), il arrive que le choix du langage de programmation soit influencé par d’autres facteurs que la sécurité. La disponibilité de développeurs qualifiés, les langages de programmation utilisés par les fournisseurs et d'autres points encore peuvent conduire à des différences significatives de l'industrie dans le choix du langage de programmation », avance le rapport.


Pourtant, Carsten Eiram, le chef de la recherche à Risk Based Security, estime que « de nombreuses personnes soutiennent que, puisque les langages de programmation modernes sont plus faciles à utiliser et réduisent encore plus les possibilités d’erreur des développeurs, plusieurs d'entre eux peuvent se bercer dans un faux sentiment de sécurité et ne pas être assez soignés dans leur développement, c’est-à-dire accroître le risque d'introduire d'autres types de problèmes comme les erreurs de conception et de logique. Ne pas mettre en œuvre correctement un chiffrement rentrerait dans cette catégorie ».

De nombreux développeurs pensent qu'ils peuvent juste mettre un lien vers une bibliothèque de chiffrement pour que le tour soit joué, mais un chiffrement solide peut s’avérer difficile à mettre en œuvre si vous n’en comprenez pas les aspects les plus subtils comme la vérification correcte des certificats, la protection des clés de chiffrement, l’utilisation de taille de clé appropriée ou l’utilisation de générateurs de nombres pseudo-aléatoires solides. « Tout cela revient finalement à une meilleure éducation des programmeurs afin qu’ils comprennent tous les pièges lors de la mise en œuvre d’un chiffrement fort », a estimé Eiram.

Mais la faute n’incombe pas uniquement aux développeurs. Matthew Green, un professeur d’ingénierie de chiffrement à l'Université Johns Hopkins à Baltimore, pense que de nombreuses bibliothèques de chiffrement sont « franchement mauvaises » d'un point de vue ergonomique parce qu'elles ont été conçues par et pour les cryptographes. « Obliger les développeurs à les utiliser c’est comme s’attendre à ce que quelqu’un pilote un avion alors qu’il a un permis de conduire », avance-t-il. Pour lui, faire des logiciels de chiffrement plus faciles à utiliser serait plus efficace que former des développeurs à devenir cryptographes.

Il faut dire que certains auteurs de bibliothèques de chiffrement y travaillent. Par exemple, sur la feuille de route du projet OpenSSL publiée le 30 juin dernier, sur le paragraphe concernant la complexité de la liberté ils reconnaissent que « les bibliothèques et applications OpenSSL sont complexes, à la fois du point de vue de la personne effectuant la maintenance, mais également de celui qui les utilise ». Raison pour laquelle ils ont décidé de « revoir et modifier l’API avec pour objectif la réduction de la complexité » sur une période d’un an.

Pourtant, bien qu’il ne conteste pas le fait que certaines bibliothèques soient trop complexes, Eiram ne pense pas qu’il faille que les développeurs soient des cryptographes pour implémenter correctement des chiffrements. Pour lui, les API de chiffrement dans Java et .NET, les deux langages les plus utilisés dans les industries verticales d’après le rapport de Veracode, ont été conçus pour les développeurs et leur fournissent la plupart de ce dont ils ont besoin en termes de fonctionnalités de chiffrement lorsqu’ils développent leurs applications.

« Bien qu’il soit préférable que les bibliothèques incluant des bibliothèques de chiffrement soient conçues pour être utilisées le plus aisément possible, les développeurs qui choisissent de les utiliser doivent au moins comprendre à un haut niveau comment elles fonctionnent. Je vois ici une voie à double sens : faciliter l’utilisation des bibliothèques de chiffrement, mais également des développeurs qui doivent implémenter un chiffrement dans leurs applications qui se renseignent convenablement au lieu d’attendre que quelqu’un leur tienne la main », a-t-il avancé.

En plus d’une absence d’expertise parmi les développeurs sur un projet ou de la complexité de certaines bibliothèques de chiffrement, Green a avancé qu’oublier de réactiver les fonctionnalités de sécurité après avoir testé un produit est une autre erreur commune. Par exemple, des développeurs peuvent désactiver une validation de certificat TLS dans leur environnement test parce qu’ils ne disposent pas de certificat valide installé sur leur serveur test, mais après oublient de la réactiver une fois que l’application passe en production.

« Il y a deux ans, un article avait paru sur un grand pourcentage d’applications Android qui étaient victimes de telles erreurs », a rappelé Green. Wysopal a indiqué que l’incapacité à valider correctement des certificats TLS a souvent été observée par Veracode durant leurs tests de sécurité.

Source : Veracode, feuille de route OpenSSL

Et vous ?

Avez-vous déjà utilisé une bibliothèque de chiffrement ? Laquelle ?

Que pensez-vous de ces différents avis ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Saverok
Expert éminent https://www.developpez.com
Le 29/06/2015 à 18:53
Citation Envoyé par Thorna Voir le message
Ca veut dire que le code qu'on dépose dans un cloud est visible de l'hébergeur, dans son intégralité, sans protection ?!? Et ils parlent de sécurité ?!?
Veracoe est une plateforme de benchmark de sécurité donc oui, le code est visible par Veracode car justement, il lui est soumis pour analyse.
Ensuite, un code peut être open source, donc visible par tous, et l'application être sécurisée.
4  1 
Avatar de Fleur en plastique
Membre extrêmement actif https://www.developpez.com
Le 29/06/2015 à 15:56
Moi je chiffre avec MD5()

Tout autre truc est trop compliqué pour moi.
3  1 
Avatar de Expert-Securité
Futur Membre du Club https://www.developpez.com
Le 16/07/2015 à 14:52
Citation Envoyé par BufferBob Voir le message
merci l'expert

néanmoins quand on dit que "les développeurs ont du mal à implémenter correctement les bibliothèques de chiffrement" j'imagine qu'on ne fait pas uniquement référence au chiffrement (a)symétrique, une problématique simple pourrait être celle du choix de la fonction de hashage à utiliser pour stocker des empreintes de mots de passe en base de données par exemple, vaut-il mieux choisir du SHA512, du ROT13, du CRC32 ou "laisser en clair, puisqu'après tout le pirate pour lire le mdp dans la base de données il doit forcément venir dans l'entreprise avec sa clé usb et on le laissera pas rentrer, donc ça risque rien"
... ajoutant pas content "moi ça me gonf de devoir cryptager tous les mdp, en plus va falloir le faire sur toute la db elle fait 50G, j'ai des impératifs moi môsieur je suis CDP, je dois aller vite"
et l'équipe sécurité de conclure : "ok on est obligé de couper la poire en deux, vous aurez qu'a tout mettre en base64, mais on veut que vous mettiez un salt..."

Il vaut mieux ne pas sous estimer les attaquants : ils arriveront (très) probablement a atteindre la machine ciblée et au moins à dumper la base de données ou l'annuaire contenant vos mots de passe. Ne serait ce que par des failles de sécurité dont il n'existe pas encore de patch ou qui ne sont même pas encore connues et donc contre lesquelles vous ne pouvez pas vous défendre, même si le plus souvent, l'attaquant entre dans le système par des failles sur des applications qui ne sont pas à jour sur les patchs de sécurité ou par une erreur humaine.
Une base dumpée ne sert à rien si les mots de passe sont "hashés". Enfin, s'ils ont été correctement hashés ! Il faut ajouter un sel ou user d'autres techniques (double hash) autrement, le hash des mots de passe ne suffira pas à empêcher l'attaquant de les retrouver (avec MD5 en tout cas) grâce à des rainbow tables mais ça le frainera au moins.

Enfin, on pourrait en parler des jours de ce qu'il faut faire ! il vaut mieux consulter un expert en sécurité :-).
2  1 
Avatar de Tcharl
Membre averti https://www.developpez.com
Le 14/06/2016 à 16:09
C'est si dur que ça de mettre en place un TLS 1.2 pour aller chercher un jeton OAuth2?
Aussi de configurer encrypter le mdp côté client avec un SSHA 1024 + 3DES, le faire passer via TLS au serveur qui sale le pwd avec l'ID de la ligne en table puis sauvegarde (bien sûr, un UUID, pas un incrément)?
Aussi avoir des bibliothèque d'encryption à jour bien sûr.
Faire du chrooting sur les sockets, activer Selinux, configurer pam, nsswitch, nscd.
Comprendre le mécanisme de CA, CSR, PKI, CRT, de proxy et reverse, voir Radius, Kerberos, le LDAP(s) et ses mécanismes d'ACL.

Non, sérieux ils déconnent ces développeurs, c'est super simple la sécurité...
1  0 
Avatar de hotcryx
Membre extrêmement actif https://www.developpez.com
Le 30/06/2015 à 18:59
Effectivement le chiffrement c'est difficile à implémenter, j'y suis en plein dedans et je creuse
Où mettre l'algorithme, lequel (il y en a tellement), certains ont été "cassés", est-ce que ça va toujours fonctionner, et les admins ils vont voir les pwd, le code qui utilise les clés, et la NSA?...
Plein de questions que vous allez vous posées et peuvent rendre fou lol.
Et quand on pense avoir trouvé une méthode (entre 2 systèmes), un autre élément arrive comme par exemple y accéder par un autre chemin et là on se recasse la tête ^3
Rem: c'est vrai que c'est un chouette domaine et je n'ai pas encore vraiment attaqué le hashing, les maths derrière l'algorithme, aille ya yay aille...

Peace courage les gars
0  0 
Avatar de BufferBob
Expert éminent https://www.developpez.com
Le 01/07/2015 à 10:55
Citation Envoyé par Saverok Voir le message
un code peut être open source, donc visible par tous, et l'application être sécurisée.
paraitrait même que les codes sources de SHA512, AES256, Diffie-Hellman etc. et même carrément OpenSSL, GPG ou -feu- Truecrypt sont tous disponibles sur le net et consultables par n'importe qui

et ça parle de sécurité !!!
0  0 
Avatar de flaroche
Nouveau Candidat au Club https://www.developpez.com
Le 03/07/2015 à 10:40
J'espère que c'était du 2nd degré...
Si on ne peut pas contrôler le niveau de chiffrement d'une méthode quel est l'intérêt ?
Pour mémoire, les seuls systèmes réellement acceptables en terme de sécurité sont RSA (taille cle > 1024) et le chiffrement par courbe elliptique pour lesquels existent des preuves de non-vulnérabilité.
0  0 
Avatar de Natura-Time
Nouveau Candidat au Club https://www.developpez.com
Le 05/07/2015 à 12:08
"La qualité du code s’est avéré être le vecteur de vulnérabilité le plus observé dans les industries. Avec 56%, l’industrie de construction observe le pourcentage le moins élevé de ce type de vecteur tandis que l’industrie de la santé observe 80%."

Je crois que le tableau a été mal analysé, les 80% dans l'industrie de la santé proviennent de "Cryptographic Issues", la qualité du code n'y est vulnérable que à 60% (les couleurs correspondent aux vulnérabilités à gauche et leur position en Y est leur rang, comme sur la droite). Le pourcentage le plus élevé est 70% dans le secteur des technologies.
0  0 
Avatar de Expert-Securité
Futur Membre du Club https://www.developpez.com
Le 16/07/2015 à 11:19
Juste quelques précisions tout de même :
- MD5 et SHA sont des algos de Hashage, ils ne permettent pas de chiffrer
- AES est un algo de chiffrement symétrique effectivement
- OpenSSL est une bibliothèque & boîte à outils

Il est parfaitement normal et même voulu que tous les algorithmes de chiffrement ou Hashage soient OpenSource, le but étant qu'un maximum de personnes puisse les lire et trouver des vulnérabilités afin de les corriger. Je suppose que c'est la même chose pour OpenSSL autrement la dernière faille de sécurité n'aurait pas été trouvée aussi vite. La force de la protection des algorithmes de chiffrement réside dans la clé (le secret) et non pas dans la méconnaissance de l'algorithme : principe de Kerckhoffs oblige...

Je confirme que les développeurs sachant utiliser le chiffrement efficacement ne sont pas nombreux, vraiment pas nombreux. En général, la tentative de mise en place de chiffrement donne une protection illusoire contre un attaquant confirmé : ce dernier arrivera le plus souvent à récupérer la clé de chiffrement, et dans 99% des cas, je dirais que c'est assez facile... autrement, il est facile de récupérer les données directement déchiffrées...

Donc le chiffrement est inutile si votre environnement d'exécution n'est pas sur-protégé pour le rendre le plus inaccessible possible (ce qui demande d'autres compétences de la part des attaquants).
0  0 
Avatar de Expert-Securité
Futur Membre du Club https://www.developpez.com
Le 16/07/2015 à 11:23
Juste quelques précisions tout de même :
- MD5 et SHA sont des algos de Hashage, ils ne permettent pas de chiffrer
- AES est un algo de chiffrement symétrique effectivement
- OpenSSL est une bibliothèque & boîte à outils

Il est parfaitement normal et même voulu que tous les algorithmes de chiffrement ou Hashage soient OpenSource, le but étant qu'un maximum de personnes puisse les lire et trouver des vulnérabilités afin de les corriger. Je suppose que c'est la même chose pour OpenSSL autrement la dernière faille de sécurité n'aurait pas été trouvée aussi vite. La force de la protection des algorithmes de chiffrement réside dans la clé (le secret) et non pas dans la méconnaissance de l'algorithme : principe de Kerckhoffs oblige...

Je confirme que les développeurs sachant utiliser le chiffrement efficacement ne sont pas nombreux, vraiment pas nombreux. En général, la tentative de mise en place de chiffrement donne une protection illusoire contre un attaquant confirmé : ce dernier arrivera le plus souvent à récupérer la clé de chiffrement, et dans 99% des cas, je dirais que c'est assez facile... autrement, il est facile de récupérer les données directement déchiffrées...

Donc le chiffrement est inutile si votre environnement d'exécution n'est pas sur-protégé pour le rendre le plus inaccessible possible (ce qui demande d'autres compétences de la part des attaquants).
0  0