OAuth и уязвимости фишинга, разве они непреклонно связаны?
Я делал маленькую работу с OAuth недавно, и я должен сказать, что мне действительно нравится он. Мне нравится понятие, и мне нравится, как оно предоставляет низкую входную планку Вашим пользователям для соединения внешних данных с сайтом (или чтобы Вы обеспечили пчелу данных для потребления внешне). Лично, я всегда передумал относительно сайтов, которые просят, чтобы я обеспечил свой вход в систему для другого веб-сайта им непосредственно. И OAuth "ключ камердинера для веб-" подхода решает это приятно.
Самая большая проблема I (и многие другие) видит с ним, хотя, стандартный рабочий процесс OAuth, поощряет тот же тип поведений, которые фишинговые атаки используют для своего преимущества. При обучении пользователя, что это - нормальное поведение, которое будет перенаправлено на сайт для обеспечения данных для входа в систему, то для сайта фишинга легко использовать то нормальное поведение, но вместо этого перенаправить на их сайт клона, где они получают имя пользователя и пароль.
Что, во всяком случае, Вы сделали (или видели сделанный) облегчить эту проблему?
Вы говорите пользователям идти и входить в обеспечивающий сайт вручную без автоматических ссылок или перенаправления? (но затем это увеличивает входную планку),
Вы пытаетесь обучить своих пользователей, и если так, когда и как? Любое долгое объяснение безопасности, что пользователь должен читать также, увеличивает входную планку.
Что еще?
3 ответа
Я считаю, что OAUth и фишинг они неумолимо связаны, по крайней мере, в нынешней форме OAuth. Существовали системы, предотвращающие фишинг, в большинстве случаев - HTTP (пауза для смеха...), но, очевидно, это не работает.
Фишинг - очень успешная атака на системы, требующие комбинации имени пользователя/пароля. Пока люди используют имена пользователей и пароли для аутентификации, фишинг всегда будет проблемой. Лучшей системой является использование асимметричной криптографии для аутентификации. Все современные браузеры имеют встроенную поддержку смарт-карт. Нельзя подделать карту, сидящую в чьем-то кошельке, и взлом рабочего стола пользователя не приведет к утечке личного ключа. Асимметричная пара ключей не обязательно должна быть на смарт-карте, но я думаю, что она строит более сильную систему, чем если бы она была реализована исключительно в программном обеспечении.
Это не просто проблема ОАУТ, а также проблема OpenID. Хуже того, конечно, с OpenID вы даете веб-сайту вашего провайдера, легко автоматически соскрести этот сайт, если у вас уже нет божемого и генерировать тот, который вы тогда направляете своего пользователя.
Счастливое, что ничего серьезного использует OpenID для аутентификации - Сообщения в блоге Flickr Comments просто не сочная цель.
Теперь OpenID ездит куда-то, чтобы смягчить, когда они начинают разрабатывать поддержку своей информационной карты, где фиксированная пользовательская интернет-интерфейс в форме программного обеспечения для клиента обеспечит идентичность «кошелек», который является безопасным, но MS, по-видимому, отбросил мяч Сами на информационных карточках, хотя это их (открытый) спецификация.
Это не уходит в ближайшее время.
Расширить аналогию с парковщиком: откуда вы знаете, что можете доверять парковщику, и что он не просто кто-то примеряет? На самом деле это не так: вы просто делаете это (возможно, без сознания) суждение, основанное на контексте: вы знаете отель, вы там раньше были добры, вы даже можете узнать человека, которому даете ключ.
Точно так же, когда вы входите в систему, используя OAuth (или OpenID), вы перенаправляете пользователя на сайт/URL, который должен быть ему знаком, поскольку он предоставляет свои учетные данные с того сайта, который ему известен.