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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Не беспокойтесь, шифруя что угодно. (Хранилище с обычным текстом)

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

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

Answer 1

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

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

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

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