d8-contrib-modules / tfa Goto Github PK

Currently a user must login as an admin, attempt to turn it off 2fa for a user, get prompted for a password and then enter the password.

Its impossible to do this for an admin that relies on drush uli to turn off 2fa. You get prompted for a password you don't know! Administrators should be able to disable 2fa without being prompted for a password.

Motivation
Currently there is no way to define fallbacks for validation methods.

Resolution
Add fallback to validation annotations

Add option to check which roles should have tfa setup.
TFA should only be required by these roles.

1. Audit D7 features of TFA
2. Audit this current D8 port started by Cash
3. Create issues in this repo for known gaps

Summary
As of 8.1 composer manager stands deprecated and is not the recommend workflow for pulling in dependencies of a module.
The recommend method is using composer
composer require drupal/<modulename>
But here it states that drupal.org's repositories are still in alpha and it is not advised to use this approach or am I understanding this wrong?

This module depends on an external OTP library and having a simple installation approach is crucial for user experience.

Resolution
TDB

Most of the flood control code for TFA is commented out at the moment.

• Update code to re-implement TFA flood controls

The current plan is to extend the Encrypt module to allow multiple Encryption configurations (config entities). Once this is done, we should be able to assign an encryption entity to each TfaPlugin type if desired.

We will need to wait and see how the Encrypt implementation pans out before finalizing this ticket.

Issues:

1. No mention of fallback plugins? How are we going to decide fallback plugins?
2. After the configuration is saved, there is no mention of what the user should do next.
   Having a hyperlink to the set up page( when required ) would be a much better!

Any more views are welcome!

I was just looking some codes in tfa.module file and I think it is better to replace "hook_user_login" with "changing route from Old UserLoginForm to NewUserLogin by registering an event subscriber service". We should try to use Symfony rich and Object Oriented Programming (.class) rather than procedural PHP code. (.module).

1. Look at behaviors of how this works
2. Leverage existing plugins

I'm not familiar with all new things in 8, but I was wondering if we should use in submitForm event dispatcher instead of calling plugin methods.

Could this be used in a way in building or validating form? (I guess not)

Right now there are a few plugin specific parts in the admin configuration form which are hardcoded.

Since the aim is to make this as generic as possible, making the admin configuration alterable is a must.

• Move the EncryptMethod that is defined in TFA to the Encrypt Module. This should be provided OOTB there and we can use it once @nerdstein finishes the updates he is working on.

The user should be allowed to disable TFA only when he has this permission.

The user should be allowed to login 2-3 times without validation if he/she has not set up the required validation yet.

When using the parent::build() function to get the non-form related code from the core UserLoginBlock the submit handler seems to call the UserLoginForm submit handler even after the $build['user_login_form'] is replaced with the TfaLoginForm and returned from the build function.

Figuring out why this happens and resolving the issue (if possible) would allow us to simplify the build() logic and no duplicate what we can use from the UserLoginForm.

1. determine functionality needed
2. outline implementation in D8

Currently, the only plugin types that gets loaded properly are TfaValidation and TfaSetup plugins. In the __construct method in the Tfa.php class, use the method that the validation plugin loading uses to load other plugin types.

• Need to make sure the fallback plugins are being sent in properly.
• Need to update the loading of plugins types to use proper D8 constructs. (See the way it loads Validation plugins for an example.)

Note:: Will likely need to make updates to tfa_basic to have an example to work with in order to get this working.

After you setup TFA if you wish to disable it the form asks for the user password.
After getting the user password should we try to validate it more by going through whatever validation methods the user has setup?

Motivattion

• The google authenticator class saw it's last commit about a year ago and is not maintained anymore.
• There are quite a few pull requests related to security mainly targetting timing attacks which we should definitely have in the class we use.

Resolution

1. Find a different repo which is much more updated than the current one.
2. Fork the Google Authenticator repo and update it as needed.

Motivation
We are shifting validation libraries from tfa basic to tfa.
The plugin definiton will be updated and hence if someone updates the plugin he will face fatal errors as the plugin definitons are still the outdated cached ones.

Resolution
TBD

Helper metadata like links for authentication apps as used in TOTPSetup should be moved to an annotation.

The schema for the tfa module is not correct.
For now I have hard coded some values but this needs to be improved in the future to make this more flexible so that other plugins can define the schema for any furthur implementations.

We encrypt the user secret using the encrypt method which utilizes the mcrypt extension.