Безопасный способ хранения паролей к API без OpenID? - PullRequest
Новая
       22

Безопасный способ хранения паролей к API без OpenID?

1 голос
/ 20 апреля 2010

Я задал подобный вопрос здесь некоторое время назад, но все ответы предлагали OpenID, который хорош, но он не работает со службами, которые требуют аутентификации, которые не используют его (например, EventBrite) .

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

Некоторые возможные решения:

  1. Храните учетные данные в YAML , как это . Легко взламывается.
  2. Пусть пользователь вводит учетные данные в форму на моем сайте, я сохраняю учетные данные в своей базе данных и использую их для входа в EventBrite. Легко взламывается.
  3. Пусть пользователь вводит учетные данные, и я передаю их непосредственно в EventBrite без сохранения, и я сохраняю заголовок ответа Cookies в базе данных, и по истечении этого срока он снова входит в систему. Это легко взломать?

Этот гипотетический сервис также хочет автоматически проверять события (скажем, через cron), поэтому он не зависит от того, заходит ли пользователь на мой сайт через браузер. Поэтому куки или кредиты должны храниться где-то.

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

Что это за путь? Что мне не хватает? Можно ли пойти с № 3 и сохранить куки (но все же нужно, чтобы пользователь отправил свой адрес электронной почты / пароль через форму, которую я отправляю на Eventbrite)? Что является приемлемым решением проблемы?

Ответы [ 4 ]

1 голос
/ 04 февраля 2012

Eventbrite недавно выпустил новую документацию, описывающую , как реализовать OAuth2.0 для межсайтовой аутентификации пользователей . Я бы порекомендовал использовать наш основанный на javascipt виджет OAuth2.0 , который по умолчанию хранит токены аутентификации пользователя в localStorage их браузера. Поскольку токены авторизации хранятся в браузере пользователя и не имеют доступа к другим доменам, маловероятно, что будут какие-либо утечки безопасности.

В этой схеме аутентификации полностью отсутствует необходимость в комбинациях электронной почты и паролей.

1 голос
/ 20 апреля 2010

Нет безопасного способа сделать это. Вы можете использовать обходные пути, но это все.

  1. Запрещено хранить пароли в YAML или XML в открытом тексте
  2. На самом деле, даже шифрование и хранение паролей неверно. Вашему приложению потребуется способ расшифровки паролей, поэтому злоумышленник также может расшифровать пароли.
  3. Рекомендованный способ хранения паролей - Salt + Hash, но, поскольку он становится невосстановимым, он бесполезен в вашем случае.
  4. Из-за 2 и 3, независимо от того, где вы храните учетные данные пользователей, вы уязвимы.
  5. Лучше хранить файлы cookie вместо паролей. Но опять же, это касается пароля, проходящего через ваш сайт, что не очень хорошо.

Учитывая вашу ситуацию, хранение cookie - лучший подход. Используйте HTTPS везде, даже на вашем сайте. Хотя это не идеально, и вы и ваши пользователи должны знать об этом.

0 голосов
/ 15 мая 2011

Для работы с API Eventbrite, я бы порекомендовал убедиться, что все соединения по SSL и что вы проходите аутентификацию, используя user_key, а не имя пользователя и пароль.

Более подробная информация об аутентификации для API Eventbrite здесь: http://developer.eventbrite.com/doc/auth/

После входа в систему пользователи могут найти свой user_key здесь: http://www.eventbrite.com/userkeyapi

Это должно предотвратить перехват данных имени пользователя и пароля по проводам или чтение из локального хранилища данных.

0 голосов
/ 20 апреля 2010

Большинство сайтов поддерживают только прямой вход с оригинальным паролем в виде открытого текста, поэтому вы должны также получить, сохранить и предоставить его. И я бы никогда не поверил тебе в этом. Проблема вашей концепции в том, что вы требуете, чтобы пароль был передан третьей стороне. Решение заключается не в том, чтобы привлекать третье лицо, например, мой браузер довольно хорошо умеет автоматически хранить и заполнять пароли (мой жесткий диск тоже защищен паролем). И это десятки других приложений кошелька паролей тоже. Я бы ничего не получил, подписавшись, используя ваш сервис.

Прежде чем идти в такой бизнес, подумайте, что вы будете целью № 1. Facebook, Google невероятно параноидально относятся к безопасности, тратя много времени, денег и усилий, чтобы сохранить логины в безопасности. У вас есть такие же ресурсы? Тогда вы лучшая цель. Также, взломав ваш сервис, они сразу же получают несколько учетных записей, пароли ваших пользователей, а также видят, кто всегда использует его пароль.

...