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

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

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

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

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

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

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

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

Источник

4 ответа

Решение

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

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

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

Источник

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

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

Источник

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

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

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

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

Источник

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

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

Источник
Другие вопросы по тегам