OAuth и фишинговые уязвимости, они неумолимо связаны?

Question

Я недавно довольно много работал с OAuth, и должен сказать, что мне это действительно нравится. Мне нравится концепция, и мне нравится, как она обеспечивает низкий уровень входа для ваших пользователей для подключения внешних данных к вашему сайту (или для вас, чтобы обеспечить данные API для потребления извне). Лично я всегда заходил на сайты, которые просили меня предоставить им логин для другого сайта напрямую. Подход OAuth "ключ от сети" решает эту проблему.

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

Что вы сделали (или видели, что сделали), чтобы облегчить эту проблему?

• Вы говорите пользователям, чтобы они заходили и заходили на сайт предоставления вручную, без автоматических ссылок или перенаправления? (но тогда это увеличивает барьер входа)

• Вы пытаетесь обучить своих пользователей, и если да, то когда и как? Любое длинное объяснение безопасности, которое должен прочитать пользователь, также увеличивает барьер входа.

Что еще?

Answer 1

Я считаю, что OAUth и фишинг неразрывно связаны, по крайней мере, в нынешней форме OAuth. Существуют системы для предотвращения фишинга, наиболее заметные HTTP (пауза для смеха ...), но, очевидно, это не работает.

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

Answer 2

Есть несколько методов, которые можно использовать, чтобы избежать или уменьшить фишинговые атаки.Я сделал список дешевых вариантов:

1. Взаимная идентификация ресурсов.Значок Ex, связанный с конкретным пользователем, отображается только после ввода пользователем его имени.
2. Использование имен пользователей, не являющихся детерминированными, и избегать использования электронных писем в качестве имен пользователей.
3. Включите параметр, позволяющий пользователю просматривать свою историю входа в систему.
4. QRCode, который позволяет выполнять аутентификацию в устройстве, предварительно зарегистрированном, например, в смартфонах.Как WhatsApp Web.
5. Показывать номера аутентификации на страницах входа, которые пользователь может проверить на официальном сайте компании.

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

Answer 3

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

Как правило, страница входа должна предоставлять пользователю удобные общие секреты для подтверждения личности сайта, на который они входят.

Как отмечает Jingle, для аутентификации можно использовать ssl-сертификат, но в этом случае пользователь не может загрузить сертификат непосредственно с сайта в свой веб-браузер как часть процесса установки OAuth? Если с сайтом уже установлены доверительные отношения, я не уверен, что дальнейшее обращение к ЦС необходимо.

Answer 4

Как насчет сертификации провайдера oAuth, как и сертификации ssl? Только сертифицированный oAuth-провайдер заслуживает доверия. Но проблема, как и в случае с сертификацией ssl, имеет значение CA.

Answer 5

Это не только проблема OAuth, но и проблема OpenID. Хуже того, с OpenID вы предоставляете веб-сайт своему провайдеру, легко автоматически очистить этот сайт, если у вас его еще нет, и сгенерировать тот, который вы затем направите своему пользователю.

К счастью, ничто серьезное не использует OpenID для аутентификации - посты в блогах, комментарии flickr просто не сочная цель.

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

Это не исчезнет в ближайшее время.

Answer 6

В продолжение аналогии с камердинером: откуда ты знаешь, что можешь доверять камердинеру, и что он / она - не просто кто-то, кто его примеряет? На самом деле вы этого не делаете: вы просто делаете это (возможно, бессознательное) суждение на основе контекста: вы знаете отель, вы уже были там раньше, вы можете даже узнать человека, которому вы даете свой ключ.

Таким же образом, когда вы входите с помощью OAuth (или OpenID), вы перенаправляете пользователя на сайт / URL, который должен быть им знаком, поскольку они предоставляют свои учетные данные с того сайта, который известен им.