Какие подводные при хранении токенов в memcached?

Question

[accountnujen]

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

Comments

[Everything_is_bad]

не понятно каким местом тебе тут поможет memcached

конечно приватную информацию в коде не хранят, потому он уходит за пределы сервера, в тот же github, минимум выносят в переменные окружения

[accountnujen]

Everything_is_bad, в смысле каким местом? ты так и не сказал, что именно не так с memcached.
вместо "12345678" я буду делать $memcached->get("password")

[Everything_is_bad]

accountnujen, так и какая тут защита? намного проще держать в env, а если злоумышленник попал на сервер, то как его остановит memcached

[accountnujen]

Everything_is_bad, давай тогда от обратного: чем выигрывает тогда запись данных в env?

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

[Everything_is_bad]

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

[Михаил Ливач]

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

[ThunderCat]

accountnujen,

вместо "12345678" я буду делать $memcached->get("password")

Занятно... а как (и главное откуда) в memcached будет попадать password?

[accountnujen]

Everything_is_bad,

переменные окружения это стандартных механизм, читается из памяти

ок, почему в дефолте он отключен? если "ENV is not as commonly used", то что тогда часто используется?

; This directive determines which super global arrays are registered when PHP
; starts up. G,P,C,E & S are abbreviations for the following respective super
; globals: GET, POST, COOKIE, ENV and SERVER. There is a performance penalty
; paid for the registration of these arrays and because ENV is not as commonly
; used as the others, ENV is not recommended on productions servers. You
; can still get access to the environment variables through getenv() should you
; need to.
variables_order = "GPCS"

ThunderCat,

Занятно... а как (и главное откуда) в memcached будет попадать password?

как-как... вот так: $memcached->set("password")

[Everything_is_bad]

accountnujen, а ты точно прочитал что тут написано? всегда доступны через getenv.

[ThunderCat]

accountnujen,

как-как... вот так: $memcached->set("password")

о, прикольно. Во первых будет $memcached->set("password",'12345678'), а во вторых значит в коде где-то всё-таки будет '12345678', что возвращает нас к начальной проблеме - для того чтобы засетить мемкеш нужно иметь где-то в доступном для кода месте данные. Ой, подождите... это же то от чего вы пытались избавиться?

[ThunderCat]

accountnujen,

ок, почему в дефолте он отключен? если "ENV is not as commonly used", то что тогда часто используется?

До конца читали? through getenv().

[accountnujen]

ThunderCat,

о, прикольно. Во первых будет $memcached->set("password",'12345678'), а во вторых значит в коде где-то всё-таки будет '12345678', что возвращает нас к начальной проблеме - для того чтобы засетить мемкеш нужно иметь где-то в доступном для кода месте данные. Ой, подождите... это же то от чего вы пытались избавиться?

файлик с парами ключ-значение может быть зашифрован через aes-128-gcm и первый $mem-set() будет через ввод пароля от этого шифра. Поэтому, если ты получишь файлы - ты только увидишь зашифрованные пары.

До конца читали? through getenv().

есть подозрение, что getenv() и $_ENV не одно и тоже. иначе зачем иметь два разных способа по написанию.

[ThunderCat]

accountnujen,

есть подозрение, что getenv() и $_ENV не одно и тоже.

нет. обращение к переменной и геттер - разные вещи.

иначе зачем иметь два разных способа по написанию.

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

файлик с парами ключ-значение может быть зашифрован через aes-128-gcm и первый $mem-set() будет через ввод пароля от этого шифра.

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

Короче. Смысл ключей/паролей в доступе к компонентам сервера, а если есть код который можно как-то исполнить на сервере, все резко теряет смысл, так как var_dump() никто не отменял. Все упирается не в ключи, а в безопасность сервера в целом. Если у вас какая-то уникальная ситуация, то ее уникальность от сообщества как-то ускользает, по этому вам советуют типовые решения, удовлетворяющие 99% разработчиков.

Answer 1

[ThunderCat]

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

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

Основным общепринятым "правильным" методом хранения паролей на сегодня является использование .env файла, он лежит выше документ рут, имеет атрибут скрытого по умолчанию в линукс системах, а так же большинство IDE автоматически вносят такие файлы в гитигнор, то есть сразу удовлетворяет большинству требований.

Answer 2

[Василий]

можно хранить в .env файле если секреты не надо часто изменять обновлять. Если надо можно использовать
vault https://developer.hashicorp.com/vault
это key/value хранилище тут можно через веб морду секретами управлять