Лучшие практики для хранения конфиденциальной информации пользователя на удаленном сервисе

Question

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

Мы хотим предоставить сервис для синхронизации своих настроек на нескольких компьютерах и устройствах. То есть - они входят в сервис, который мы предоставляем, а затем эта информация синхронизируется везде, где они вошли.

У нас нет способа заставить сторонние приложения прекратить использовать незашифрованные пароли.

Есть несколько подходов, которые мы рассмотрели:

1. Никогда не отправляйте пароли или токены аутентификации.

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

   Преимущество: Безопасный, без риска компрометации пароля / токена.
   Недостаток: сложно для пользователей.

2. Шифрование конфиденциальной информации с помощью сертификата клиента или аппаратного токена.

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

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

3. Шифрование конфиденциальной информации с помощью пароля, предоставленного пользователем

   Когда пользователь входит в систему на новом устройстве, ему будет предложено ввести пароль.
   Если пароль неверный, им необходимо повторно ввести / аутентифицировать все остальные устройства.

   Преимущество: Безопасный, если пользователь предоставляет надежный пароль.
   Недостаток: если пользователь сбрасывает свой пароль, ему необходимо повторно авторизовать устройство для всех сторонних приложений.

4. Шифруйте конфиденциальную информацию на наших серверах.

   Преимущество: Легко для пользователей.
   Недостаток: только немного больше работы, чем открытый текст для тех, кто захватывает таблицы настроек.

5. Не надо ничего шифровать. (Хранение открытого текста)

   Преимущество: Легко для пользователей.
   Недостаток: Легко для любого, кто захватывает нашу БД, чтобы получить все пароли / токены пользователя.

Мой вопрос: Есть ли лучший подход, который мы еще не рассматривали?

Answer 1

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

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

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

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