Как скрыть пароль в php-коде?

Question

[webymax]

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

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

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

Answer 1

[humoured]

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

Comments

[webymax]

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

[humoured]

доступны любому разработчику, имеющему доступ к аккаунту хостинга

Разработчики не должны иметь доступа к хостингу. Они должны иметь доступ к репозиторию с кодом. Несколько человек пишут код, а один, имеющий доступ к хостингу и паролям, занимается деплоем — выкладывает код из репозитория на хостинг и создаёт production-конфиг.

[vokskela]

webymax, я думаю тут два варианта:
1) хранить хэш пароля (но smtp сервер вряд-ли его примет без дешифровки)
2) сейчас почти все почтовые сервера умеют выдавать отдельные пароли к внешним приложениям. Например https://help.mail.ru/mail/security/protection/external

[webymax]

Разработчики не должны иметь доступа к хостингу

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

[humoured]

webymax, в случае смены команды разработчиков, новой команде передаётся репозиторий с кодом.

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

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

[webymax]

vokskela, п. 2 отчасти спасает ситуацию, тоже его рассматриваю. Видимо, это единственный приемлемый вариант.
Можно ещё, конечно, как-то по хитрому закодить составление пароля (например, разложить по символам на переменные и как-то их нелинейно составлять...), чтобы он не был показан в коде в обычном текстовом виде, но всё равно ведь его нужно будет скармливать SMTP-серверу в готовом виде...

[humoured]

как-то по хитрому закодить составление пароля

Это так не работает.

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

[webymax]

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

[vokskela]

webymax, ну я и говорю, хранить пароль в зашифрованном виде, добавить функцию дешифрации при отправке пароля почтовому серверу. Его можно будет увидеть в процессе отладки, это само собой, но он уже не будет в открытом виде храниться. Но всё равно это костыли.
Оптимальный вариант это через сервис внешних приложений, либо аутентификация по api ключам, либо по сертификатам

[vokskela]

webymax, составляйте юридически правильный договор о передачи прав на интеллектуальную собственность и пароли

[humoured]

webymax,

1. Делайте репозиторий с кодом.
   Если репозиторий будет на публичном сервисе типа github.com, то создавать его должен заказчик. Он выдаст доступ вам. И другим разработчикам. В этом репозитории должен хранится только код приложения без паролей.
   
2. Делайте механизм развёртывания приложения: выгрузка кода на хостинг, создание конфигурационного файла. Этот механизм должен знать все пароли и запускаться локально заказчиком или вами.
   

При смене команды разработчиков — просто передавайте доступ к репозиторию с кодом.
При этом доступ к механизму развёртывания и паролям остаётся у заказачика или у вас.

[webymax]

Это так не работает.

Я имел ввиду что-то подобное, если примитивно:

$alph = '[перечисляем алфавит]';
$pwd = $alph[10].$alph[2].$alph[12]...;

Но это баловство, конечно, vokskela про это в принципе и пишет.

[humoured]

webymax, и от кого это поможет скрыть данные? От разработчиков, которые имеют прямой доступ к коду?
echo $pwd;

[webymax]

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

[webymax]

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

Не, ну в любом ведь случае пароль должен оказаться на хостинге. И если хостинг принадлежит заказчику, то он может передать сторонним разработчикам доступ к хостингу, и те всё увидят.

[webymax]

vokskela, договор не спасает от утечки. По факту утечки в ход идёт претензионно-исковая работа на основе договора и виновник будет наказан, но утечка уже произошла.

[vokskela]

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

[webymax]

vokskela, слушайте, а ведь отличная идея ) Спасибо, что додумались до такого )

[shurshur]

webymax,

и понимает, что заказчик может передать доступы любому стороннему разработчику

Это должна быть головная боль заказчика, а не разработчика, что и кому он передаёт и как это всё ломает.

[webymax]

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

[shurshur]

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

[webymax]

shurshur, не совсем понял решение, в принципе мог бы разобраться, но по всей видимости это можно провернуть на выделенном сервере. Мы оформляем на заказчиков аккаунты на обычных виртуальных хостингах, где далеко в настройки не пройдёшь, да и выделенный IP заказчикам обычно не требуется, тем более он идёт за отдельную плату.

[humoured]

фигурирует доступ к почтовому аккаунту нашей веб-студии и меня это настораживает

Используйте учётные данные заказчика, пусть передаёт их кому хочет. А свои — только для локального тестирования.

[webymax]

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

[webymax]

Выше подсказали вариант с использованием второго сервера, мне этот вариант очень понравился. Вопрос можно считать закрытым.

[shurshur]

webymax, ну да, у этого решения тоже есть недостатки. Например, если это виртуальных хостинг с кучей сайтов на одном IP, то все эти сайты смогут отправлять через этот сервер (если догадаются посылать через него). Просто это довольно простое решение, и в некоторых случаях именно так и делают.

[Uno]

Мастурбация.
Сделай хэндлер у себя где нибудь на пхп и шли туда все что хочется без паролей.

[webymax]

Uno, поясните, пожалуйста, что вы конкретно имеете ввиду. Во втором абзаце )

[Uno]

webymax, domain.com/handler.php?website=url&error=3

[webymax]

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

[webymax]

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

Answer 2

[zvlad_vitamin]

..но, если разработчики будут иметь доступ на ФТП, то никак не скрыть.

Answer 3

[psiklop]

В аккаунте яндекс, mail.ru нужно создавать отдельные пароли для каждого приложения доступа по smtp.
Так его тоже видно, но все таки гораздо безопасней. Пароль легко сменить вместе с закрытием доступа по FTP.
Хотя было бы гораздо лучше если бы яндекс и прочие давали возможность привязать такой временный пароль к IP адресу.

Еще вариант поставить этому файлу права 600 и владельца www-data. Вообщем, чтобы сайт работал, но этот ftp-user не мог его открыть.

Comments

[webymax]

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

Выставление прав и владельца на файл не спасёт от прямого доступа через аккаунт хостинга.

[psiklop]

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

[webymax]

psiklop, реальная ситуация такая - почта отправляется с сайта через почтовые аккаунты заказчика, как и положено. Но на случай возврата почтовым скриптом ошибки отправки я посылаю отчёт об ошибке уже с почтового аккаунта нашей веб-студии, чтобы исключить проблему с почт. аккаунтом заказчика. Получается, что доступ к почтовому акку веб-студии светится в коде, что меня как-то угнетает )

[psiklop]

webymax, ясно куча одностраничных прототипов, за всеми надо следить, чтобы налоги собирать. Тут вам виднее.

[webymax]

psiklop, как только вам такое в голову пришло...

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

[AUser0]

webymax, а что, создать ещё один технический ящик - не судьба? И пусть пароль от него знает хоть 100 юзверей заказчика, всё равно неправильное содержимое прямиком улетит в /dev/null.

[webymax]

AUser0, да можно, конечно. Но заказчик ведь полностью управляет созданием ящиков на своём домене. У меня нет доступа к ящику, на который делегирован домен. Думаю заказчику проще отправить мне новый пароль, чем создавать новый тех. ящик.

Меня интересует безопасность своих собственных паролей, которые приходиться размещать в коде на сайте заказчиков.

[psiklop]

webymax, раз таких случаев много, можно завести специального телеграм бота и отчет об ошибке слать ему.

[webymax]

psiklop, интересная идея. Я пока не имел опыта с этим, но вариант мне кажется очень даже подходящий.

[psiklop]

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

[psiklop]

webymax, раз у вас студия, значит у вас есть и сайт, настройте веб-хук на свой сайт с ваших подопечных и все.

[psiklop]

webymax, например

$url = 'https://вашсайт/smtp_error.php';
$data = array('domain' => $_SERVER["SERVER_NAME"], 'smtp_error' => 'error');

$options = array(
    'http' => array(
        'header'  => "Content-type: application/x-www-form-urlencoded\r\n",
        'method'  => 'POST',
        'content' => http_build_query($data)
    )
);
$context  = stream_context_create($options);
$result = file_get_contents($url, false, $context);

А в smtp_error.php у себя можно обработать как душа пожелает

[webymax]

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

[psiklop]

webymax, можно еще проше просто писать ошибки в лог smtp_error.txt прямо на сервере подопечного и в случае жалобы открывать http://сайт/smtp_error.txt и смотреть, так как наверное никакой секретного инфо там нет, а если есть можно отфильтровать по IP

[webymax]

psiklop, нужно знать о проблемах подопечного раньше него самого.

Answer 4

[Владимир Коротенко]

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

Comments

[Алексей Тутубалин]

А разве разработчик не может прочитать от имени вебсервера, через другой php файл?

Answer 5

[Алексей]

У разработчика априори максимальный уровень прав, ведь именно он и пишет этот код.

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