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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    5 897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 5 897
    Points : 147 225
    Points
    147 225
    Par défaut Les développeurs auraient du mal à implémenter correctement des bibliothèques de chiffrement
    Les développeurs auraient du mal à implémenter correctement des bibliothèques de chiffrement,
    parce qu'ils n'ont pas reçu de formation spécifique

    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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti
    Profil pro
    Vélotypiste
    Inscrit en
    novembre 2010
    Messages
    196
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Vélotypiste

    Informations forums :
    Inscription : novembre 2010
    Messages : 196
    Points : 391
    Points
    391
    Par défaut
    Moi je chiffre avec MD5()

    Tout autre truc est trop compliqué pour moi.

  3. #3
    MikeRowSoft
    Invité(e)
    Par défaut
    Cela dépend très souvent de la nature des informations stockées ou transmises. En avoir besoin ou ne pas en avoir besoin grosso modo.
    Je me demande se qu'il penserait d'un TinyCore exploitant la mémoire cache d'un CPU/GPU et exploitable depuis divers I/O d'IHM, n'ayant pas de mémoire vive ou graphique externe à proprement parlé, mais une mémoire de masse externe de type SSD ou EEPROM?
    Dernière modification par MikeRowSoft ; 29/06/2015 à 17h24.

  4. #4
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Fleur en plastique Voir le message
    Moi je chiffre avec MD5()

    Tout autre truc est trop compliqué pour moi.
    Cool, c'est le reverse MD5 engine qui est sympa, reconstruction du fichier à partir du code MD5.

  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    579
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 579
    Points : 1 067
    Points
    1 067
    Par défaut
    Je ne commente pas le contenu, juste un truc au début:
    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.
    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é ?!?
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  6. #6
    Membre émérite

    Homme Profil pro
    Ranger
    Inscrit en
    avril 2006
    Messages
    659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 80
    Localisation : France

    Informations professionnelles :
    Activité : Ranger
    Secteur : Service public

    Informations forums :
    Inscription : avril 2006
    Messages : 659
    Points : 2 996
    Points
    2 996
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Thorna Voir le message
    Je ne commente pas le contenu, juste un truc au début:
    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é ?!?
    J'ai pensé exactement la même chose. L'hébergeur fouille dans le code source du système informatique de l'entreprise et ose donner des leçons de sécurité ? Et après on s'étonne de la paranoïa (justifiée) envers le Cloud ?

  7. #7
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 132
    Points : 7 774
    Points
    7 774
    Par défaut
    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.

  8. #8
    Membre émérite

    Homme Profil pro
    Ranger
    Inscrit en
    avril 2006
    Messages
    659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 80
    Localisation : France

    Informations professionnelles :
    Activité : Ranger
    Secteur : Service public

    Informations forums :
    Inscription : avril 2006
    Messages : 659
    Points : 2 996
    Points
    2 996
    Billets dans le blog
    1
    Par défaut
    Du coup on peut comprendre mieux, l'article peut induire en erreur avec le terme "Cloud", mais à la décharge du journaliste, ce terme est utilisé à tort et à travers par 90% des personnes, c'est un terme marketing inventé pour désigner essentiellement des choses qui existaient déjà et regrouper des concepts qui n'ont finalement peu à voir ensemble si ce n'est que d'avoir une dimension "déportée chez un prestataire".

  9. #9
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Saverok Voir le message
    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.
    Ils sont pas trop loin de fournir un service de compilateur/linker. Cependant déterminer les comportements suspects demande un modèle de modélisation comme UML façon rational ROSE. Chose qui n'a jamais été clairement cité dans cette article.

  10. #10
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 969
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 969
    Points : 3 255
    Points
    3 255
    Par défaut
    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
    Si la réponse vous a aidé, pensez à cliquer sur +1

  11. #11
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    novembre 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 963
    Points : 8 209
    Points
    8 209
    Par défaut
    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é !!!

  12. #12
    Nouveau Candidat au Club
    Homme Profil pro
    Enseignant
    Inscrit en
    juin 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2012
    Messages : 1
    Points : 1
    Points
    1
    Par défaut C'est une blague ?
    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é.

  13. #13
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    avril 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : avril 2014
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    "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.

  14. #14
    Futur Membre du Club
    Homme Profil pro
    Expert sécurité informatique
    Inscrit en
    juillet 2015
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Expert sécurité informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juillet 2015
    Messages : 3
    Points : 5
    Points
    5
    Par défaut quelques précisions
    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).

  15. #15
    Futur Membre du Club
    Homme Profil pro
    Expert sécurité informatique
    Inscrit en
    juillet 2015
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Expert sécurité informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juillet 2015
    Messages : 3
    Points : 5
    Points
    5
    Par défaut Quelques précisions
    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).

  16. #16
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    novembre 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 963
    Points : 8 209
    Points
    8 209
    Par défaut
    Citation Envoyé par Expert-Securité Voir le message
    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
    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..."

  17. #17
    Futur Membre du Club
    Homme Profil pro
    Expert sécurité informatique
    Inscrit en
    juillet 2015
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Expert sécurité informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juillet 2015
    Messages : 3
    Points : 5
    Points
    5
    Par défaut
    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é :-).

  18. #18
    Membre averti
    Homme Profil pro
    Expert MDE
    Inscrit en
    janvier 2008
    Messages
    181
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Expert MDE
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : janvier 2008
    Messages : 181
    Points : 331
    Points
    331
    Par défaut
    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é...

Discussions similaires

  1. Pourquoi les développeurs entrent-ils dans une guerre des tranchées ?
    Par Stéphane le calme dans le forum Débats sur le développement - Le Best Of
    Réponses: 104
    Dernier message: 23/07/2015, 14h54
  2. Réponses: 25
    Dernier message: 25/08/2014, 01h57
  3. Réponses: 0
    Dernier message: 21/03/2009, 11h59
  4. Réponses: 2
    Dernier message: 23/07/2006, 16h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo