Как мне хранить известный/жестко закодированный пароль в базе данных?

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

Моя первоначальная мысль состояла в том, чтобы хранить эти данные в базе данных, которая используется для поддержки веб-сайта. Я хочу хранить его таким образом, чтобы его было нелегко «взломать» (т. е. я не собираюсь хранить его как обычный текст или как хэш MD5). Должен ли я следовать тому же формату, который я использую для хранения паролей пользователей веб-сайта, где я использую генератор случайных чисел для создания SALT для каждого пароля, а затем сохраняю пароль в виде хешированной комбинации пароля и SALT, или это было бы излишним?


person Eric Belair    schedule 19.03.2019    source источник
comment
Хеширование с помощью SALT НЕ будет работать, так как я не смогу расшифровать хешированную строку....   -  person Eric Belair    schedule 20.03.2019


Ответы (2)


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

Теперь вы можете хранить его либо в БД, либо в файлах конфигурации, в зависимости от вашего приложения.

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

В нашем продукте мы справляемся с такой ситуацией, используя 2 Way SSL Certificates. Это очень безопасно, и нет необходимости хранить пароли.

Но если вам действительно нужно хранить пароли, то я предлагаю использовать configuration file и позволить вашему приложению прочитать его. Вы можете зашифровать пароли, хранящиеся в configuration files (Шифрование паролей, хранящихся в configuration file, снова вернет вас к тому же вопросу о том, как защитить ключ). Доступ к configuration file должен быть ограничен (в Unix 600 File Permission).

В качестве альтернативы, если ваше веб-приложение создано на Java, вы можете рассмотреть возможность использования JNDI< /а>.

person Ameen Ali Shaikh    schedule 20.03.2019
comment
Спасибо. Я должен был упомянуть, что это установка IIS/ColdFusion/SQL Server. Я не уверен, какой файл конфигурации я бы использовал? Я рассмотрю JNDI, поскольку ColdFusion по сути работает поверх Java. - person Eric Belair; 20.03.2019

После дополнительных исследований я решил на этом этапе следовать идеям здесь:

Шифровать столбец данных - SQL Server | Документы Майкрософт

... и шифровать/дешифровать в БД внутри хранимой процедуры.

person Eric Belair    schedule 20.03.2019