Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Devise user enumeration mitigations #2

Closed
eliotsykes opened this issue Apr 19, 2017 · 7 comments
Closed

Devise user enumeration mitigations #2

eliotsykes opened this issue Apr 19, 2017 · 7 comments

Comments

@eliotsykes
Copy link
Contributor

Use generic error messages such as "Invalid email or password" instead of specifying which part (e-mail or password) is invalid. Devise does that by default. Mitigates user enumeration and brute-force attacks.

Hi, I think this section of the checklist might benefit from updating as from what I can tell Devise has further user enumeration mitigations that are disabled by default. For more see eliotsykes/rails-security-checklist#21 where I'm trying to update another checklist with a similar issue. HTH.

@brunofacca
Copy link
Owner

Hi Eliot,

I'm glad that the project has its first contributor :)

I agree that Devise's paranoid mode is relevant to mitigate user enumeration. However, the Devise wiki says

If you use Paranoid-mode on Devise, you're protected against user enumeration on confirmable, recoverable and unlockable modules, but not on registerable. One of the validations on creating a new user is for it to have an unique e-mail or login. So, we can't add a response that s to the register controller because the user will not know if his account was created or not.

There are two solutions that are very common in the internet, that should stop robots doing the enumeration:

Add a captcha;
Add a rule that blocks create requests for a few minutes after creating a small number of users. E.g. blocking an IP for five minutes after creating five users.

I haven't recommended turning on paranoid mode because it may give developers a false sense of security against user enumeration while the registerable module is stull vulnerable. A possible way to avoid this is to include a checklist item recommending turning on paranoid mode along with a code sample regarding the implementation of a captcha. Blocking an IP after creating a few users would not be effective if the attacker distributes the user enumeration process amongst multiple IPs (e.g. a botnet).

What do you think?

@brunofacca
Copy link
Owner

I found a How To: Use Recaptcha with Devise in the Devise Wiki.

@brunofacca
Copy link
Owner

@eliotsykes This issue is highly relevant. Do you intend to submit a PR? I'm asking because if you don't, I'll do it...

Thank you.

@eliotsykes
Copy link
Contributor Author

Sorry I haven't had time to think through the (re)captcha solution.

I haven't recommended turning on paranoid mode because it may give developers a false sense of security against user enumeration while the registerable module is stull vulnerable

I've had this concern too. In the end I decided to be clear about the registration exclusion in the text, see diff https://github.com/eliotsykes/rails-security-checklist/pull/26/files

@eliotsykes
Copy link
Contributor Author

And sorry I forgot to answer your PR question, please go ahead and take it on if you wish.

@brunofacca
Copy link
Owner

Nice text on your checklist. Thanks for sharing :)

@brunofacca
Copy link
Owner

Done! f9142d3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants