Содержание
Такое ощущение, что каждый раз, когда вы подписываетесь на новую услугу, вы можете выбрать имя пользователя и пароль или просто войти в систему с Facebook или Twitter. Вход в систему с вашей учетной записью Google также часто вариант. Это быстро и легко. Но стоит ли это делать?
Как это работает?
При входе в систему с использованием социальной учетной записи используется протокол под названием OAuth, который (в двух словах) позволяет одному приложению или услуге (запрашивающей стороне или услуге, на которую вы подписываетесь) подключаться к другому (поставщику услуг или существующей сети, которую вы используете). использовать для регистрации) и действовать от вашего имени. Это делается путем выдачи «токенов» запрашивающему приложению. Эти токены работают так же, как ваше имя пользователя и пароль, поскольку они предоставляют запрашивающему приложению доступ к защищенной паролем службе (например, Facebook).
Здесь важно то, что ваше действительное имя пользователя и пароль никогда не передаются между приложениями, а запрашивающее приложение получает доступ только к ограниченной части вашей защищенной паролем учетной записи.
Давайте посмотрим на быстрый пример. Допустим, вы используете Blurb, чтобы превратить свои фотографии на Facebook в книгу
, Вы идете в Blurb (запрашивающая сторона) и говорите, что хотите распечатать фотографии из Facebook. Blurb направляет вас обратно в Facebook (поставщик услуг), где вы вводите свои учетные данные для входа (отправленные непосредственно в Facebook, а не в Blurb) и сообщаете Facebook, что вы даете Blurb разрешение на доступ к вашим фотографиям. Теперь Blurb может загрузить эти фотографии, чтобы их можно было распечатать. Если Blurb попытается получить доступ к вашей временной шкале, ему будет отказано, поскольку имеющийся у него токен дает ему доступ только к вашим фотографиям и общедоступному профилю.
OAuth никогда не передает ваше имя пользователя или пароль запрашивающему приложению, идея состоит в том, что сохранение вашего имени пользователя и пароля в секрете обеспечивает их безопасность. И чтобы запретить запрашивающему приложению или службе доступ к вашей учетной записи, все что вам нужно сделать, это нажать «отозвать доступ», а не менять свой пароль.
Это безопасно?
Итак, процесс пока выглядит довольно простым. Но насколько это безопасно? Должны ли мы беспокоиться о безопасности сайтов OAuth?
С точки зрения безопасности OAuth выглядит довольно хорошо. Наихудший сценарий по-прежнему не приводит к раскрытию ваших социальных паролей. А возможность мгновенного аннулирования доступа к любому приложению, имеющему токен, означает, что даже если веб-сайт будет взломан и некоторые гнусные персонажи получат в свои руки все данные токена, вы можете просто нажать кнопку отзыва доступа, и у них не будет доступ к вашему социальному сайту.
Тот факт, что вы предоставляете доступ только к определенному подмножеству данных на своем социальном сайте, также весьма привлекателен: если кто-то взламывает Snapfish и получает доступ к вашим фотографиям на Facebook, вам не следует беспокоиться (вы заботитесь о фотографиях) Вы отправляете, правильно?).
Несмотря на недавнее драматическое обнаружение недостатка безопасности в OAuth, система довольно хорошая.
Однако безопасность в Интернете — это не только шифрование и токены. Один из лучших способов убедиться, что вы в безопасности в сети, — это использовать хорошие методы паролей. И OAuth очень помогает в этом. Как? Чтобы войти в систему с помощью Twitter или Google, вам не нужно создавать еще один пароль, который вы должны запомнить. Если у вас есть очень надежный пароль Facebook, вы можете использовать его для доступа к нескольким вещам, не используя тот же пароль для других сайтов.
Это явное преимущество OAuth, и тот факт, что вы ограничиваете количество веб-сайтов с паролями, является большим плюсом.
Также важно упомянуть, что сайты, имеющие доступ к вашим социальным профилям, не могут предпринимать каких-либо серьезных действий — они не могут удалить вашу учетную запись, изменить пароль или внести другие существенные изменения. Что обнадеживает.
Какие риски вы принимаете?
К сожалению, нет ничего проще, когда дело доходит до онлайн-безопасности. Существуют некоторые риски использования OAuth, в основном связанные с конфиденциальностью.
Например, как часто вы уделяете время тому, чтобы по-настоящему взглянуть на разрешения, которые вы предоставляете при использовании Facebook Connect? В то время как приложения должны запрашивать доступ только к той информации, которая им нужна для лучшего обслуживания, они часто запрашивают гораздо больше — например, график времени, информацию о ваших друзьях и возможность публикации.
Иногда это хорошо — вы можете захотеть интегрировать Twitter в приложение контактов или программу чтения новостей. Или вы можете опубликовать результаты тренировок из RunKeeper
или MapMyFitness. Но в разрешениях нет ничего, что помешало бы приложению или службе публиковать то, что они хотят. Опция «только результаты опроса» отсутствует. Вы просто должны верить, что приложение будет публиковать только то, что вы хотите или сказать, а не рекламу.
И вы можете выдавать больше информации, чем рассчитывали. Кого волнует, видит ли ваш любимый магазин то, что вы публикуете на Facebook, верно? Ну, они могут получить больше информации, чем вы себе представляли.
Например, на конференции 2012 года японская каталожная компания рассказала о том, как она использовала информацию в профиле пользователя Facebook, чтобы делать выводы «о« жизненном этапе »клиента (будь он женат или не женат, беременен, соблюдает диету, планирует вечеринку). и т. д.) «домашнее хозяйство» (если у них есть ребенок, пожилой родитель, домашнее животное, квартира и т. д.) и «личность» (занимаются ли они волонтерством, гаданием, едой, путешествиями, спортом, бегом и т. д. ?) «.
Член маркетинговой команды заявил, что команда «может узнать историю жизни наших клиентов — их образ жизни и психологию. Затем мы можем настроить таргетинг на наши каталоги. И мы можем предсказать, когда кому-то понадобится продукт, основываясь на том, что они говорят в социальных сетях ».
Не думали ли вы, что вы выдавали столько информации, не так ли?
Конечно, вы имеете полный контроль над тем, что вы делитесь с компанией, используя социальные учетные записи и сколько они могут опубликовать для вас, но только если вы потратите время на чтение разрешений, которые они запрашивают. И не предоставляйте доступ к вещам, которые вы предпочитаете держать в секрете. Но это не всегда легко, потому что некоторые приложения и сервисы теперь используют вход только через Facebook или Twitter, а это означает, что если вы не согласны с их разрешениями, вы не сможете пользоваться сервисом.
Уроки на вынос: что делать?
Как и в большинстве случаев, у входа в систему с использованием социальных учетных записей есть две стороны. Как правило, это довольно безопасно, и вы на самом деле имеете достаточный контроль над тем, как много информации вы делитесь.
С другой стороны, вы можете потерять много контроля, если не будете осторожны. Так что же с этим делать?
- Прочитайте запросы на разрешение, прежде чем предоставлять их.
Это важный вопрос, и он будет становиться все важнее по мере того, как веб-службы станут более интегрированными. Если вы не хотите, чтобы приложение собирало данные о ваших друзьях на Facebook, не разрешайте ему доступ к Facebook.
- Регулярно просматривайте разрешения вашего приложения.
В Facebook перейдите на вкладку «Приложения» на экране «Настройки». В Twitter также перейдите на вкладку «Приложения» в настройках. Google немного сложнее: перейдите на account.google.com, затем нажмите «Безопасность», а затем «Просмотреть все» в разделе «Права учетной записи». Посмотрите, какие приложения имеют доступ к вашим данным, и отзовите доступ для тех, которые вы больше не используете. И если вы видите приложение, которое имеет больше разрешений, чем должно, рассмотрите возможность отзыва доступа и посмотрите, сможете ли вы войти в эту службу с традиционным именем пользователя и паролем.
Чтобы ускорить процесс, вы можете использовать MyPermissions
, который помогает вам управлять своими разрешениями через Facebook, Twitter, Google, Yahoo, LinkedIn, Foursquare, Instagram, Dropbox и многое другое.
- Пропустить разрешения и установить допустимые аудитории для обмена.
Если приложение запрашивает разрешение на публикацию от вашего имени через социальную службу, у вас может быть возможность не давать это разрешение (вы увидите это на Facebook, когда увидите кнопку «Пропустить»). Если это вариант, используйте его! Вы также можете установить аудиторию для допустимого обмена — например, вы можете поделиться со всеми своими друзьями, пользовательской аудиторией или только с собой.
- Относитесь к запросам разрешений по-разному в зависимости от учетных записей.
Что вы публикуете в Instagram? Что вы публикуете в Twitter? Запрос на чтение ваших сообщений в Foursquare может быть намного менее пугающим, чем предоставление привилегий «Составлять и отправлять новую почту» вашей учетной записи Gmail.
- Меняйте свои пароли на регулярной основе.
Когда вы меняете свои пароли, несколько токенов OAuth будут немедленно аннулированы, что потребует от вас повторной регистрации и повторного утверждения токенов. Насколько мне удалось выяснить, Gmail и Facebook делают недействительными токены, когда вы меняете пароль, а Twitter и Google+ этого не делают. Для этих других служб вам необходимо отозвать доступ, а затем повторно выдать разрешения.
Вывод: удобство за цену
Вход на сайты и в сервисы с вашими социальными учетными данными добавляет много удобства и даже немного безопасности. Но это может быть рискованно как с точки зрения конфиденциальности, так и, в меньшей степени, с точки зрения безопасности. Но если вы будете практиковать пять советов по безопасности, приведенных выше, вы должны давать только те разрешения, которые вы намереваетесь.
Как часто вы используете вашу социальную регистрационную информацию на другом сайте? Вы чувствуете себя в безопасности, делая это? Вы регулярно читаете и проверяете разрешения? Поделитесь своими мыслями ниже!
Изображения предоставлены: Марк Фалардо через Flickr, Роб Понгсаджапан через Flickr, Иван Меленчон Серрано через MorgueFile
