Часто используемые решения для кэширования учетных данных? - PullRequest
1 голос
/ 25 июня 2011

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

У меня такой вопрос:

Допустим, я создаю какой-то простой клиент Twitter.Я не хочу заставлять пользователя каждый раз вводить свой пароль.Как большинство приложений решают эту проблему?В какой-то момент клиент должен сделать вызов API для аутентификации (который включает в себя пароль, который обычно находится в виде простого текста).Однако сохранение пароля в виде обычного текста где-то не является правильным решением, очевидно.Итак, как большинство приложений делают это безопасно?Я полагаю, вы могли бы кэшировать пароль в файле или в БД, если пароль зашифрован, но тогда как безопасно хранить ключ дешифрования?Или он генерируется во время выполнения с использованием уникальной информации с клиентского компьютера в качестве начального числа?

Есть ли какие-либо ресурсы (статьи, книги и т. Д.), Которые говорят об этом?Как большинство приложений справляются с этим?

Спасибо!

1 Ответ

0 голосов
/ 25 июня 2011

Установки единого входа (SSO) обычно выполняют то, что вы описываете, предоставляя централизованные методы для генерации, распространения и проверки ключа с использованием идентификатора сеанса определенного типа.

См. Один метод (используется StackExchange / StackOverflow ):

http://openid.org/

Вот кое-что, чего я не знал: Эта категория функций известна как Федеративная идентификация .Например, наша веб-система, в которой я работаю, предлагает (но не требует) Shibboleth .Смотрите здесь список опций:

http://en.wikipedia.org/wiki/Category:Federated_identity

...