☰

Почему oAuth более безопасен?

tag-icon • tag-icon security oauth2
Почему oAuth более безопасен?

Многие сервисы, например почта IMAP от Google, перешли от аутентификации по идентификатору пользователя и паролю к использованию oAuth.

Почему oAuth более безопасен, помимо того, что это услуга, предоставляемая крупной и хорошо обеспеченной компанией, имеющей больше ресурсов для мониторинга?

решение1

Технические преимущества:

  • Поскольку часть OAuth «первоначальная аутентификация» выполняется через веб-сайт, он может запросить другие факторы аутентификации, а не только пароль. Например, он может запросить одноразовый код TOTP или ключ U2F. (Он также может иметь reCAPTCHA, если необходимо.)

    • Обычно это также означает, что вводимый вами пароль виден только веб-браузеру — почтовое приложение его никогда не видит.

      В настоящее время Google, в частности, более агрессивно относится к предотвращению загрузки страницы аутентификации во «встроенных» браузерах, которые могут раскрыть пароль хостовой программе. (Старые версии GNOME делали это полулегально, поскольку им требовалось использовать определенные API Google, которые в то время еще не поддерживали OAuth2.)

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

      (Сравните с SSH, в котором есть метод аутентификации «KeyboardInteractive», который может отображать несколько подсказок с пользовательским текстом — работает нормально для базового пароля + OTP или пары ключей + OTP, но в целом довольно неуклюж, когда дело доходит до 2FA. Многие корпорации фактически внедряют системы, которые используют кратковременные пары ключей SSH, способом, очень похожим на токены OAuth2 или билеты Kerberos — вы проходите аутентификацию через корпоративный сайт SSO, чтобы получить ключ SSH на день.)

  • Токен, выданный вашему почтовому клиенту, имеет доступ только к определенным службам (областям действия), в данном случае IMAP и SMTP — например, его нельзя использовать для доступа к файлам на Диске или истории YouTube.

    • Хотя это может привести к злоупотреблениям со стороны поставщика услуг (например, Google может потребовать дорогостоящую «верификацию» для приложений OAuth2, имеющих более 100 пользователей и желающих получить доступ к почтовым областям).

    • «Пароли приложений», созданные вручнуюмогтакже может быть ограничена определенными службами, но очень немногие будут использовать эту функцию эффективно — например, это возможно с токенами доступа GitHub, но требуется слишком много умственных усилий, чтобы определить (часто методом проб и ошибок), какие области нужны для того или иного приложения, поэтому будет сгенерировано много токенов со всеми возможными включенными областями...

Для поставщика услуг существуют также некоторые преимущества «глубокой защиты»:

  • Фактический сервис никогда не получает ваш фактический пароль (и даже токен обновления — только кратковременный токен доступа), поэтому даже если один сервис скомпрометирован, он не может собирать учетные данные для доступа к другим сервисам («боковое перемещение»?).

    • Это очень похоже на использование билетов Kerberos в Active Directory или утверждений SAML в корпоративных системах единого входа.

      Во всех таких системах вместо всех служб, которым требуется доступ к базе данных пользователей (и все они являются ценными целями), в привилегированном положении остаются только KDC или IdP.

решение2

Я вижу по крайней мере несколько возможных положительных моментов.

  1. Это снижает вероятность повторного использования пароля. Чем больше мест вы вводите пароль, тем выше вероятность критической утечки, и если вы повторно используете пароли, то другие сайты также подвергаются риску.
  2. Он предоставляет центральный орган, способный быстро отзывать доступ к большому количеству сайтов за один раз. Поскольку сайты получают только «токен доступа» от Google, они все могут быть уникальными и отзываться по отдельности или все сразу.
  3. Он скрывает необходимость для сайтов обрабатывать смену паролей и безопасно хранить пароли. Если они никогда не получают пароль, то они не могут хранить его в открытом виде, некоторые сайты делали это или, возможно, делают до сих пор.
    Онидолженпо-прежнему безопасно обрабатывать токен, но это более простой процесс в случае взлома. Сообщите поставщику OAuth о взломе, и они отзовут ваш токен, пока вы не получите новый при следующей аутентификации пользователя.

Конечно, требуется безопасность вашего провайдера OAuth, но сбросить пароль в одном месте все равно гораздо проще, чем делать это на 50 или 500 сайтах.

Связанный контент