Это безопасно для хранения паролей в веб-приложении исходный код?

Вот то, что мы делаем с нашими паролями.

$db['hostname'] = 'somehost.com'
$db['port'] = 1234;

$config = array();
include '/etc/webapp/db/config.php';

$db['username'] = $config['db']['username'];
$db['password'] = $config['db']['password'];

У пользователя никакого но веб-сервера нет доступа к/etc/webapp/db/config.php, этот способ, которым Вы защищаете имя пользователя и пароль от разработчиков.

Нет. Иногда это неизбежно. Лучшему подходу нужно было настроить архитектуру, где сервис слепо доверит Вашему под управлением коду на основе другого доверия. (Такие как доверие машине код работает или доверяет серверу приложений, который запускает программное обеспечение),

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

Нет, это не.

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

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

Но источник "безопасное" место для "безопасности чувствительное" содержание (как пароли, ключи, алгоритмы). Конечно, это.

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

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

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

Это не должно быть рекомендовано.

Зашифрованный web.config был бы более подходящим местом (но примечание не может использоваться с веб-фермой),

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

Если Вы не управляете веб-сервером (скажите, Вы находитесь на общем или даже выделенном сервере, обеспеченном хостинговой компанией), то шифрование не поможет Вам очень; если приложение может дешифровать учетные данные на данном хосте, чем хост может использоваться для дешифрования учетных данных без вмешательства (думать root или Администратор, смотрящий на исходный код и адаптирующий стандартную программу дешифрования так, чтобы это могло использоваться для чтения конфигурации). Это - еще больше возможности, если Вы используете незапутываемый управляемый код (например, JVM или.NET) или веб-язык сценариев, который находится в простом тексте на сервере (как PHP).

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

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

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