Mots de passe cryptés de la base d'utilisateurs de mots de passe non cryptés

Question

Il y a quelque temps, j'ai rejoint un nouveau projet. Il était en développement depuis assez longtemps. Ce qui m’a surpris, c’est que les mots de passe de tous les utilisateurs sont stockés sous une forme non chiffrée .

J'ai expliqué à notre direction d'énormes vulnérabilités en matière de sécurité - il semble qu'elles soient d'accord avec cela et souhaitent rendre le projet plus sécurisé. Les membres de l’équipe sont également d’accord.

Nous avons environ 20 000 utilisateurs dans le système.

En réalité, il est très stressant de réussir cela: migrez les mots de passe non cryptés vers la forme cryptée . Si quelque chose ne va pas, cela peut mener au désastre du projet.

Comment puis-je réduire ce stress? Sauvegarde? Tests unitaires (tests d'intégration)?

Answer 1

Bien, soyez prudent avec votre sauvegarde car elle contiendra des mots de passe utilisateur non chiffrés: -)

En supposant que les mots de passe soient stockés dans une base de données, une solution simple consisterait à quelque chose comme ceci:

1) Effectuez une sauvegarde sécurisée de l'intégralité des données de la table

2) Créez une nouvelle colonne (PasswordEncrypted ou nom similaire)

3) Utilisez une requête UPDATE pour mettre à jour la nouvelle colonne de chaque ligne avec un MD5 du mot de passe non chiffré, tout en utilisant un salt de 32 octets ou plus. Aujourd'hui, presque tous les systèmes de base de données ont une fonction MD5, vous n’aurez même pas à quitter votre invite SQL

4) Conservez la colonne de texte en clair dans l'intervalle et mettez à jour votre application / vos scripts en conséquence pour qu'ils fonctionnent avec le mot de passe salé.

5) Renommez la colonne ancien mot de passe en texte brut pour la mettre temporairement hors service et tester votre application. En cas de problème, revenez à l'étape 4 et corrigez vos erreurs.

6) Lorsque tout fonctionne correctement, supprimez la colonne du mot de passe en texte clair

7) Encouragez les utilisateurs à choisir un nouveau mot de passe maintenant que vous disposez d'un niveau de sécurité suffisant pour atténuer les effets d'éventuelles attaques précédentes qui auraient pu aboutir.

Answer 2

De quel type de projet s'agit-il? Une application Web, une application de bureau?

Si vous optez pour la refactorisation, y a-t-il une raison pour laquelle les mots de passe doivent être stockés dans quelque chose de réversible comme le cryptage? En général, il est recommandé de hacher vos mots de passe avec quelque chose comme SHA, puis de hacher les entrées avec le même algorithme et de comparer les résultats. Vous ne stockez que les valeurs hachées, pas les mots de passe réels. Cela vous donne la possibilité de vérifier que quelqu'un a saisi le bon mot de passe sans exposer vos utilisateurs à la possibilité que votre cryptage soit brisé et que leurs mots de passe soient exposés.

Je ne peux pas vous fournir d'informations spécifiques sur votre approche (car je ne sais pas comment cela fonctionne), mais le mieux est de créer une colonne supplémentaire pour stocker les mots de passe hachés, de hacher les mots de passe existants, puis de les conserver. les mettre à jour avec tous les changements de mot de passe. Utilisez cette nouvelle colonne pour tous les nouveaux développements, puis une fois le déplacement terminé et testé, supprimez la colonne contenant les mots de passe en clair.

Answer 3

Rédigez de nombreux tests, notamment des majuscules et des minuscules, des nombres, des symboles, des caractères Unicode, des mots de passe longs, etc. Lorsque vous développez et testez, créez un système pour revenir à l'ancien système (en fournissant l'ancienne liste de mots de passe, bien sûr, une fois que les mots de passe sont hachés, vous ne pourrez plus les reconvertir). Enregistrez une copie de la liste de mots de passe actuelle. Convertissez les mots de passe dans un fichier de test ou dans une base de données de test, puis utilisez les mots de passe copiés enregistrés pour vérifier que tout fonctionne. Mettez maintenant le système en production et assurez-vous qu'il fonctionne pour vos utilisateurs. Si ce n'est pas le cas, vous avez déjà testé le plan de migration vers l'ancien système. Une fois que cela a été démontré que cela fonctionne pendant quelques semaines, vous pouvez supprimer la liste de mots de passe en clair et tout est prêt.

Answer 4

Je voudrais simplement hacher les mots de passe actuels, les stocker dans un nouveau champ de base de données et commencer à utiliser ce champ lors de la suppression du champ de mot de passe. Je signalerais alors à mes utilisateurs que le moment est venu de changer les mots de passe, car vous avez mis en place davantage de mécanismes de sécurité pour protéger leurs données.

Pour créer une sauvegarde, il suffit de faire SELECT * INTO Backup FROM UserData

Answer 5

Vous pouvez obtenir une confiance accrue en exécutant les deux méthodes d'authentification (chiffrée et non chiffrée) pour chaque tentative de connexion. Si elles donnent un résultat différent, recevez un e-mail d'alerte vous étant envoyé. Ce changement n'est pas visible pour vos utilisateurs. Il peut donc durer des semaines, voire des mois. Lorsque vous constatez que l'ancienne et la nouvelle authentification fonctionnent pour un pourcentage suffisamment élevé d'utilisateurs, désactivez l'ancienne.

Answer 6

Si possible, essayez ceci: envoyez un courrier électronique à tous vos utilisateurs pour mettre à jour leurs mots de passe avec un délai d’expiration, après quoi ils ne pourront plus travailler s’ils ne les changent pas. Hachez ces nouveaux mots de passe et stockez le hachage. Cela nécessiterait quelques modifications sur le client (c'est-à-dire les données qu'il renvoie).