Implement a new second factor method that uses WebAuthn.

Description

A new authentication method is available in the setup wizard: WebAuthn, that enables support for hardware authentication devices such as fido-u2f keys in modern browsers that implement the specification.

Motivation and Context

WebAuthn is supported in the Chrome, Firefox, and Edge browsers, for credential creation and assertion using a U2F Token, like those provided by Yubico and Feitian.

How Has This Been Tested?

New view and utils tests have been added.

Screenshots (if appropriate):

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have added tests to cover my changes.
• [x] All new and existing tests passed.

When using the login wizard the user's password is stored in plain text in the session store. The information is stored by formtools' wizard class. This is a security risk, depending on the deployment this can easily lead to a leak. Imagine a shared database ...

The information is not required to complete the token step, it would suffice to store the authentication state once the user's username and password are verified and then call login() in the done() method.

Based on #280 and my recent work on making a method registry in #328, this is a first step in that direction, trying to isolate code per auth method. That's not the end of the road, but this commit should at least pass the tests.

We are breaking compatibility because we moved the PhoneDevice models to plugins/phonenumber sub-app, but I think that's a price to pay for added modularity.

(scoped to settings.LOGIN_URL). If cookie exists/is valid on the next login, token steps are skipped

1 - if user checks checkbox to token step "Remember this device for %s days" 2 - create signed cookie with the desired end date 3 - on next login, if cookie is present/valid, allow login with login step only

Description

added a method token_required() that returns False when a valid signed cookie ('rememberdevice') is present. If not required, methods has_token_step() and has_backup_step() will return None (skipping that logic).

To enable OTPRequiredMixin() to grant access, if token_required() returns False, a device will be added to user

Motivation and Context

issue #56

How Has This Been Tested?

yes, tests were added to test_views_login.test_with_backup_phone() testing both the form change and the cookie logic.

Ubuntu 16.04, Postgres 9.3, Python 3.5.2 Django==2.0.3 django-bootstrap-form==3.4 django-debug-toolbar==1.9.1 django-formtools==2.1 django-otp==0.4.3 django-phonenumber-field==1.3.0 django-two-factor-auth==1.7.0

ran "make test" with no errors

Screenshots (if appropriate):

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [X] My code follows the code style of this project. - I tried to :)
• [X] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly. (I will, if the changes are OK with you)
• [X] I have added tests to cover my changes.
• [X] All new and existing tests passed.

This issue tracks the implementation of the Jazzband guidelines for the project django-two-factor-auth

It was initiated by @Bouke who was automatically assigned in addition to the Jazzband roadies.

See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

Feel free to ping a Jazzband roadie if you have any question.

TODOs

• [x] Fix all links in the docs (and README file etc) from old to new repo
• [x] Add the Jazzband badge to the README file
• [x] Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
• [x] Check if continuous testing works with GitHub Actions
• [x] Check if test coverage is tracked with Codecov
• [x] Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/django-two-factor-auth/collaboration/)
• [x] Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-two-factor-auth/users/)
• [x] Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-two-factor-auth/integrations/)
• [x] Fix project URL in GitHub project description
• [ ] Review project if other services are used and port them to Jazzband
• [x] Decide who is project lead for the project (if at all)
• [x] Set up CI for Jazzband project releases if needed and open ticket if yes

Project details

Revive #267 thanks to @Atterratio for the initial patch. I did some changes based on the reviews on the original pull requests and some doc style fixes.

Description

Make possible two-factor authorization using emails.

Motivation and Context

Although this way of two-factor authentication is not very reliable, it can be preferable for some users.

How Has This Been Tested?

Tested in a local project. Not fully tested but I tried it out. Didn't look closely at old PR.

Screenshots (if appropriate):

Content-Type: multipart/alternative;
 boundary="===============1209054917869947523=="
MIME-Version: 1.0
Subject: Authentication token email
From: [email protected]
To: [email protected]
Date: Wed, 28 Jul 2021 04:20:20 -0000
Message-ID: <[email protected]>

--===============1209054917869947523==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Hello,
Your email address has been given for two-factor authorization on the our website.
If you did't do this, just ignore this message.

Authentication token for user hello is 487008.
--===============1209054917869947523==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit



<p>Hello,</p>
<p>
    
        Your email address has been given for two-factor authorization on the our website.
        If you did't do this, just ignore this message.
    
</p>
<p>Authentication token for user hello is 487008.</p>
--===============1209054917869947523==--

-------------------------------------------------------------------------------

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have added tests to cover my changes.
• [x] All new and existing tests passed.

Untested attempt to allow newer django-phonenumber-field dependency for issue #387

Description

As above PS: I would like to know why you required <3.99 and not <4 -- is this best practice or for some other reason?

Motivation and Context

Issue #387

How Has This Been Tested?

It hasn't. https://github.com/stefanfoulis/django-phonenumber-field/blob/master/CHANGELOG.rst reports no breaking changes so fingers crossed, eh?

Screenshots (if appropriate):

N/a

Types of changes

• [X] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
  • Provide Django 3.1 support in dependency
  • Allow package use when people are already using django-phonenumber-field 4 or newer
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.

Patch imports and setup to use django-formtools instead of the obsolete contrib package.

This fixes issue https://github.com/Bouke/django-two-factor-auth/issues/89

Passed all tests in my environment.

I want to implement remember otp for few hours 10 hrs. Means on first attempt admin gives userid/password an then give the OTP and for next 10 hrs when admin try to login again then it asks for userid/password only and skip the OTP till the 10 hrs.

Whats the best place to implement this in codebase.

@Bouke

• Upgrades phonenumberfield
• Uses phonenumberslite by default (taken from https://github.com/stefanfoulis/django-phonenumber-field/blob/1.1.0/setup.py#L7-L8)
• Removes debug_toolbar from INSTALLED_APPS as it errors before running the server on django 1.10 due to middleware missing (https://github.com/Bouke/django-two-factor-auth/blob/543687e872bfe7a3d6244f8c73fb9149e53a1df9/example/settings.py#L33)

Hi! I just want to thank you for your work on this! It's pretty amazing. I was wondering if Yubikey support would be added at any point, since django-otp also supports Yubikeys?

I would like to increase security of some views such as submitting payouts, handling money or other potentially risky tasks. To increase the security I would like to let the user re-submit his/hers OTP once again for every POST action.

Expected Behavior

The scenario when this might help is such that the user leaves his/hers computer with session already authenticated and goes off. The some other person can come in and for example steal all money from his/hers account.

Current Behavior

In current logic of django-two-factor-auth it is also possible to disable 2FA without any additional authentication and set a new one. It would be needed to require secondary 2FA also for /account/two_factor/disable/ view in order to make this protection effective.

Possible Solution

The described scenario could be prevented if the user re-submits OTP code before/during the making POST request to the security demanding view.

The second possibility how to implement this might be to modify the @otp_required/OTPRequiredMixin decorator/mixin with requirement for maximal age of the authentication. So for example I could decorate the risky view with:

from django_otp.decorators import otp_required

@otp_required(max_age=5)  # 5 seconds
def my_view(request):
    pass

I am currently using REST API for user login. Now want to add two factor authentication to my existing Login api. In django-two-factor-auth there are views provided by default, and I want to customize them according to my API response.

This might look similar to the issue described in #473 but is different. It refers to version 1.14.0 and specifically only to the case where Email has been configured as the primary method and Phone sms as the backup authentication method. Please, can someone also confirm that the behavior described below can be reproduced?

Expected Behavior

In the login screen where the user is being asked to enter the token received by the primary method (Email), clicking on the alternative method to sent the token by SMS and submitting it to the login form should result in a successful login.

Current Behavior

After submitting the valid code received by SMS (as a backup method), it is not accepted and the user is redirected to the previous login screen with an error message for 'Invalid token' displayed.

Steps to Reproduce (for bugs)

1. Enable two factor authentication from the setup wizard by selecting Email as the (primary) authentication method.
2. Add a phone number as a backup method and verify it.
3. Logout and open the login page again, enter your credentials (if any).
4. When prompted to enter the authentication token, click the button to send a token to your phone number instead (alternative method).
5. Enter in the new form the valid token received by SMS. Instead of a successful login, you get an error message for invalid token and are redirected to the previous login screen.

Context

Providing 2-factor authentication to users by combining Email as main authentication method and Phone SMS as the backup method (a rather popular use case) seems to be problematic. Interestingly, when configuring the token generator mobile app as the primary method and the SMS as the backup method, the issue does not occur and the user is able to successfully enter the sms token.

Your Environment

• Browser and version:
• Python version: 3.8.10
• Django version: 3.2
• django-otp version: 1.1.3
• django-two-factor-auth version: 1.14.0

Current Behavior

The OTP field does suggest past OTP codes which might overlap with other screen elements, especially on mobile phones. Tested on Chrome browser on Android. The field has autocomplete="one-time-code" attribute (introduced in #396), which should suggest SMS codes on iOS, but is not working correctly elsewhere.

Expected Behavior

The field should make SMS suggestions on iOS, but not suggest past codes.

Possible Solution

I am not sure how to fix correctly. According to StackOverflow answer the field should not suggest anything if Chrome doesn't understand autocomplete field value, but that does not happen.

Solution could be using different value based on "user agent" or something like that, but that seems to be too complicated.

Steps to Reproduce (for bugs)

1. Set up OTP authentication
2. Log in and out few times
3. You will see the suggestions covering whole mobile screen

Context

It is sometimes difficult to get rid of the suggestions and enter correct code.

Your Environment

• Browser and version: Chrome 107.0.5304.91 on Samsung A40 Android 11 SM-A405FN
• Python version: 3.10
• Django version: 4.0.8
• django-otp version: 1.1.3
• django-two-factor-auth version: 1.14.0
• Link to your project: https://www.blenderkit.com/

Description

reference: https://github.com/jazzband/django-two-factor-auth/issues/565

This is temporally workaround until django-user-sessions Django 4.x compatible version is released.

Motivation and Context

reference: https://github.com/jazzband/django-two-factor-auth/issues/565

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.