OAuth 2.0 Bearer-токены против Mac-токенов. Почему не использовать Mac-токены?
Я искал другие вопросы в этой теме, но не нашел ответа на именно этот. Так скажи мне, если я ошибаюсь. Я новичок в этой теме и вы можете меня поправить, с удовольствием. Вот что я думаю в настоящий момент:
Я бродил по сети в течение 2 дней, выясняя, каково фактическое состояние техники для авторизации webrequest. Теперь я быстро понял, что OAuth 2.0 кажется самым распространенным стандартом. Но сам OAuth 2.0-это все, кроме стандартизированный. Из моих глаз это беспорядок различных настроек для каждой большой компании. Но в любом случае есть два метода обмена информацией об авторизации: Mac-токены и токены на предъявителя.
на мой взгляд, Mac-токены обеспечивают большую безопасность. Так почему же она не реализуется широко? Единственная причина, по которой я мог найти, потому что это немного сложнее. И я слышал несколько раз, что Mac-токены не рекомендуются, если клиенту не доверяют на 100%, потому что клиент должен хранить секрет. Но в чем разница? Клиент должен в любом случае сохранить Authorazation-информация. По-моему это не важно wheter его носитель-токен или Mac-секрет. Но что!--5-->разница это mac-secret (а не носитель-токен) не передается по проводу по каждому запросу.
Итак, можете ли вы сказать мне разумную причину, почему не использовать Mac-токены? (помимо того, что немного больше усилий) Я чего-то не хватает? Или я missunderstood двух методов маркер.
Спасибо за чтение и помощь.
3 ответов
опасность заключается в том, что если клиент продолжает, не настаивая на действительном сертификате SSL/TLS, что является шагом, который многие клиенты не в состоянии принять, то маркер носителя восприимчив к человеку в середине атаки.
маркер Mac не подвержен этой атаке; может быть правильно сказать, что маркер Mac обеспечивает некоторую аутентичность в отсутствие SSL/TLS или действительно, когда он не используется правильно.
маркер Mac усиливает известную слабость о знаке носителя.
клиенту не следует доверять ключ MAC, который является общим. Для каждого клиента должен быть создан новый ключ. Доверять каждому клиенту свой собственный ключ не более опасно, чем доверять ему токены на предъявителя.
Я думаю, что проблема возникает при обмене Гранта Auhtorization на токен доступа. Для ключа Mac это возвращает симметричный секретный ключ. Если клиент небрежно проверяет сертификаты SSL/TLS, то это тоже восприимчив к атаке MITM.
короче говоря, маркер Mac может быть менее предпочтительным, потому что он более сложный, но вам все равно нужно сделать SSL/TLS правильно, чтобы сделать его безопасным, и если вы это сделаете, то маркер носителя также будет безопасным.
на мой взгляд, ответ может быть простым: механизм токена на предъявителя предполагает наличие уровня SSL/TLS, тогда как токен MAC пытается его заменить. Поскольку SSL / TLS широко принят и используется, почему делать вещи сложнее, чем нужно?
да, как недавно было замечено с уязвимостью heartbleed, многие вещи на самом деле не так надежны, как ожидалось, но кто гарантирует, что реализация MAC также свободна от сбоев?
другой момент, как вы упомянули, обмен симметричными секретами. При отсутствии абсолютно надежного вторичного канала это может быть сложно. И доверие клиенту также может быть проблемой.
Если SSL / TLS использовался правильно, а учетные данные клиента, выдаваемые конфиденциальным и самообслуживанием, не имеют преимуществ для принятия MAC вместо токенов на предъявителя. Только добавляет сложности. Клиент несет ответственность за сохранение конфиденциальности секрет клиента. Конечно, есть клиенты, которые предпочитают использовать мышление MAC, которые улучшают безопасность.