Правильное хранение паролей для подключения к БД и т.п.

man криптография // thread

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

а субд должно торчать только в локалхост

Так-с. В чём профит криптографии для хранения данных подключения к БД в случае, когда все файлы проекта оказались доступны публично?

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

Коротко ответ на твой вопрос:

В связи с этим вопрос, где таки хранить пароли? В переменных среды? Или таки нужно вместо паролей использовать ещё что?

Где угодно. Важно зашифровать пароли стойким алгоритмом. Если на взлом шифра требуется несколько лет этого уже более чем достаточно в 95% случаях.

а субд должно торчать только в локалхост

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

Друг мой, ты говоришь не о том. Вот тебе конспект:

Был доступен просмотр ... конфигурационного файла. ... некоторые хранят там данные для подключения к БД

Ты мне предлагаешь зашифровать их стойким алгоритмом, а затем при каждом запросе «несколько лет взламывать шифр», чтобы подключиться к БД?

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

В связи с этим вопрос, где таки хранить данные для подключения к БД и др. подобные вещи? В переменных среды? Или таки нужно вместо паролей использовать ещё что?

Ответ на этот вопрос хорошо описан у Эрика Рэймонда. По сути все эти пароли security by obscurity. Рассмотрим случай, когда пароль передается через параметры запуска программы:$ ps xawu выдаст нам результат. Любые манипуляции с файлами, до которых есть доступ у текущего процесса дадут результат.

Более сложные схемы:

• Две базы: в одной ключи, в другой данные
• Hardware-based: удаленный ввод пароля/шифра, usb-ключи, сканеры сетчатки глаза и т.п.

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

Для поделий на гитхабе текущая схема проекта идеальна: она проста, удобна, не жрет лишних ресурсов и проверена временем. То, что нашли дыру — критичный баг, который закроют и все будет чики пуки. ИМХО, это напоминает возрождение Joomla, которая несла, несет и будет нести в себе подобные баги, ибо это не лечится :)

Поскольку ты изменил вопрос уже после... и теперь это что-то вменяемое

Это было вменяемым с самого начала (заметь, первый комментатор всё понял правильно). Вопрос был отредактирован для Ъ, читающих только заголовок и последнее предложение.

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

Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.

Любые манипуляции с файлами, до которых есть доступ у текущего процесса дадут результат.

Если есть доступ к выполнению произвольных команд от имени процесса - это конечно уже фейл и с этим ничего не поделаешь. Но в стартовом посте была ссылка на уязвимость, которая позволяла лишь смотреть системные файлы вне public директории (а это только config файл).

И таки да, мы ведь речь про web ведём, верно?

Настройки выставлять через переменные окружения.

ps e, strings -a /proc/<pid>/environ, etc.

не хранить никак, вводить при каждом запуске (один раз в год не проблема)

Ничего что один раз в год может оказаться не достаточно? Вообще ворос «где хранить пароли» не правильный. Лучше всего хранить часть пароля в кармане, а часть еще где нибудь. Правильный вопрос - Как ограничить доступ к паролям со стороны ПО и людей?