Безопасна ли эта простая схема аутентификации REST?

Question

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

Влияющие факторы:

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

Предлагаемая схема аутентификации:

• "Зарегистрироваться" и "Вход" достигается через соединение TLS. В поле «Ввод» указывается имя пользователя и пароль, а серверный сервер возвращает общий секретный ключ (а затем хранится в локальном хранилище клиентом, например, локальным хранилищем HTML5, хранилищем приложений и т. Д.).
• Каждый другой запрос проходит через открытого текста HTTP

стороне клиента алгоритм:

• Перед отправкой каждый запрос «соленый» с общим секретным ключом и хэш SHA берется из соленых запрос.
• Этот хэш вставляется в запрос в пользовательском HTTP-заголовке.
• Соль удаляется из запроса.
• Запрос отправляется с настраиваемым заголовком.

Сервер алгоритм сторона:

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

Существуют ли какие-либо уязвимости в этой схеме, которые я забыл?

Answer 1

Я бы поставил под вопрос ваши предположения.

TLS везде слишком медленно и ресурс тяжелых

TLS становится почти повсеместно для API, и одна из причин, потому что это в настоящее время относительно дешевы для клиентов и серверов, чтобы поддержать его. Сколько накладных расходов? Как обычно, «это зависит», но, безусловно, ничтожно мало для большинства современных API, даже API-интерфейсов массового потребителя, таких как Facebook и Twitter, для перехода к использованию исключительно.

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

Это распространенный миф о TLS. Даже для публичных данных рассмотрите последствия:

• Любой посредник может вводить собственные запросы и ответы. Это может быть мусор, злой, тонко неправильный, что угодно. Безопасная связь заключается не только в том, чтобы сохранить конфиденциальность контента, но и для поддержания ее целостности. (Обычный пример - это телекоммуникации и гостиницы, которые вводят объявления на веб-сайты.)
• Данные могут быть общедоступными, но трафик все еще может быть чувствительным. Что делать, если вы могли контролировать запросы Википедии Apple? Было бы интересно, если бы возникла проблема в запросах на статьи, связанные с автомобилем? Без TLS посредники могут отслеживать запросы, которые пользователь делает.

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

Answer 2

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

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

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

И наконец, я согласен с @mahemoff, что TLS становится повсеместным и very cheap. На самом деле, в зависимости от обстоятельств, HTTPS may outperform HTTP.