5

The remember_user_token cookie token generated by the Ruby Devise authentication component reveals part of a bcrypt salted credential when decoded.

For example:
remember_user_token=W1sxNF0sIiQyYSQxMSRtSHhGeWd3VkFNdzdxd3VmUE04MWdPIiwiMTUyMTA4NjEzMy4wOTU3Il0%3D--96341f2abb8e9fa777d9ad5199b2231f3d22e1d7

Decodes to:

[[14],"$2a$11$mHxFygwVAMw7qwufPM81gO","1521086133.0957"]

The second part of this tuple is the bcrypt cred up to the salt.
As the hashed password portion is omitted, I believe recovering the password would not be feasible. However, this does not seem like good practice and I am not clear on why this function has been designed to reveal even a part of the user's hashed credentials.

What are some scenarios where this information may help an attacker gain unauthorised access to the application?

Source code below:

http://www.rubydoc.info/github/plataformatec/devise/Devise%2FModels%2FRememberable%2FClassMethods%3Aserialize_into_cookie

http://www.rubydoc.info/github/plataformatec/devise/Devise/Models/Rememberable#rememberable_value-instance_method

  • 1
    The salt should be considered non-secret information and as such doesn't pose a significant risk. The salt is used to a) make the usage of pre-computed hash values more difficult, and b) ensure that two users with the same password don't also have the same stored hash value. Neither of these cases are compromised by storing the salt on the end user's machine. That said, there are alternatives in writing your own salting function / changing the configuration config.use_salt_as_remember_token. – Dave Satchell May 7 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.