[SR] Facilitate 2FA+MultiFactor compatibility (2FA/two-factor -> MFA/multi-factor) #2788
Comments
|
(External reference: I am maintaining this information in a related post about CMX perspectives over at the CMX.zone, here is the reference: https://cmx.arbolis.net/content/articles/multi-factor-compatibility-for-login-related-modules-needed-for-the-distrobase . Also posting this over at D.o. shortly.) Further specifications and examplification / insights into the relevant login process(es)The race (conditions) - "the order of things": 2 alternative starting pointsA. User arrives "at the login logic" through a (valid) one-time login link (either through "forgotten password link or by another user/admin sending out a "one-time login link" via something like the "login-one-time module.) B. Normal login starting at the login page asking for credentials. If A., then skip Stage 1 and go straight to Stage 2 below: If B., then start with Stage 1: Stage 1 - which credentials are initially required (or "enough")?
IF either the password is not required (either from settings, or in the case of using a One-Time login link), OR the correct password was given, then check for extra requirements (factors): Stage 2 - Second- or Multi-Factor logic
After the "2FA"/"MFA" alternatives have been passed, skip to Stage 3... Stage 3 - Legal module active? (Terms-of-Service (re-)confirmation)Check if the Legal module (is active and...) requires (first or new) confirmation for the current or new ToS revision.
Stage 4 - Figure out the "landing page" after the authentication is okLanding page scenarios:
Core features: The flexibility for Stage 1I think (hope...) that the only relevant part for Drupal/Backdrop core in this context is all in Stage 1: Depending on which (contrib.) modules are activated on the actual site, the site figures out during Stage 1 the appropriate route and next steps. All the logic of Stage 2 should reside within whichever extra/contrib. modules are activated on the site, hence not an issue for core. (EXCEPT perhaps if we agree to put both the TFA and TFA_Basic modules in core (might make sense), then TOTP etc. are handled in/by core.) The core MFA functionality should have settings for the following:
The core functionality should be indifferent as to which extra/contrib. modules are (or will be) used on the site. It should be made so that it is totally up to each extra module to integrate correctly and find its way into the (appropriate place in the) "race". Examples related to core configuration (Stage 1 above):
Compatibility with Maintenance mode...(!) For users that are member of any 1 role that is allowed to use the site in maintenance mode (separate, independent/existing core permission), all elements of this login logic should work also when the site is in maintenance mode... (Please keep in mind that "Maintenance mode" is not just a mode we use temporarily/sometimes/short-time; It has several good use cases and there are many sites where teams are working fully in maintenance mode for months, even "permanently" until a whole other version of the site is released, so this concern is quite valid.) D.o references:
Aaaaand..: Masquerading compatibility (Just-for-the-record, potentially not relevant for core)The Masquerade module (and ditto Devel function) needs customizeable (preferably both roles-based and optionally user-id based) settings to..: a) decide who should be allowed to masquerade into such accounts while bypassing all the above..., and b) whenever any one of these options should be enforced also while masquerading, it should also work in that context (so it does not prevent masquerading, yet still enforce the desired security). (Some admins may need to be blocked from certain accounts within the roles they are generally allowed to masquerade to (...), for example by enforcing the target user's physical Yubikey also for masquerading...) |
|
Related issue at D.o: Facilitate 2FA+MultiFactor compatibility (2FA/two-factor -> MFA/multi-factor) https://www.drupal.org/node/2901795 |
|
I've been thinking a bit about this myself. I'm trying to define a pair of interfaces, one for identity providers and one for authentication providers. These interfaces would be used by a core framework where admins could define the requirements. The identity providers would allow external user databases (e.g., LDAP/AD). Some kind of identity reference would need to be added, so a user could be authenticated against their LDAP password or an SSL cert in their LDAP record, separate from a password in their Backdrop user record. The authentication providers would provide challenge-response elements. A password's challenge would be a form field, an HTTP Basic challenge would be an HTTP header field, an OAuth challenge would trigger the auth token sequence. Some kind of credential setup needs to be included in the interface, too, to facilitate password changes or TOTP setup. The core framework would use rules patterned after PAM's sufficient/required control, and set up the requirements using draggableviews to stack an arbitrary number of "stages". Reading through your description, it sounds like we are generally on the same page. |
|
A great and relevant issue, thanks for documenting so thoroughly here @LeeteqXV.
If what we are talking abut is fixing a bug that prevents race conditions, and the solution is straightforward, that's something that could get in as early as 1.7.2. Unfortunately, I don't believe there is a clear straightforward solution for that yet. In terms of adding any kind of new API - or even the groundwork for one - I'd give this almost no chance of getting into 1.8. We are already less than 3 weeks from code freeze, and haven't even started seriously thinking about this problem space. The last thing we want to do is rush in some "groundwork" that turns out not to be useful for our final solution that we are then stuck with for the rest of the 1.x cycle. I'd like to see a clear proposal, perhaps something like @jlfranklin suggests, with an API for identity and an API for authentication, perhaps with a [META] of relevant API changes and additions. Once we have that meta it is possible that one (or more!) of the child issues could get into 1.8 if they were ready, but my guess is that we're more than 3 weeks away from any of them. |
|
@jenlampton - I am fine with just the possibility of getting it into a 1.8.x release without an API, just to get started. What I am after here is the agreement of the perspective and initial steps. Just the "yes, it is possible to get the first part into "any" .x release", NOT needing to make it wait for 1.9 just to get started, or the clarification whether or not this is irrelevant for core (and should be done all in contrib? (I think the 1st stage needs to be in core, at least)). |
|
@jlfranklin - yes, LDAP is also an important "factor", just did not bring it into this initial request to avoid that extra complexity right now. But LDAP is certainly needed as well, just not for the first step, IMHO. |
|
@LeeteqXV any bug-fix can get into any "patch" release (so, as early as 1.7.2). It sounds like there might be an existing core bug relating to race-conditions. If that can be confirmed, we can fix that as soon as a patch is ready. If we decide to add any new feature (or new API) -- and this would certainly be considered a "new feature" -- any part of that can only be committed into a "minor" release (so, 1.8, or more likely 1.9). Please see https://backdropcms.org/releases for more on semantic versioning. |
|
@jenlampton - yes, I am aware of the versioning policy. The question from my point of view is what exactly is needed for the first step, to move things along: would that need to be an API change (hence delayed to 1.9), or can we get started sooner without having the API first? That is the main question: to identify what exactly could be the first small step that would prevent further delay. |
|
As we said in the weekly meeting, a "new feature" will need to go into 1.8 or 1.9. It is explained more clearly than I can do here on https://backdropcms.org/releases. Please give that a read before you ask about it again :) |
|
My main point is that IF the answer is that this cannot even be started without building a full, new API, then the answer is obviously to wait for 1.9. However, what I am asking here now is if there is any way of doing just a little bit for the initial part of Stage 1, which does not require an API initially, then we might get started with a small part of this before 1.9, and then work to improve and establish a proper API from there? |
I understand what you are asking, and I have answered it several times, maybe to the best of my ability. What release any code can get into depends on what the code is changing. In this case, that will depend on what you mean by As I said before: if As I said before: if
The part I think you may be missing is that a "new feature" is not necessarily tied APIs. Does that clear things up at all? |
|
Another thought: It's very hard to talk about this generally. We are going to need to come up with a solid course of action including all intended changes to core before we will commit any of it. Once we have that list, we'll be able to determine which of those changes are bug fixes and which are new features, and which of them can happen in what order. At that point we'll be able to decide which changes can be tagged for a particular release. |
|
I am also curious as to the fact if not many in the community sees the (significant!?) need for this.., or maybe I should turn that around and ask if we can assume that many are NOT entering into Backdrop until 2FA is in place... - do we even know? Even without any measurement for that, I am just assuming that there may be many more than just me and my projects that are getting into a dilemma where several sites/projects need to get started on either Drupal or WP instead of BD "already" this year mainly because they cannot wait any longer, and simply need 2FA from the start. I wonder what is the percentage of serious projects/sites establishing themselves now in 2017 without at least TOTP/2FA as a requirement. (And I would personally love to be able to start recommending BD to new projects, which I can only do before accounts can be sufficiently protected...) Google, Facebook, Dropbox and others are already supporting the new U2F, meaning that with the same "key" any person can secure multiple (unrelated) accounts. The new U2F is also anonymous so that the servers does not know if the same key is used on another account. Last year the US NIST started recommending AGAINST using SMS as 2FA, due to security concerns, so now it is a choice between the well etablished, flexible, easy and free, yet (much) less secure TOTP standard (Google Authenticator uses that standard) - and U2F (read: (physical) Security key(s)). 2FA and the Reference(s) features are the two main last showstoppers for several new sites, with the Legal module coming in as a real showstopper for a fraction of those (due to conflict with 2FA also on D7). Several projects can not be postponed as far as until next year, so they'd have to bite the bullet and launch them on a different platform. (Once that is decided for site, that project is most likely not going to spend extra resources to migrate to BD in quite a while.) We can of course simply proceed as usual and port the TFA/TFA_basic modules and the Legal module to BD with no change needed to core, but I would just want to know if there is anything we can do for core to set the "direction" for these modules so that when more and more are ported, they would follow a recommended pattern that will be good for all and mean less conflicts and race conditions. Maybe all that is needed is a documentation reference for advice to maintainers who want to port such modules, not even a code change to core? I dont know, but that is part of the clarification that I am asking about here. |
|
@jenlampton - thanks for your replies, you do not have to answer more times about that documentation part. I am the one asking IF it is possible without that. I am not a coder, so it is you guys that have the competence to find out IF this can be done in a way that does not need such a change; IF it can be started in a simpler way. I cannot, as I am not a coder. The only thing relevant for me is to understand (and accept) that it will be pushed to 1.9 if there is no other way to prevent this being a "new feature". I am waiting for some coders to figure that out, as that is not within my competence to do. |
|
(For example; I would not know if there is already something in core that can be regarded as a "bug" and demand a "fix" into any current release to help login related modules avoid running into race conditions. I would not know if a small change to core will make it easy to avoid unintended race conditions in contrib modules. And I would not know if such a change/fix would be defined inside or outside the scope of the next minor release or not. That is an example of what I might be hoping for, and is for you coders to have the competence to know, not me as a non-coder.) |
It would depend entirely on the specific issue. Do you have a hard example? Such an example should include the version of Backdrop, what modules are enabled (both contrib and core), the sequence of events required to trigger the issue, and what the site does wrong or fails to do at all. |
|
@jlfranklin - that sounds like something that needs a code inspection to figure out. Let me instead point out the simplest scenarios: a) If only the TFA/TFA_basic modules were ported; no relevance for core and hence we'll have 2FA/TOTP with a simple, normal port. No need for any preparations or co-ordination, strictly speaking. b) If we want to use Legal module too (also need to be ported), then we also can do that without involving core; having two tasks to solve: 1. Make it play nice with TFA_basic's TOTP when revisions of the ToS interferes with the login process, and 2. Ensure that Legal can handle BOTH TFA_basic's TOTP AND core's "forgotten/reset password" function SIMULTANEOUSLY. Also possibly not affecting core; normal port. So far so good, perhaps, although I fear (?) that without involving core at this point, the solution to number 2 might be an unnecessary workaround instead of a proper logic that maintainers of other modules may benefit from and "hook into". If I am wrong about that, all the better. c) But now we get into the areas where many other modules also needs bits of the same (and beyond) (clear) logic to adhere to, so that not all maintainers need to figure out these things separately and then getting into delays by similar bugs (in each contrib. module) as people start combining more modules such as Yubikey, passwordless, login-one-time, login-destination, etc. Someone may do a simple port of the Yubikey module also without affecting core; but several sites would most likely want to offer the choice between Yubikey and TOTP (TFA_basic) right away, as very few sites are in the position to expect ("all"/"important users/accounts) to have or acquire physical Yubikeys, and then that logic outline becomes relevant immediately, which IMO should be provided by (read: "recommended/directed/approved") by core, at least documentation-wise. I think it would be a great time saver to have at least an outline "recommended by core" before we invite maintainers to start porting, as all would benefit from a "smart starting point". I fear that without a clear outline, the inter-module incompatibilities are likely to delay sites that need 2+ such contrib. modules to play nicely together, for months if such bugs have to be figured out separately, independently. The first critical part is a simple port of TFA/TFA_basic, and then hopefully the Legal module. (AFAIK, no sites currently benefit from ToS functionality with elegant and suitable handling of revisions - as per now, and it is 2017... - which is especially important for premium content sites, for example.) (For the record: "please" change the "T" in TFA/TFA_basic to "M" (MFA) in the process: Multi-Factor is the correct term for the subsequent developments. 2FA is only a temporary phase and almost outdated already.) Example from my own (D7-based) sites/projects: We often require Yubikeys for admin roles, content managers, and other users/roles with extra permissions, then TOTP for either the rest or only for selected roles, while normal users without special privileges may be allowed in through basic user name/password login, or through enforced links-through-email ("passwordless" module). Very little of that is currently possible along with the Legal module, sadly. Whatever may work with it, will break the password reset function whenever the ToS has changed at the same time.) Initially I chose to write this issue providing the whole picture (as far as I could), as I hoped for opinions on the "direction" first. Hopefully it may be useful for various maintainers later. Anyway, as you can see, there are some simple steps that can be taken even without supporting a "grand plan". |
|
Related: #2377 |
|
Potentially related (should be possible to use alternate login paths - for security): #1977 |
|
And in case anyone is interested in the first part that might or might not be trivial to get to work, this is the error given when trying to configure TFA/TFA_basic on BD 1.7.1 with just a basic .info file adjustment (no port):
|
|
FYI: The Yubikey module may already be usable "by itself" as 2FA on some Backdrop sites: Without being "ported", the default Drupal 7 version of the Yubikey module (version 2.1) works "somewhat" with the following 2 adjustments: a) Basic .info file update according to the Backdrop docs However:
|
|
My general notion is that perhaps most of the modules mentioned in this issue could be adjusted to "work somewhat" on Backdrop already now with only small/easy "quickfixes" from a developer. If any of you developers wants to check if it may be easy, try the "passwordless" module: It gives the following error when trying to use the initially correctly emailed login link:
PS. In addition to the standard passwordless.info file updates, it must also have the following line changed: |
|
That's enough input from me on this issue, I think. I would like to know whom among the contrib module devs are passionate about security (alternatively: would like to build competence in that field), partly to get to know if that is an area we need to pay particular attention to in the various outreach/recruitment efforts. |
|
(Btw: Login_destination module vs. cTools existing possibilities: It is often practical to use cTools for contextual redirects etc., but on sites where we want to teach non-tech site owners to do basic site administration (in particular those who want to learn to easily set up more, similar sites on their own), the cTools GUI is too scary/technical so the GUI of the Login_destination module is by far preferable. I have not mentioned the similar possible incompatibilities that may arise from using cTools' Page Manager instead of Login_destination for this feature earlier in this issue, but that also needs to be checked/compatible with the login logic of the various elements in this issue at some point. Relevant in the same places as the Login_destination module is in the describe logic, but I guess with quite a lot more potential complexity/scenarios/options than the simple Login_destination module.) |
|
(Edit: I just edited 2 previous comments of mine to correct the name of the "login-one-time" module. There is another module called "one-time-login", which I am NOT using or referring to anywhere in this issue, but I sometimes confuse the two, in particular because when saying something like "send a one-time login link", the correct grammar and sentence logic is identical to the name of the other module... - I'd consider a reward to anyone who merged the two, just to get rid of the confusion... ;-) ) |
|
Attention - Contrib. developers: How many here regard Two-Factor authentication (and by extension: account security) as a requirement for "any"/most modern web sites? Is there yet a general consensus that passwords (even with SSL!) are NOT secure enough without a second factor? |
|
No such consensus exists. It's not hard to come up with examples where one-factor is sufficient or necessary, either because the data on the site is low-value, the site is only accessible on a private, internal network, or the logins are for web services or IoT devices which cannot provide effective multifactor. Security = 1 / convenience. Multi-factor adds considerable security. Where lower convenience will impact adoption, multi-factor becomes a self-imposed impediment to success. "Why are they insisting on a second factor to post a lolcat picture? Forget it, it's too much trouble." This holds true for web services, too. If you had to grab your TOTP fob every time you tried to stream a movie, would you bother, or would you choose a competing service that doesn't impose that requirement? The security needs of individual sites must be decided by the site owners. |
|
@jlfranklin I do not think this is a question of all or nothing. Any user roles that does not provide permissions with security concerns may be set to allow the user to log in without 2FA. The issue is that all sites have at least 1 admin that definitely does need 2FA, and therefore the option to select which roles should require it is needed for "all" sites... Even sites where not even the admin access is a concern ...?!... (do they exist?), it is still a valid point to make sure attackers are prevented from entering and (mis)using the site in attacks against other servers. |
|
(So, this is not about enforcing 2FA on roles/users that "only want to post a picture".) |
|
Related/FYI: "What can Legal module do to avoid conflicts with other modules?" |
jenlampton
changed the title
jenlampton
changed the title
(Filing this feature request as a result of a short mention in today's BD weekly meetup.)
Two concerns, but only 1 relevant for core, hopefully with at least a clarification / guideline in place before or on the release of 1.8. Not sure how much needs to be done code-wise for core. If a separate/new API is the answer, then the initial question is if we can do something "imperfect" only partially to help various ports of contrib modules from D7 head "in the right direction" or take a "unified approach".
Most (all?) of the existing/relevant modules may well reside in contrib, but the question is how core can help them avoid race conditions and incompatibilities. Does that constitute an effort too big to consider for inclusion in 1.8.x?
For actual examples, here is my initial list of the most relevant contrib modules:
Examples:
Below are some examples on which "issues" we need to fix when porting those modules to BackdropCMS, related to the above modules (based on current situation/experience from D7):
(Notice that these examples are mostly issues that needs to be fixed in each contrib module. THIS feature request related to BD core is simply a question of identifying what/how core can facilitate and help guide these ports into a constructive direction where race conditions and incompatibilities can be avoided from the start.)
passwordless (email link instead of password) is most often/likely the first part of the login process. It does not redirect properly when (some) other(s) of these modules are active, so that TFA/Yubikey/etc. does not get to work after this module has accepted the login. The result is currently aborted logins.
TFA_basic (TOTP/Google Authenticator compatible) should allow the login to proceed through other steps as well, such as subsequent Yubikey / U2F.
ToS updates may aim to PREVENT login if the new ToS revision is not accepted, thus it needs to come FIRST in the login process (second if using "passwordless" / email login links), before the TOTP/Yubikey/U2F kicks in.
Yubikey module has options for disabling username/password and only use YK for login. When an account also has activated TOTP or email-login (passwordless), those should also get to work without conflicts with YK. This part of the features might be the one we want in core: the very setting per account for how many and which authentication elements are required (also depending on roles; so the combination of roles is key here)
legal does not get to do its renewal of acceptance on new ToS revisions if some of the above modules also kick in at the same login time.
(PS. The world is about to realize that two-factor is important but not enough by itself, depending on the sensitivity of the content/accounts/site(s) in question. We need to cater for all. If you look at for example Google's password recovery process, that is already multi-factor (and a great example). We need to aim for multi-factor functionality already now, not just two-factor.)
The text was updated successfully, but these errors were encountered: