{"id":3598,"date":"2013-08-13T14:40:09","date_gmt":"2013-08-13T17:40:09","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=3598"},"modified":"2018-09-24T14:22:49","modified_gmt":"2018-09-24T17:22:49","slug":"devise-3-1-now-with-more-secure-defaults","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2013\/08\/devise-3-1-now-with-more-secure-defaults\/","title":{"rendered":"Devise 3.1: Now with more secure defaults"},"content":{"rendered":"<p>We are glad to announce that Devise 3.1.0.rc is out. On this version, we have focused on some security enhancements regarding our defaults and the deprecation of <code>TokenAuthenticatable<\/code>. This blog post explains the rationale behind those changes and how to upgrade.<\/p>\n<p>Devise 3.1.0.rc runs on both Rails 3.2 and Rails 4.0. There is a TL;DR for upgrading at the end of this post.<\/p>\n<p><strong>Note:<\/strong> We have yanked 3.1.0.rc and released to 3.1.0.rc2 which fixes some regressions. Thanks everyone for trying out the release candidates!<\/p>\n<h3>Do not sign the user in after confirmation<\/h3>\n<p>In previous Devise versions, the user was automatically signed in after confirmation. This meant that anyone that could access the confirmation e-mail could sign into someone&#8217;s account by simply clicking the link.<\/p>\n<p>Automatically signing the user in could also be harmful in the e-mail reconfirmation workflow. Imagine that a user decides to change his e-mail address and, while doing so, he makes a typo on the new e-mail address. An e-mail will be sent to another address which, with the token in hands, would be able to sign in into that account.<\/p>\n<p>If the user corrects the e-mail straight away, no harm will be done. But if not, someone else could sign into that account and the user would not know that it happened.<\/p>\n<p>For this reason, <strong>Devise 3.1 no longer signs the user automatically in after confirmation<\/strong>. You can temporarily bring the old behavior back after upgrading by setting the following in your <code>config\/initializers\/devise.rb<\/code>:<\/p>\n<pre lang=\"ruby\">\nconfig.allow_insecure_sign_in_after_confirmation = true\n<\/pre>\n<p>This option will be available only temporarily to aid migration.<\/p>\n<p>Thanks to <a href=\"http:\/\/themoll.com\/\">Andri M\u00f6ll<\/a> for reporting this issue.<\/p>\n<h3>Do not confirm account after password reset<\/h3>\n<p>In previous Devise versions, resetting the password automatically confirmed user accounts. This worked fine in previous Devise versions which confirmed the e-mail just on sign up, so the e-mail both confirmation and password reset tokens would be sent to were guaranteed to be the same. With the addition of reconfirmable, this setup change and Devise will no longer confirm the account after password reset.<\/p>\n<p>Thanks to <a href=\"http:\/\/themoll.com\/\">Andri M\u00f6ll<\/a> for reporting this issue and working with us on a fix.<\/p>\n<h3>CSRF on sign in<\/h3>\n<p>Devise&#8217;s sign in page was vulnerable to CSRF attacks when used with the rememberable feature. Note that the CSRF vulnerability is restricted only to the sign in page, allowing an attacker to sign the user in an account controlled by the attacker. This vulnerability does not allow the attacker to access or change a user account in any way.<\/p>\n<p>This issue is fixed on Devise 3.1.0 as well as 3.0.2 and 2.2.6. Users on previous Devise versions can patch their application by simply defining the following in their <code>ApplicationController<\/code>:<\/p>\n<pre lang=\"ruby\">\ndef handle_unverified_request\n  super\n  Devise.mappings.each_key do |key|\n    cookies.delete \"remember_#{key}_token\"\n  end\nend\n<\/pre>\n<p>Thanks to Kevin Dew for reporting this issue and working with us on a fix.<\/p>\n<h3>Store digested tokens in the database<\/h3>\n<p>In previous versions, Devise stored the tokens for confirmation, reset password and unlock directly in the database. This meant that somebody with read access to the database could use such tokens to sign in as someone else by, for example, resetting their password.<\/p>\n<p>In Devise 3.1, we store an encrypted token in the database and the actual token is sent only via e-mail to the user. This means that:<\/p>\n<ul>\n<li>Devise now requires a <code>config.secret_key<\/code> configuration. As soon as you boot your application under Devise 3.1, you will get an error with information about how to proceed;<\/li>\n<li>Every time the user asks a token to be resent, a new token will be generated;<\/li>\n<li>The Devise mailer now receives one extra token argument on each method. If you have customized the Devise mailer, you will have to update it. All mailers views also need to be updated to use <code>@token<\/code>, <a href=\"https:\/\/github.com\/plataformatec\/devise\/blob\/2a8d0f9beeb31cd2287094c5dcf843d0bd069eb8\/app\/views\/devise\/mailer\/reset_password_instructions.html.erb#L5\">as shown here<\/a>, instead of getting the token directly from the resource;<\/li>\n<li>Any previously stored token in the database will no longer work unless you set <code>config.allow_insecure_token_lookup = true<\/code> in your Devise initializer. We recomend users upgrading to set this option on production only for a couple days, allowing users that just requested a token to get their job done.<\/li>\n<\/ul>\n<p>Thanks to Stephen Touset for reporting this issue and working with us on a solution.<\/p>\n<h3>Token Authenticatable<\/h3>\n<p>Jay Feldblum also wrote to us to let us know that our tokens lookup are also vulnerable to timing attacks. Although we haven&#8217;t heard of any exploit via timing attacks on database tokens, there is a lot of research happening in this area and some attacks have been successful over the local network. For this reason, we have decided to protect applications using Devise from now on.<\/p>\n<p>By digesting the confirmation, reset password and unlock tokens, as described in the previous section, we automatically protected those tokens from timing attacks.<\/p>\n<p>However, we cannot digest the authentication token provided by <code>TokenAuthenticatable<\/code>, as they are often part of APIs where the token is used many times. Since the usage of the authenticatable token can vary considerably in between applications, each requiring different safety guarantees, we have decided to remove <code>TokenAuthenticatable<\/code> from Devise, allowing users to pick the best option. <a href=\"https:\/\/gist.github.com\/josevalim\/fb706b1e933ef01e4fb6\">This gist describes two of the available solutions<\/a>.<\/p>\n<p>Thanks to Jay Feldblum for reporting this issue and working with us on a solution.<\/p>\n<h3>TL;DR for upgrading<\/h3>\n<p>As soon as you update Devise, you will get a warning asking you to set your <code>config.secret_key<\/code>. By upgrading Devise, your previous confirmation, reset and unlock tokens in the database will no longer work unless you set the following option to true in your Devise initializer:<\/p>\n<pre lang=\"ruby\">\nconfig.allow_insecure_token_lookup = true\n<\/pre>\n<p>It is recommended to leave this option on just for a couple days, just to allow recently generated tokens by your application to be consumed by users. <code>TokenAuthenticable<\/code> has not been affected by those changes, however it has been deprecated and you will have to move to your <a href=\"https:\/\/gist.github.com\/josevalim\/fb706b1e933ef01e4fb6\">own token authentication mechanisms<\/a>.<\/p>\n<p>Furthermore, the Devise mailer now receives an extra token argument on each method. If you have customized the Devise mailer, you will have to update it. All mailers views also need to be updated to use <code>@token<\/code>, <a href=\"https:\/\/github.com\/plataformatec\/devise\/blob\/2a8d0f9beeb31cd2287094c5dcf843d0bd069eb8\/app\/views\/devise\/mailer\/reset_password_instructions.html.erb#L5\">as shown here<\/a>, instead of getting the token directly from the resource.<\/p>\n<p>With those changes, we hope to provide an even more secure authentication solution for Rails developers, while maintaining the flexibility expected from Devise.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>We are glad to announce that Devise 3.1.0.rc is out. On this version, we have focused on some security enhancements regarding our defaults and the deprecation of TokenAuthenticatable. This blog post explains the rationale behind those changes and how to upgrade. Devise 3.1.0.rc runs on both Rails 3.2 and Rails 4.0. There is a TL;DR &#8230; <a class=\"read-more-link\" href=\"https:\/\/blog.plataformatec.com.br\/2013\/08\/devise-3-1-now-with-more-secure-defaults\/\">\u00bb<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[36,7,124],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3598"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=3598"}],"version-history":[{"count":18,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3598\/revisions"}],"predecessor-version":[{"id":7795,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/3598\/revisions\/7795"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=3598"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=3598"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=3598"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}