Меню
Что нового?

Как обезопасить себя от хранения и оперирования логинов\паролей (не пользовательских)?

Крот

Новичок
Привет,

Если таблица, в которой хранятся логин\пароль от доступа к различным сайтам, а порой даже достаточно важным сайтам. Пускай для понятности ее структура будет содержать колонки: serviceId, name, login, password. В колонках login, password данные лежат в открытом виде и это очень плохо.

Этими паролями оперируют php скрипты, которые запускаются в CLI режиме. Сами скрипты запускаются по крону, иногда руками.

Нужно обезопасить себя и :
  • свести к 0% возможность завладеть паролем\логином в случае, если злоумышленник получил доступ к базе данных
  • постараться свести к минимуму возможность завладеть паролями даже если злоумышленник завладел доступом на сервер (назовем его application)
Первый пункт, имхо, достаточно просто выполним и есть масса вариантов его решения: храним пароли в зашифрованном виде + храним пароли на сервере (назовем его keeper), который с наименьшей вероятностью может быть скомпрометирован.

Второй пункт сложнее, т.к. пользователь, получив доступ к серверу может легко задебажить php скрипт и забрать нужный логин и пароль. В принципе это также можно усложнить, если закодировать Zend'ом или ionCube'ом. Чисто теоритечески это должно усложнить процесс дебага.

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

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

Спасибо!
 
WMix

WMix

герр M:)ller
Партнер клуба
общайся через тунель с промежуточным сервисом ограниченным в функционале, с закрытой базой, на зашифрованном жестком диске, используя презерватив
 

AnrDaemon

Продвинутый новичок
hell0w0rd

hell0w0rd

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

Hello

Новичок
@hell0w0rd, зачем приватный ключ? Ассиметричное шифрование тут не нужно.
Делается через сервер ключей.
  1. Сервер ключей котролирует раздачу ключей для серверов ПО. Виден только в локальной сети.
  2. Сервер БД хранит данные, взломав его ничего не получим.
  3. Сервер ПО, получает ключ с сервера ключей при старте.
 

Крот

Новичок
На самом деле мне больше всего понравился вариант @WMix - сделать какой-то промежуточный сервис (читай проксю), который был бы более защищен и через него делать все запросы необходимые. Таким образом даже если злоумышленник получает доступ к application серверу, то всё что он может сделать - выполнить ряд запросов к "проксе", регламентированных ее API. Но этот способ наиболее трудоёмкий, т.к. подразумевает разработку ПО "прокси" и модификацию уже существующего кода приложения.

Hello написал(а):
@hell0w0rd, зачем приватный ключ? Ассиметричное шифрование тут не нужно.
Делается через сервер ключей.
  1. Сервер ключей котролирует раздачу ключей для серверов ПО. Виден только в локальной сети.
  2. Сервер БД хранит данные, взломав его ничего не получим.
  3. Сервер ПО, получает ключ с сервера ключей при старте.
Нажмите для раскрытия...
А где хранить ключ? Просто в памяти? Как быть например с ситуацией, если у злоумышленника есть доступ к application серверу. Он может всегда посмотреть результат выполнения decrypt($encryptedPassFromDb, $keyFromMemory) либо вообще просто проснфать запросы, идущие к серверу.

PS: Под злоумышленником я не всегда подразумеваю какого-то хакера. Иногда этим самым злоумышленником может являться админ сервера. Уже сталкивались с ситуацией, когда админ, ответственный за managed сервера у хостера банально продавал дамп базы. :)
 
hell0w0rd

hell0w0rd

Продвинутый новичок
Крот написал(а):
либо вообще просто проснфать запросы
Нажмите для раскрытия...
https
Крот написал(а):
Иногда этим самым злоумышленником может являться админ сервера.
Нажмите для раскрытия...
ну тут как всегда. Ты можешь что угодно делать, писать какую угодно защиту, а люди тебе все обгадят. Тут уже нужна юридическая защита.
 
Hello

Hello

Новичок
Крот написал(а):
А где хранить ключ? Просто в памяти? Как быть например с ситуацией, если у злоумышленника есть доступ к application серверу. Он может всегда посмотреть результат выполнения decrypt($encryptedPassFromDb, $keyFromMemory) либо вообще просто проснфать запросы, идущие к серверу.
Нажмите для раскрытия...
Если знаешь другие структуры для хранения временных ключей, можешь хранить там.
Я описал как не хранить ключ на сервере который делает запросы к БД. Это может быть как application сервер, так и сервис API который возвращает учётные данные пользователя.
 
Войдите или зарегистрируйтесь для ответа.
Сверху