Защита системы входа без паролей

Question

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

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

1. Новый пользователь впервые открывает приложение на определенном устройстве и вводит свой адрес электронной почты. Адрес электронной почты отправляется на сервер вместе со статическим токеном, встроенным в приложение (которое одинаково для всех экземпляров приложения).
2. Сервер проверяет токен и тот факт, что адрес электронной почты является @company.com. Он отвечает новым токеном / ключом для использования только с тем пользователем и устройством, которые клиент хранит в виде простого текста локально. Этот ключ фактически является паролем пользователя. Он хэшируется, сохраняется в базе данных сервера и помечается как отключенный.
3. На данный момент есть две возможности:
   1. Сервер отправляет электронное письмо на этот адрес, подтверждающее, что он хочет войти в систему на новом устройстве. Письмо содержит ссылку, которая при нажатии помечает ключ как включенный. Потребуется ограничение скорости запросов новых устройств, чтобы люди не могли получить спам, если кто-то обнаружит токен, встроенный в приложение.
   2. Администратор специально одобряет запросы новых устройств.
4. Каждый последующий запрос клиента к серверу должен включать ключ.

Предполагая, что все общение происходит по SSL, это звучит как безопасная стратегия? Есть ли более безопасный или простой подход?

Кроме того, каков наилучший способ создания токена, который будет храниться на стороне клиента? Поскольку я хочу, чтобы пользователи вводили свой адрес электронной почты только при первом использовании приложения, я считаю, что этот токен никогда не изменится. Вот мой текущий алгоритм (PHP), свободно основанный на drupal_get_token() Drupal:

// Usage: get_token($email) or get_token($client_token)
function get_token($value = '') {
  $salt = hash('sha256', 'Some static, predefined phrase');
  $hmac = base64_encode(hash_hmac('sha256', $email, $salt, TRUE));
  return $hmac;
}

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

Answer 1

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

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