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

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

Connection c = DriverManager.getConnection("url", "username", "password");

Это довольно опасно. Если злоумышленник получает доступ к исходному коду, он также получает доступ к самой базе данных. Как мое веб-приложение может подключиться к базе данных без сохранения пароля базы данных в открытом тексте в исходном коде?

Ответы

Ответ 1

Вы можете сохранить строку подключения в файле Web.config или App.config и зашифровать раздел, который ее удерживает. Здесь очень хорошая статья, которую я использовал в предыдущем проекте для шифрования строки подключения:

http://www.ondotnet.com/pub/a/dotnet/2005/02/15/encryptingconnstring.html

Ответ 2

В .NET соглашение состоит в том, чтобы хранить соединительные строки в отдельном файле конфигурации.

В этом случае файл конфигурации можно зашифровать.

Если вы используете Microsoft SQL Server, все это становится неуместным, если вы используете учетную запись домена для запуска приложения, которое затем использует надежное соединение с базой данных. В этом случае строка соединения не будет содержать имена пользователей и пароли.

Ответ 3

Я могу рекомендовать эти методы для .NET-программистов:

  • Шифровать пароль\строка подключения в файле конфигурации
  • Установить доверенное соединение между клиентом и сервером (например, использовать windows auth и т.д.)

Вот полезные статьи из CodeProject:

Ответ 4

Если мне не хватает точки, то соединение должно управляться сервером через пул соединений, поэтому учетные данные подключения хранятся сервером, а не приложением.

Принимая это в дальнейшем, я обычно строил соглашение, в котором внешнее веб-приложение (в DMZ) ведет переговоры только с БД через веб-службу (в домене), поэтому обеспечивает полное разделение и улучшенную безопасность БД.

Кроме того, никогда не давайте priviliges для учетной записи db сверх того, что по существу необходимо.

Альтернативный подход - выполнять все операции с помощью хранимых процедур и предоставлять пользователю приложения доступ только к этим процессам.

Ответ 5

Предполагая, что вы используете MS SQL, вы можете воспользоваться проверкой подлинности Windows, которая не требует ввода имени пользователя/передачи в любом месте исходного кода. В противном случае мне придется согласиться с другими плакатами, рекомендующими шифрование app.config +.

Ответ 6

  • Создайте пользователя O/S
  • Поместите пароль в переменную среды O/S для этого пользователя
  • Запустите программу как пользователь

Преимущества:

  • Только root или этот пользователь может просматривать переменные среды O/S пользователя
  • Выжить при перезагрузке
  • Вы никогда не проверяете пароль в исходном коде.
  • Вам не нужно беспокоиться о том, чтобы установить права доступа к файлам.
  • Вам не нужно беспокоиться о том, где вы храните ключ шифрования
  • Работает x-платформа