Devise user enumeration mitigations

[eliotsykes]

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 https://github.com/eliotsykes/rails-security-checklist/issues/21 where I'm trying to update another checklist with a similar issue. HTH.

[brunofacca]

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]

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

[brunofacca]

@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]

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]

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

[brunofacca]

Nice text on your checklist. Thanks for sharing :)

[brunofacca]

Done! f9142d343b97c5b49995b8c176fbddc9fe644688