хранение оригинального текста пароля

Question

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

Как хранить эти пароли?

Редактировать: IЯ обеспокоен, если кто-то получит доступ к моему серверу.Если я использую какое-то двухстороннее шифрование и у них есть доступ к серверу, они могут просто проверить, как пароли расшифровываются в моем бэкэнд-коде.

Answer 1

Я бы поступил следующим образом.

Защита данных от кражи оборудования:

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

Защита данных, если сервер взломан (взломан):

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

A) Рабочий сервер

• Имеет БД с паролями и т. Д., А также подключается к другим службам.
• Чтобы подключиться к рабочему серверу, пользователи могут сделать это через API.В API должна быть включена функция insertUserData, которая позволяет вставлять пользовательские данные, а API экранирует все входные данные.
• API использует пользователя БД, который имеет только права на ввод данных в таблице userData.
• Это был бы единственный способ связаться с этим сервером.
• Разрешить только SSL-соединения.
• Этот сервер, в свою очередь, запускает задания хрон, которые подключаются к внешним службам, извлекает из них данные и заполняет их БД.Используйте другую БД с разными привилегиями пользователя.
• Этот сервер запускает еще одну хроническую работу, которая подключается к переднему серверу и передает новые данные на передний сервер.
• Минимальное количество запущенных сервисов
• Только SSH / SCP от вашего IP, жесткий межсетевой экран.Заблокируйте, если соединения превысили X / min и т. Д., Так как они будут делать только случайную вставку.
• НЕТ FTP и т. Д.

B) Фронт-сервер

Получает данные с рабочего сервера, никогда не использует сами пароли.Единственный способ связаться с рабочим сервером через API, упомянутый выше, только для новой пользовательской информации.Именно здесь все пользователи входят в систему, чтобы увидеть свою информацию и т. Д.

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

Answer 2

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

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

Если вы просто гарантируете безопасность данных, еслиаппаратное обеспечение украдено, вы можете использовать решение для полного шифрования диска, такое как TrueCrypt или PGP WDE, или встроенный в Ubuntu, Debian или Fedora подход, требующий PIN-код или пароль при каждой загрузке.о безопасной передаче, имейте код, гарантирующий, что вы используете безопасность на транспорте, и не беспокойтесь о шифровании данных в вашей базе данных.

Answer 3

Мне кажется, что вы хотите хранить пароли аналогично Firefox и Chrome. Так почему бы не посмотреть, как они это делают?

Вот как это делает Chrome: http://www.switchonthecode.com/tutorials/how-google-chrome-stores-passwords

Answer 4

Если вы ДОЛЖНЫ сделать это, вы должны использовать двустороннее шифрование.Для этого существует множество алгоритмов (шифров), но в основном вы шифруете свои данные с помощью ключа шифрования и снова используете тот же ключ для их расшифровки.

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

• Blowfish
• 3DES
• Skipjack

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

/ Carsten

Answer 5

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

Получение доступа sudo. Развертывание вредоносного приложения на веб-сервере - это приложение получит доступ к ключу и сможет отправить его в другое место.

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

---

РЕДАКТИРОВАТЬ: Если подумать, вы можете просто сохранить конфиденциальные данные прямо включевой файл.Шифрование обеспечит дополнительный уровень безопасности, но это не будет очень сильный уровень;если злоумышленник получает доступ к файлу, велика вероятность, что он также имеет доступ к БД.