Как хранить конфиденциальные данные пользователей?

Question

[Алексей]

Всем привет!

Поделитесь опытом/идеями, как хранить API-ключи, secret-ы, токены и т.д. пользователей (для доступа к сторонним сервисам). В открытом виде в БД, разумеется, не вариант
* шифровать с помощью пароля (который задается при регистрации на сайте/приложении)
* использовать сторонние сервисы (какие?)

Может, кто-то уже сталкивался

Answer 1

[xmoonlight]

1. Никакого шифрования с помощью пароля! Т.к. никакого пароля в зашифрованном виде на сервере => Только парольный хеш!
2. Никаких сторонних сервисов, включая CRM и подобные => Данные - конфиденциальные!
3. Шифруйте данные с помощью серверного ключа и с помощью встроенных средств шифрования выбранной базы данных.
4. Серверный ключ для дешифровки, обработку конф.данных и хранилище конф.данных - храните на 3-х различных серверах с взаимодействием по API (лучше, с контролем поведенческим фильтром на промежуточных узлах при запросах).
5. При передаче между различными хостингами - используйте свой протокол шифрования (помимо SSH, TLS/SSL).

Comments

[Алексей]

Четвертый пункт можно поподробнее? На каком-нибудь сферическом коне в вакууме

[xmoonlight]

amexlar, тут

[xmoonlight]

amexlar, советую вот это ещё "порыть" подробно.

[Boris Köln]

Только парольный хеш

Сторонний сервис для доступа требует логин-пароль. У вас есть хэш пароля и ключ шифрования. Что вы предлагаете делать автору вопроса?

[xmoonlight]

Boris Korobkov, я думал, что сторонние - это сервисы (площадки) автора...

Тогда такие варианты:
1. Шифровать и держать таблицу соответствий (1-к-1): user (этой системы) <-> user:pass (для сторонней)
2. Проксировать запросы к стороннему сервису (если это возможно!)
3. Использовать OAuth/API, если это предоставляют сторонние сервисы.

Возможно, есть ещё варианты...

[Алексей]

xmoonlight, сторонние сервисы - это внешние (не наши) сервисы. Суть такая: эти сервисы для автоматического управления выдают юзерам некие API-key и secret, которые юзер должен ввести у нас в личном кабинете. И ввести желательно только один раз, чтобы не приходилось их запрашивать на каждый чих. Соответственно, нам приходится их как-то хранить
При разработке, конечно, удобно, что эти данные лежат в открытом виде в БД, но на продакшне это недопустимо

[xmoonlight]

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