Как хранить ключ пользователя и секретный ключ OAuth v1 для клиента Twitter с открытым исходным кодом, не раскрывая его пользователю?

Я хочу сделать клиент с толстым клиентом, рабочим столом, открытым исходным кодом. Я использую .NET как мой язык и Twitterizer как свою обертку OAuth /Twitter, и мое приложение, скорее всего, будет выпущено как с открытым исходным кодом .

Чтобы получить токен OAuth, требуется четыре части информации:

  1. Ток доступа (имя пользователя twitter)
  2. Access Secret (пароль для twitter)
  3. Потребительский ключ
  4. Секрет потребителя

Вторая часть информации не должна быть разделена, например, закрытый ключ PGP. Однако из-за того, что поток авторизации OAuth спроектирован, они должны находиться в родном приложении. Даже если приложение не было открытым исходным кодом, а ключ /секрет потребителя был зашифрован, разумно опытный пользователь мог получить доступ к ключам пользователя /секретной паре.

Итак, мой вопрос: как мне обойти эту проблему? Какова правильная стратегия для клиентского компьютера Twitter для защиты своего ключа и секретности от пользователя?

30 голосов | спросил Justin Dearing 8 AM00000050000005131 2011, 05:24:51

5 ответов


4

Я нашел ответ, который отражает путь, который я рассматривал, опустившись на hueniverse . В статье Помимо потока перенаправления OAuth Web , предлагает некоторые предложения, один из которых является веб-адресом, который проксирует процесс обмена токенами. Я должен разработать способ правильно аутентифицировать, что мое приложение - это то, что запрашивает аутентификацию на этой странице прокси. Однако это возможно.

ответил Justin Dearing 11 AM00000050000005631 2011, 05:32:56
2

Возможно, я ошибаюсь, но если вы связываете ключи с настольным или мобильным приложением, с открытым исходным кодом или нет, можно получить к ним доступ. Если такие сервисы, как Twitter и Tumblr, заставляют нас использовать API только для OAuth, у нас есть два варианта:

  • настроить службу auth proxy для каждого приложения
  • связывать ключи с приложением

Первый из них более сложный и дорогостоящий, не обязательно поддерживаемый для небольших приложений с открытым исходным кодом. Последнее означает, что приложение может и будет заблокировано, как только спамеры украдут ключи. Поскольку Twitter и Tumblr пока не дают лучшего варианта, и открутите все настольные клиенты, клиенты с открытым исходным кодом включительно, есть предложение

ответил sastanin 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 12 Sep 2012 15:42:35 +0400 2012, 15:42:35
1

Раздел 4.6 RFC 5849 , который определяет OAuth 1, указывает, что потребительская тайна никогда не предназначалась для использования потребителями настольных компьютеров, несмотря на то, что использование Твиттера на практике. Как указал Нельсон Эльхадж в « Дорогой Twitter », Twitter может и заканчивается потребительские ключи настольных клиентов, при условии, что клиент не слишком велик, чтобы потерпеть неудачу. Но есть два способа обхода, которые позволяют использовать OAuth 1 в настольном или мобильном приложении.

Один из способов - проксировать весь протокол Twitter через сервер, на котором вы работаете. Таким образом, потребительский секрет остается на вашем сервере. Это обходной путь, рекомендованный Диком Хардтом , редактором спецификации OAuth 1. Это обходное решение не учитывает стоимость работы этого сервера.

Другой способ, предложенный в сообщении от Raffi Krikorian в Twitter сообщают группу Google и от Chris Steipp в список рассылки Wikipedia, заключается в том, чтобы« каждый пользователь регистрировал свою копию своего настольного приложения как своего собственного потребителя ». Затем пользователь будет копировать и вставлять вновь зарегистрированный потребительский ключ и секрет пользователя в ваше приложение. В руководстве для вашего приложения будет необходимо включить подробные инструкции о регистрации нового приложения на сайте разработчика Twitter. Это официальное ограничение имеет несколько практических проблем:

  • Ваш клиент столкнется с недостатком удобства использования по сравнению с известными собственными клиентами.
  • Форма для создания нового приложения , похоже, не предлагает способ предварительной настройки, заполните необходимые поля. Это означает, что вам нужно будет обновить прохождение регистрации в своем руководстве, когда Twitter изменит процедуру регистрации приложения.
  • В соглашении с разработчиком требуется, чтобы пользователи имели совершеннолетний возраст, чтобы заключить обязательный контракт. Это означает, что пользователь вашего приложения в возрасте от 13 до 17 лет должен иметь родителя, принимающего соглашение от имени пользователя.
  • Политика разработчиков запрещает массовые регистрации приложений и "имя приседания", что определяет как «отправка нескольких приложений с той же функцией под разными именами». Я не знаю о прецеденте относительно того, обращался ли Twitter с несвязанными пользователями, которые зарегистрировали отдельные экземпляры одного приложения как «сквоттеры имен».
ответил Damian Yerrick 12 J0000006Europe/Moscow 2015, 21:49:29
-2

Я собираюсь ответить, но буду предупрежден, что я сам с этим не занимался, я ухожу от лучших практик и существующего соответствующего опыта;

Я не стал бы слишком беспокоиться об этом. Если ваш клиент является открытым исходным кодом, у них все равно будет доступ к источнику, и попытка контролировать то, что они делают с вашей программой, в любом случае идет вразрез с природой open source (хотя важно то, что вы пытаетесь сделать . не ).

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

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

Полное раскрытие информации, я не знаком с API Twitters, API twitterizer, требованиями oauth или чем-либо еще, что я сказал, что звучит сомнительно;)

ответил Damian Yerrick 12 J0000006Europe/Moscow 2015, 21:49:29
-4

Ключ и секрет потребителя привязаны к приложениям, а не связаны с пользователем. С этим в формировании поставщик OAuth знает, с какими приложениями он справляется. Остальные, токен доступа и секрет будут получены после выполнения первых шагов.

См. этот пост в блоге для получения более подробной информации. как показывает, как работает протокол.

ответил Yblih 31 PM000000100000002231 2011, 22:40:22

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132