Merging Devise Security Extension into Devise?

[dillonwelch]

In addition to Devise, there's a gem called devise_security_extension that builds on Devise and adds additional modules. Unfortunately, the original maintainers have gone MIA which has made it difficult to get maintenance updates for things like Rails 5 fixes or Ruby 2.4 fixes merged in, let alone bug fixes or features.

Several members in the community have decided to make a new fork at devise-security in order to have a mainline branch where this work can be contributed.

Is there interest in getting some/all of the modules in this gem merged into Devise itself?

[rafaelfranca]

I don't think so.

Merging this means that we will have to maintain and, while I like to maintain code, I prefer to keep the scope of the things I maintain really small. Because of that, through the years, we have being polishing the scope of Devise to be only essential features and merging those extensions into the gem is going against this goal.

Other maintainers may have different opinion than mine so I'll keep this open to get their feedback too.

[natebird]

I would also like to see this merged into the main Devise repository but I also understand the goal of keeping the project scope small.

[danielricecodes]

Perhaps instead of merging the two together, the Devise Wiki or README's can be updated to reference the devise-security repository instead? Part of the problem is letting people know that there is a collection of useful modules over here.

[tegon]

I agree that it's better to keep things separated.
A Wiki page sounds like a good idea, if anyone would be up to writing, we'd appreciate it. 😄
@feliperenan WDYT? Can we close this one?

[monfresh]

I've worked on some projects where some of those modules were required, but I have since learned that most of them are in fact anti-patterns. The latest NIST guidelines specifically say that you should NOT do the following:

• expire passwords
• prevent people from reusing passwords
• have complicated character requirements for passwords (it's better to enforce a minimum length and use something like zxcvbn and other dictionaries to enforce strength). Here is the rationale: https://pages.nist.gov/800-63-3/sp800-63b.html#appA
• don't prompt for questions like "what was the name of your first pet?"

[helmutrs]

I'd like to add about NIST Guidelines:

• Hash with HMAC
• PBKDF2 over bcrypt with at least some 'k' iterations.
• The reason for PBKDF2 because it is based on hashing primitives that satisfy many national and international standards.
  Maybe something that we need to look on the future?