Является ли маркер devise аутентифицируемым безопасным?

Я создаю простой api с Rails API, и хотите убедиться, что я на правильном пути здесь. Я использую devise для обработки Логинов, и решил пойти с Devise token_authenticatable опция, которая генерирует ключ API, который вам нужно отправить с каждым запросом.

я соединяю API с интерфейсом backbone / marionette и обычно задаюсь вопросом, как я должен обрабатывать сеансы. Моя первая мысль заключалась в том, чтобы просто сохранить ключ api в локальном хранилище или cookie и получить его при загрузке страницы, но что-то о хранении ключа api таким образом беспокоило меня с точки зрения безопасности. Не было бы легко захватить ключ api, либо заглянув в локальное хранилище / cookie, либо обнюхав любой запрос, который проходит, и использовать его для олицетворения этого пользователя на неопределенный срок? В настоящее время я сбрасываю ключ api для каждого входа в систему, но даже это кажется частым - каждый раз, когда вы входите на любое устройство, это означает, что вы выйдете из системы на каждом другом, что является своего рода болью. Если бы я мог бросить это сброс я чувствую, что это улучшится с точки зрения удобства использования.

Я могу быть совершенно неправ здесь (и надеюсь, что я), может ли кто-нибудь объяснить, является ли аутентификация таким образом надежно защищенной, и если нет, то какой хорошей альтернативой будет? В целом, я ищу способ, которым я могу безопасно держать пользователей "вошедшими" в доступ к API без частого принудительного повторного аутентификации.

3 69
ruby-on-rails api forms-authentication devise rails-api

3 ответа:

token_authenticatable уязвим для временных атак, которые очень хорошо объяснены в этот блог. Эти нападения были причиной token_authenticatable был отстранен от разработки 3.1. Смотрите plataformatec сообщение в блоге для получения дополнительной информации.

чтобы иметь самый безопасный механизм аутентификации токена, Токен:

  1. должен быть отправлен через HTTPS.

  2. должно быть случайным, криптографическим сила.

  3. необходимо надежно сравнить.

  4. не должны храниться непосредственно в базе данных. Там может храниться только хэш токена. (Помните, токен = пароль. Мы не храним пароли в виде обычного текста в БД, верно?)

  5. должен истечь в соответствии с некоторой логикой.

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

расширения и объясняя мой ответ:

  1. использовать HTTPS. Это, безусловно, самый важный момент, потому что он имеет дело с нюхачами.

    если вы не используете HTTPS, то многое может пойти не так. Например:

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

    • в Rails 3 файлы cookie окутаны только кодировкой Base64, поэтому их можно довольно легко выявить. Смотрите Расшифровка Файлов Cookie Сеанса Rails для получения дополнительной информации.

      поскольку Rails 4, однако, хранилище файлов cookie зашифровано, поэтому данные являются цифровыми проверено и нечитабельно для злоумышленника. Cookies должны быть безопасны до тех пор, пока ваш secret_key_base не просочилась.

  2. создайте свой токен с помощью:

    • SecureRandom.hex только если вы находитесь на Ruby 2.5+.
    • камень sysrandom если вы находитесь на старом Рубине.

    для объяснения того, почему это необходимо, я предлагаю прочитать sysrandomчитаю и то сообщение в блоге как генерировать Безопасные случайные числа в различных языках программирования.

  3. найти запись пользователя, используя идентификатор пользователя, адрес электронной почты или какой-либо другой атрибут. Затем сравните токен этого пользователя с токеном запроса с Devise.secure_compare(user.auth_token, params[:auth_token]. Если вы находитесь на рельсах 4.2.1+ вы также можете использовать ActiveSupport::SecurityUtils.secure_compare.

    Do не найти запись Пользователя с помощью Rails finder, как User.find_by(auth_token: params[:auth_token]). Это уязвимо для время атаки!

  4. если вы собираетесь иметь несколько приложений/сеансов одновременно на одного пользователя, то у вас есть два варианта:

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

    • хранить столько зашифрованных токенов на пользователя, сколько вы хотите разрешить текущие сеансы. Поэтому, если вы хотите разрешить 2 сеанса на 2 разных устройствах, сохраните 2 разных хэша маркеров в базе данных. Этот вариант немного менее прост в реализации, но он определенно безопаснее. Он также имеет преимущество, позволяя вам предоставить своим пользователям возможность завершить текущие Активные сеансы на определенных устройствах, отозвав их токены (так же, как GitHub и Facebook делают).

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

    срок действия токена Google истекает, если он не использовался в течение шести месяцев.

    Facebook истекает срок действия токена, если он не использовался в течение двух месяцев:

    родные мобильные приложения, использующие SDK Facebook, получат долгосрочный доступ жетоны, около 60 дней. Эти маркеры будут обновлены однажды в день, когда человек, использующий ваше приложение, делает запрос в Facebook сервера. Если запросы не выполняются, срок действия токена истекает примерно через 60 дни и человек должен будет пройти через поток входа снова, чтобы получите новый маркер.

  6. обновление до Rails 4, чтобы использовать его зашифрованное хранилище файлов cookie. Если вы не можете, то зашифруйте хранилище cookie самостоятельно, как и предлагалось здесь. Там не будет абсолютно никаких проблем в хранении аутентификации токен в зашифрованном хранилище файлов cookie.

у вас также должен быть план на случай непредвиденных обстоятельств, например, задача rake для сброса подмножества токенов или каждого отдельного токена в базе данных.

чтобы вы начали, вы можете проверить в этом суть (одним из авторов Devise) о том, как реализовать аутентификацию токенов с помощью Devise. Наконец,Railscast по обеспечению API должно быть полезным.

175

согласно README проекта, драгоценный камень devise_token_auth был вдохновлен этим сообщением StackOverflow:https://github.com/lynndylanhurley/devise_token_auth

9

вы можете попробовать использовать rails4 С вашим API, он обеспечивает большую безопасность и использование разработать 3.1.0 rc

  • в Rails 4.0 несколько функций были извлечены в драгоценные камни.

    • ActiveRecord:: SessionStore
    • Кэширование Действий
    • Кэширование Страниц
    • Русская кукла-кэширование через ключ на основе истечения срока действия с автоматическим управлением зависимостями вложенных templates.
      http://blog.envylabs.com/post/41711428227/rails-4-security-for-session-cookies

  • разработать 3.1.0.RC работает на обе рельсы 3.2 и Rails 4.0. http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/

  • устройство, ограничивающее использование TokenAuthenticatable в 3.1.0 rc но вы можете создать свой собственныйTokenAuthenticatable метод для проблемы безопасности. Это более надежно и безопасный.

для токена, хранилище сеансов вы можете пройти через http://ruby.railstutorial.org/chapters/sign-in-sign-out и http://blog.bigbinary.com/2013/03/19/cookies-on-rails.html для более understable.

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

3