stockage de mot de passe dans le contrôle de la source

Question

Nous conservons toutes nos applications et les mots de passe db dans le texte brut dans le contrôle source. Nous faisons notre processus build / déploiement génère des fichiers de configuration nécessaires et fait aussi réelles qui nécessitent Déploie ces mots de passe (par exemple: en cours d'exécution sql contre une base de données exige que vous connectez à la db en utilisant des informations d'identification valides). Quelqu'un at-il eu un besoin similaire où vous étiez en mesure de mettre en œuvre ce type de fonctionnalité tout en ne stockant pas les mots de passe en texte clair?

Answer 1

Si votre plan est de stocker toutes les informations de code et configuration pour exécuter un système de production directement du contrôle de version, et sans intervention humaine, vous êtes foutus. Pourquoi? Ceci est tout simplement une violation de l'ancien axiome de sécurité « ne jamais écrire votre mot de passe vers le bas ». Faisons preuve par la négation.

Couper d'abord, vous avez des mots de passe en texte clair dans les fichiers de configuration. Ce n'est pas bon, ils peuvent être lus par tous ceux qui peuvent voir les fichiers.

Deuxième coupe, nous chiffrons les mots de passe! Mais maintenant, le code a besoin de savoir comment déchiffrer les mots de passe, vous devez donc mettre la clé de déchiffrement quelque part dans le code. Le problème vient d'être poussé vers le bas niveau.

Comment l'utilisation de clés publiques / privées? Même problème que les mots de passe, la clé doit être dans le code.

L'utilisation d'un fichier de configuration local ne sont pas stockées dans le contrôle de version met toujours le mot de passe, et les moyens de les lire si elles sont cryptées, sur le disque et d'un attaquant. Vous pouvez durcir les choses un peu en veillant à ce que les autorisations de fichiers de configuration sont très limitées, mais si la boîte Déracine vous êtes foutus.

Ce qui nous amène à pourquoi mettre des mots de passe sur le disque est une mauvaise idée. Il viole le concept d'un pare-feu de sécurité. Une machine compromis contenant les informations de connexion signifie que d'autres machines seront compromises. Une machine mal entretenue peut détruire toute votre organisation.

un être humain va avoir à un moment donné d'injecter le secret critique pour commencer la chaîne de confiance en cours. Ce que vous pouvez faire est de chiffrer tous les secrets du code, puis lorsque le système démarre avoir un homme entrer manuellement la clé pour déchiffrer tous les mots de passe. C'est comme le système de mot de passe principal Firefox utilise. Il est ouvert aux abus car une fois que l'un mot de passe est compromise, de nombreux systèmes peuvent être compromis, mais il est pratique et probablement plus sûr puisque les utilisateurs ont seulement de se rappeler un mot de passe et sont moins susceptibles de l'écrire.

La touche finale est de veiller à ce que devrait les informations de connexion être compromise (et vous devriez toujours supposer que ce sera) que A) l'attaquant ne peut pas faire beaucoup avec elle et B), vous pouvez rapidement arrêter les comptes compromis . Les anciens moyens de ne donner que les comptes d'accès autant qu'ils ont besoin. Par exemple, si votre programme ne jamais besoin de lire à partir d'une base de données avoir connecter sur un compte limité à SELECT. En général, supprimer tous les accès, puis ajoutez seulement si nécessaire. Lésiner sur les droits de supprimer de peur que vous obtenez une visite de petits tableaux Bobby .

Ce dernier signifie que vous donner à chaque utilisateur / organisation / projet leur propre connexion, même si elles peuvent avoir les droits et privilèges mêmes exacts et accéder aux mêmes données. Il est un peu plus compliqué, mais cela signifie que si un système est compromis, vous pouvez rapidement fermer ce compte sans fermer votre entreprise tout.

Answer 2

Je suppose que l'objectif est que vous ne voulez pas les mots de passe privés de votre entreprise soient disponibles, crypté, décrypté, ou autrement, à toute personne qui devrait par ailleurs être autorisé à accéder au reste de la source.

Voici comment je le fais. J'ai dupliqué ce modèle de TikiWiki, qui fait aussi.

dans certains fichier qui contient normalement les mots de passe, les mettre à des valeurs fictives, peu importe quoi. Réglez-le à tout ce que votre client devrait voir. Mettez un commentaire à proximité pour les développeurs de laisser seul ce fichier et de modifier un second fichier.

Dans le second fichier qui est créé si ce n'est pas là, mettre les mots de passe réels. les dispositions nécessaires pour que ce dernier soit inclus, importé, quelle que soit, par le premier fichier.

Prendre des dispositions pour votre contrôle de code source d'ignorer ce fichier. Pourrait ressembler à ceci:

# in .gitignore
localsettings.py

# in settings.py
## Alter this value to log into the snack machine:
## developers: DON'T alter this, instead alter 'localsettings.py'
SECRET_VALUE = ""
try:
  from localsettings import *
except:
  pass

# in localsettings.py
SECRET_VALUE = "vi>emacs"

Answer 3

J'ai des systèmes intégrés où les paires base de données ID utilisateur / mot de passe ne font pas partie de la baisse de code. La clé est de mettre en place un mécanisme de configuration spécifique au site. Ensuite, vous pouvez mettre ces informations sur la boîte en question, sans qu'il soit une partie de la base de code.

Il y a un bonus: vous pouvez non seulement avoir des mots de passe pour les différentes gouttes de code, mais aussi pour les développeurs différents. : -)

Answer 4

Vous n'avez pas mentionné la langue, voici donc une solution vb.net nous utilisons:

Imports System.Web.Security
Imports System.Security.Cryptography
Imports System.Text
Imports Microsoft.Win32

Public Class myCrypt

Private myKey As String = "somekeyhere"
Private cryptDES3 As New TripleDESCryptoServiceProvider()
Private cryptMD5Hash As New MD5CryptoServiceProvider()


Private Function Decrypt(ByVal myString As String) As String
    cryptDES3.Key = cryptMD5Hash.ComputeHash(ASCIIEncoding.ASCII.GetBytes(myKey))
    cryptDES3.Mode = CipherMode.ECB
    Dim desdencrypt As ICryptoTransform = cryptDES3.CreateDecryptor()
    Dim buff() As Byte = Convert.FromBase64String(myString)
    Decrypt = ASCIIEncoding.ASCII.GetString(desdencrypt.TransformFinalBlock(buff, 0, buff.Length))
End Function

Private Function Encrypt(ByVal myString As String) As String
    cryptDES3.Key = cryptMD5Hash.ComputeHash(ASCIIEncoding.ASCII.GetBytes(myKey))
    cryptDES3.Mode = CipherMode.ECB
    Dim desdencrypt As ICryptoTransform = cryptDES3.CreateEncryptor()
    Dim MyASCIIEncoding = New ASCIIEncoding()
    Dim buff() As Byte = ASCIIEncoding.ASCII.GetBytes(myString)
    Encrypt = Convert.ToBase64String(desdencrypt.TransformFinalBlock(buff, 0, buff.Length))
End Function

End Class

Answer 5

mots de passe de magasin sous forme cryptée. Écrire une routine personnalisée qui décrypte les mots de passe et met à jour les fichiers de configuration au moment de la construction. Ceci peut être facilement intégré à l'outil de construction comme Ant.

Answer 6

Si vous le faites en C vous pouvez stocker dans comme un tableau de caractères et de mettre les caractères comme références décimales. Je ne sais pas si cela va briser les chaînes ou non, mais pourrait aider à atténuer une partie de ce problème.

char pass[]={72, 101, 108, 108, 111};