Que faire lorsque votre entreprise ne crypte pas les mots de passe

Contexte

J'ai été engagé pour aider une entreprise à maintenir son serveur. Je travaille sur quelques projets PHP mineurs, mais je regarde également les problèmes de performances et récemment, j'analyse les journaux pour les pirates.

Ces gars utilisent leur serveur depuis un certain temps et ont ce que j'appellerais une application héritée sur ses dernières jambes. Il utilise des guillemets magiques, des variables globales (ce qui permet $idd'être écrasé par $_GET['id']), utilise .htaccess comme seule sécurité dans certains cas, vous le nommez. Un cauchemar de sécurité et de programmation.

Nous avons été piratés dans le passé, principalement avec des injections SQL, qui exécuteraient des SLEEP(99999999)commandes et agiraient comme une attaque DOS. Heureusement, ils ne tenaient pas de "petites tables de bobby",

XKCD: http://xkcd.com/327/

J'ai donc réécrit leurs instructions SQL vulnérables de mysql_query()(pas mysqli) aux transactions PDO. J'analyse également les requêtes pour SLEEPet UNIONque nous n'utilisons pas, mais les injections ont. Jusqu'ici tout va bien.

Dernier numéro

Récemment, on nous a dit que les enregistrements changent dans la base de données pour les utilisateurs, tels que leurs adresses e-mail en celles vraisemblablement créées par des spammeurs.

J'ai remarqué que leurs colonnes n'avaient pas de last_modifiedcolonne, donc nous ne pouvions même pas savoir quand elles étaient changées, encore moins par qui. J'ai ajouté cette colonne, mais c'est à peine une première étape.

Lorsque je regardais dans ce tableau, j'ai remarqué que les mots de passe n'étaient pas salés ni même hachés, juste enregistrés en texte clair.

Communication client

Comment puis-je les approcher de toute la situation, en tant qu'entrepreneur, sans me battre les bras comme un fou? Aucun conseil? Je pensais à une approche calme de

    NUMÉRO 1
        Synopsis
        Pourquoi c'est un problème
        Que peut-il arriver si ce n'est pas résolu
        Correction suggérée

    NUMÉRO 2
        Synopsis
        Pourquoi c'est un problème
        Que peut-il arriver si ce n'est pas résolu
        Correction suggérée
        

L'approche calme que vous proposez serait la meilleure. Soulignant que lorsque ces données seront exposées, la plupart de vos utilisateurs seront vulnérables au vol d'identité en raison de la réutilisation des mots de passe. Ce serait un bon moment pour souligner que c'est le même problème qui a affecté Target (en supposant que la société n'est pas Target). Et votre manager devrait être assez réceptif à ce changement.

En ce qui concerne la légalité des données, je ne pense pas que les noms d'utilisateur / mots de passe soient considérés comme les mêmes que les données CC, les informations personnelles, etc. Bien que cela puisse dépendre des informations que vous avez pour vos utilisateurs. Je ne suis pas avocat et ces aspects seraient mieux évoqués dans votre révélation et devraient être portés au service juridique de votre entreprise pour déterminer les aspects juridiques.

https://en.wikipedia.org/wiki/Information_privacy_law

Et vous avez ce XKCD pour vous aider aussi:

Cela dépend vraiment du public auquel vous essayez de vous attaquer. J'ai travaillé dans des entreprises avec de graves problèmes de sécurité comme vous le dites, mais ils ont refusé de l'entendre jusqu'à ce que je leur montre.

Une approche, si possible, consiste à rassembler essentiellement ce que vous avez l'intention de faire comme vous le ferez pour détailler ce qui s'est déjà passé dans ces hacks. Si votre public n'est pas technique, vous devrez probablement indiquer le coût commercial que ces compromis peuvent avoir. De toute évidence, les comptes piratés réduisent la crédibilité de votre système et la valeur client perçue de votre produit. Sans parler d'un système compromis avec des mots de passe en texte brut et des adresses e-mail pour les utilisateurs peut provoquer un effet d'entraînement grave.

La prochaine chose que vous devriez faire, si possible, est de le prouver. Si vous pouvez supporter ce système dans un environnement de test, faites-le. Démontrez ensuite devant eux le type d'impact que vous pouvez avoir sur le système du côté client de l'application. Même avec les techniciens, cela s'est avéré assez convaincant pour moi (bien qu'ils n'agissaient toujours pas dans mes cas).

Bien sûr, comme vous l'avez dit, vous devez expliquer, le cas échéant, quelles mesures devraient être prises et une estimation des efforts pour y parvenir. Cela les aidera à justifier le coût, bien que certains endroits ne s'en soucient tout simplement pas. Au moins, vous pouvez effacer votre conscience et avancer en sachant que vous avez essayé.

Si, comme vous le dites, vous avez été engagé pour entretenir leur serveur, ce contrat doit sûrement inclure dans la description de travail des tâches telles que garantir l'intégrité, la sécurité et la disponibilité du système d'exploitation, des logiciels d'application et de toutes les données, etc.?! S'il y a même un vague indice que le contrat attend (et vous tient responsable) pour vous assurer que le serveur est sécurisé, alors je ne perdrais pas de temps à préparer des analyses de rentabilisation et je fais juste un bon travail pour m'assurer que les problèmes sont corrigés (en prenant une sauvegarde avant et après, en conservant un historique des versions de vos modifications de code).

Je ne m'attendrais pas à ce qu'un changement comme celui-ci prenne plus d'une journée de travail et s'ils demandent ce sur quoi vous avez passé votre temps, vous pouvez tenir un journal pour expliquer et justifier vos actions. À condition que vous travailliez dans le cadre de votre contrat, il ne devrait y avoir aucun problème ici. Parfois, la folie de la sécurité devant les décideurs provoque la panique ou, dans le pire des cas, leur donne l'occasion de dire qu'ils ne se soucient pas de ces problèmes, alors ne le résolvez pas, pendant que votre contrat vous tient toujours responsable en cas de une brèche! Peut-être que ce n'est pas toujours l'approche la plus conviviale pour les entreprises, mais mon éthique professionnelle ne me permettrait pas de laisser des mots de passe non cryptés dans n'importe quel système dont j'ai été responsable pour l'avoir porté à mon attention.

D'après mon expérience personnelle, j'ai tendance à trouver chaque fois que je commence à travailler pour un nouvel employeur ou client, discuter des scénarios et des attentes à l'avance peut économiser beaucoup de stress de votre part, par exemple: si je trouve des problèmes de sécurité que je peux résoudre, êtes-vous heureux moi d'aller de l'avant et de terminer ce travail sans venir à chaque fois, ne vous informant que des violations / incidents suspectés? Ils diront presque toujours oui parce que de leur point de vue, ils ne sont pas intéressés à se soucier de la sécurité ou des trucs informatiques - c'est pourquoi ils vous ont embauché! Peut-être que cela ne répond pas à la question comme vous vous y attendiez, mais j'espère que cela donne matière à réflexion. Je vous souhaite tout le meilleur et j'espère que le problème sera corrigé!

Certes, si le changement d'adresse e-mail du client est déjà en cours, et que cela est considéré comme un problème - la possibilité de changer les mots de passe est également un problème.

Maintenant, si vous avez suffisamment sécurisé la base de données pour éviter que cela ne se reproduise à l'avenir, la possibilité que n'importe qui puisse modifier le mot de passe de l'utilisateur est également corrigée et vous n'avez qu'à vous demander si quelqu'un peut lire le mot de passe maintenant.

Bien sûr, s'ils le peuvent, ou si (dans le cas peu probable ) que vous n'avez pas totalement sécurisé la base de données, alors le cryptage des mots de passe doit être fait - comment le faire? Il suffit de le mettre dans le même contexte que le problème de "mise à jour des adresses e-mail". La question de savoir si cela nécessite le changement de l'application et s'il s'agit d'un problème "trop ​​difficile" est une autre question qui doit être soulevée avec eux. Examinez le code et voyez combien coûtera sa modification avant de lui apporter le correctif suggéré.