Приложение для аутентификации приложения / контроля доступа без HTTPS

Question

В текущем проекте, над которым я работаю, возникла следующая проблема.

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

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

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

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

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

Любая помощь высоко ценится. Заранее спасибо!

Answer 1

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

Протокол:

0) серверы извлекают salt для этого конкретного пароля из базы данных, генерируют salt2 и отправляют оба клиенту

1) клиент отправляет hash(hash(password, salt), salt2, timestamp) и timestamp.

2) сервер извлекает hash(password, salt) из базы данных и сравнивает.

Обратите внимание, что если вы находитесь в сети, где злоумышленники могут не только прослушивать, но и изменять трафик , как Пауло указал , вы должны подписывать КАЖДОЕ сообщение : hash(hash(password, salt), salt2, timestamp, message) и проверьте это на сервере. (Например, для случая, когда злоумышленник может изменить сообщение, чтобы оно содержало команду удаления ...)

Обратите внимание, что по-прежнему существует проблема , когда пользователю необходимо безопасно УСТАНОВИТЬ / ИЗМЕНИТЬ пароль . Вы не можете сделать это безопасно, просто используя хэш-функцию в небезопасной сети, вам нужен какой-то шифр / расшифровщик.

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

Answer 2

Вместо того, чтобы придумывать собственное решение, вы должны использовать уже установленное. SOAP поддерживает криптографическую аутентификацию, такую ​​как WS-Security - см. Комментарий Крэйга Форстера к этому ответу для предложений.

Лучшим выбором в других случаях обычно является oauth ; он обеспечивает как авторизацию, так и аутентификацию, а также решает множество криптографических проблем, которые вы вряд ли обнаружите при создании собственного.

Answer 3

Использование решения для аутентификации, которое не содержит проверки целостности всего сообщения (или потока), небезопасно.

В то время как решение для хеширования, первоначально предложенное Томасом Т. (hash(hash(password, salt), salt2, timestamp), где hash(password, salt))хранится в базе данных, и salt2 создается заново) гарантирует, что злоумышленник не сможет получить пароль (или любые данные, которые будут полезны для входа в систему после истечения времени), он сам по себе не препятствует активному злоумышленникуперехватить сеанс после аутентификации и отправить любые требуемые запросы SOAP (и перехватить ответы).

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

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

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

Еще один способ просмотреть это - принять сообщение для аутентификации в качестве ввода во внешний хеш вСхема аутентификации Томаса Т.(Убедитесь, что аутентифицировали все, что стоит аутентифицировать.)