Notifying the user whether the password or the email was incorrect after a failed login

[Daniel Nelson]

Hello,

Someone sent me a Mailchimp blog post
(http://blog.mailchimp.com/social-login-buttons-arent-worth-it/) that
shows that they were able to dramatically reduce failed logins by
telling the user which was incorrect: the email or the password.
Devise takes the position that it is more secure to obscure this (even
though with config.paranoid = false, user enumeration can be done via
the password reset form), but I would like to override this behavior
and clearly show the user whether the email or the password was
incorrect. I have checked the wiki and done some Googling, but all I
have found is how to prevent enumeration even more (eg: by customizing
registerable), not how to remove the default protection.

Thank you for any help you can offer,

Daniel

[Vasiliy Ermolovich]

Hi,

I think right not it can't be configured. The only way I see is to
override method `find_or_initialize_with_errors`
(https://github.com/plataformatec/devise/blob/f5e33089a032f44abd80225e34370c4fdd651a25/lib/devise/models/authenticatable.rb#L255)
and fill it with your own logic:

class User < AR::Base
def self.find_or_initialize_with_errors(required_attributes,
attributes, error=:invalid)
# your logic
end
end

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Devise" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to plataformatec-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[and...@benjamin.dk]

On Friday, 17 May 2013 16:02:03 UTC+2, Daniel wrote:

Hello,

Someone sent me a Mailchimp blog post
(http://blog.mailchimp.com/social-login-buttons-arent-worth-it/) that
shows that they were able to dramatically reduce failed logins by
telling the user which was incorrect: the email or the password.
Devise takes the position that it is more secure to obscure this

The reason why devise does this has to do with the attacker not being able to know if he got any of the parameters right, reducing the time of guessing by brute-force attacks/dictionary attacks to half. especially if he finds out one password and then he can get a way of getting all the users emails and try them all out. if you really want to implement this behaviour you need to be aware of this!

[Daniel Nelson]

> I think right not it can't be configured. The only way I see is to
override method `find_or_initialize_with_errors`

Thank you, Vasiliy.

> The reason why devise does this has to do with the attacker not being able
> to know if he got any of the parameters right, reducing the time of guessing
> by brute-force attacks/dictionary attacks to half. especially if he finds
> out one password and then he can get a way of getting all the users emails
> and try them all out. if you really want to implement this behaviour you
> need to be aware of this!

Thank you for pointing that out, Andreo. However, Devise alone doesn't
block against user enumeration even in paranoid mode
(https://github.com/plataformatec/devise/wiki/How-To:-Using-paranoid-mode,-avoid-user-enumeration-on-registerable).

I wonder whether the core team would be open to changing the way
Devise handles the paranoid configuration so that if paranoid is set
to false, it will tell the user which was wrong, the password or the
email. Not telling the user provides no security enhancement (because
with paranoid set to false, password reset and other routes can be
used to enumerate email addresses), but provides a diminished user
experience. Anyone on the core team reading this and want to weigh in?

Thank You,

Daniel

[Daniel Nelson]

Actually, this turned out to be as simple as updating devise.en.yml.

en:
devise:
failure:
invalid: That password appears to be incorrect.
not_found_in_database: "There doesn't appear to be a user with
that email address."