Хранилище паролей в исходном управлении

17

Мы сохраняем все наши пароли приложений и db в текстовом виде в исходном элементе управления. Мы делаем это, так как наш процесс сборки / развертывания генерирует необходимые файлы конфигурации, а также фактические развертывания, требующие этих паролей (то есть: запуск sql для базы данных требует входа в db с использованием действительных учетных данных). У кого-то была такая же потребность, когда вы могли реализовать этот тип функциональности, не сохраняя пароли в виде обычного текста?

    
задан Marcus Leon 18.02.2009 в 03:21
источник
  • Поместите пароли в переменные пользовательской среды o / s. –  Neil McGuigan 03.11.2013 в 01:06

6 ответов

21

Если ваш план состоит в том, чтобы хранить всю информацию о коде и конфигурации для запуска производственной системы непосредственно из управления версиями и без вмешательства человека, вы ввернуты. Зачем? Это всего лишь нарушение старой аксиомы безопасности «никогда не записывайте свой пароль». Давайте сделаем доказательство путем отрицания.

Сначала вырезаете, у вас есть текстовые пароли в файлах конфигурации. Это нехорошо, их можно прочитать всем, кто может видеть файлы.

Второй разрез, мы зашифруем пароли! Но теперь код должен знать, как расшифровать пароли, поэтому вам нужно поместить ключ дешифрования где-нибудь в коде. Проблема только что была нажата на уровень.

Как использовать общедоступные / закрытые ключи? Такая же проблема, как и пароли, ключ должен быть в коде.

Использование локального файла конфигурации, не сохраненного в контроле версий, по-прежнему помещает пароль и средство для чтения, если они зашифрованы, на диске и доступно злоумышленнику. Вы можете немного ожесточить ситуацию, убедившись, что разрешения файла конфигурации очень ограничены, но если поле будет укоренено, вы ввернуты.

Что приводит нас к тому, почему размещение паролей на диске - плохая идея. Это нарушает концепцию брандмауэра безопасности. Одна скомпрометированная машина, содержащая информацию для входа, означает, что другие машины будут скомпрометированы. Один плохо обслуживаемый компьютер может разрушить всю вашу организацию.

В какой-то момент человеку нужно будет ввести критический секрет, чтобы начать цепочку доверия. Что вы можете сделать, так это шифрование всех секретов кода, а затем, когда система запускается, человек вручную вводит ключ для дешифрования всех паролей. Это похоже на основную систему паролей, которую использует Firefox. Он открыт для злоупотреблений, поскольку с момента взлома одного пароля многие системы могут быть скомпрометированы, но это удобно и, вероятно, более безопасно, поскольку пользователям приходится запоминать только один пароль и с меньшей вероятностью записать его.

Последний штрих должен гарантировать, что если информация о входе в систему будет скомпрометирована (и вы всегда должны предполагать, что она будет), что A) злоумышленник не может с этим справиться, а B) вы можете быстро закрыть скомпрометированные аккаунты , Первый означает предоставление только учетным записям как можно большего доступа. Например, если ваша программа только когда-либо должна читать из базы данных, она зарегистрируется в учетной записи, ограниченной для SELECT. В общем, удалите весь доступ, а затем добавьте его только по мере необходимости. Будьте скупы по поводу прав на удаление, чтобы вы не посетили небольшие таблицы Bobby .

Последнее означает, что вы даете каждому пользователю / организации / проекту свой собственный логин, даже если они могут иметь одинаковые права и привилегии и получать доступ к тем же данным. Это немного больше хлопот, но это означает, что если одна система скомпрометирована, вы можете быстро закрыть эту учетную запись, не закрывая весь свой бизнес.

    
ответ дан Schwern 18.02.2009 в 04:37
  • ", но если поле должно быть укоренено, вы ввернуты.« Я в замешательстве - есть ли протоколы безопасности, в которых коренится часть модели угрозы? Я не могу представить, как вы могли бы защитить от корневой атаки. –  christianbundy 21.03.2015 в 01:21
  • @christianbundy Когда одна система проникла, вы хотите убедиться, что они не могут использовать ее для проникновения в другую систему. В этом случае, если вы храните свой пароль базы данных на диске и прошивается одна машина, злоумышленник теперь может получить доступ к вашей базе данных. Я предполагаю, что код приложения и база данных запущены на разных серверах. Также вам не нужно быть root для чтения файла конфигурации приложения, вам просто нужно быть пользователем приложения, что намного проще. Вам это даже не нужно, вам просто нужно обмануть приложение, чтобы вы могли просмотреть его конфигурационный файл. –  Schwern 21.03.2015 в 18:26
  • , если ваша система проникла, как можно заставить злоумышленника прочитать пароль? Сохранение его в файловой системе легко читается через FS I / O, сохранение его в среде легко читается через / proc /, а сохранение его в ОЗУ легко читается через / dev / mem. Какую альтернативу вы предлагаете? –  christianbundy 22.03.2015 в 19:33
  • @christianbundy Хранить все зашифрованные пароли. Когда процесс начинается, введите ключ, чтобы расшифровать их. Это будет только в памяти. Хотя чтение / dev / mem может быть легким, если у вас есть root, найти что-то конкретное в нем нет; безусловно, значительно сложнее, чем чтение из файла. Это мое понимание того, как работают серверы ключей. Это, безусловно, лучше, чем наличие четких паролей в контроле источника, проверенных на кучу dev-машин. Для получения более точного ответа обратитесь к Security.SE. –  Schwern 22.03.2015 в 20:16
6

Я предполагаю, что вы не хотите, чтобы личные пароли вашей компании были доступны, зашифрованы, дешифрованы или иным образом для тех, кому в противном случае разрешен доступ к остальной части источника.

Вот как я это делаю. Я продублировал этот шаблон из TikiWiki, который тоже делает это.

в каком-то файле, который обычно содержит пароли, устанавливает их в фиктивные значения, не имеет значения, что. Установите его так, как должен видеть ваш клиент. Поставьте комментарий для разработчиков, чтобы оставить этот файл в покое и изменить второй файл.

Во втором файле, который создается, если его нет, поместите фактические пароли. организовать, чтобы этот файл был включен, импортирован, что угодно, первым файлом.

Расположите свой источник, чтобы игнорировать этот файл. Может выглядеть примерно так:

# 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"
    
ответ дан SingleNegationElimination 18.02.2009 в 03:42
1

Я создал системы, в которых пары userid / password базы данных не являются частью кода. Ключом является настройка механизма конфигурации для конкретного сайта. Затем вы можете разместить такую ​​информацию в соответствующем поле, не входя в кодовую базу.

Есть бонус: вы можете не только иметь разные пароли для разного снижения кода, но и для разных разработчиков. : -)

    
ответ дан staticsan 18.02.2009 в 03:51
  • Хорошая точка. Один сценарий у нас есть, где наш скрипт развертывания работает sql против db (может быть dev, qa, prod и т. Д.). Все это делается на одном сервере развертывания. Не знаете, как реализовать это решение в этом случае. –  Marcus Leon 18.02.2009 в 04:30
  • Способ сделать это для скрипта sql-update для запуска на конечном целевом сервере. Затем он может использовать локальную конфигурацию для поиска базы данных. :-) –  staticsan 18.02.2009 в 23:00
-1

Вы не упомянули язык, поэтому вот решение vb.net, которое мы используем:

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
    
ответ дан BenB 18.02.2009 в 03:34
  • Наш процесс сборки / развертывания - ANT. Наш код приложения - это Java. –  Marcus Leon 18.02.2009 в 03:36
  • MD5? TripleDES? Черт, MD5 уже скомпрометирован, и 3DES уже на пороге. Используйте AES и SHA256. Что еще более важно, как только вы зашифровали учетные данные для входа, где вы поместили ключ дешифрования? Куриное яйцо. –  Schwern 18.02.2009 в 04:48
-5

Храните пароли в зашифрованном виде. Напишите специальную подпрограмму, которая расшифровывает пароли и обновляет файлы конфигурации во время сборки. Это можно легко интегрировать с инструментом сборки, например Ant.

    
ответ дан Rahul 18.02.2009 в 03:29
  • Итак, где вы помещаете ключ дешифрования? –  Schwern 18.02.2009 в 04:38
-8

Если вы делаете в C, вы можете хранить его в виде массива символов и помещать символы в десятичные ссылки. Не уверен, что это приведет к поломке строк или нет, но может помочь устранить некоторые из этих проблем.

char pass[]={72, 101, 108, 108, 111};
    
ответ дан Suroot 18.02.2009 в 03:25
  • Boshfpngvba qbrf abg cebivqr frphevgl! –  Schwern 18.02.2009 в 04:15
  • eewwwwwwwwwwwwwww –  Carson Myers 27.02.2010 в 21:59