xi / django-mfa3 Goto Github PK

Some questions users/implementers of this lib may have:

• How do I/should I handle password resets?
• Should I allow support stuff to reset 2FA codes? Why (not)?
• Should I force users into generating recovery codes? Why and how?
• When to require such a (re)authentication? If so how? (see how GitHub e.g. allows it with a password or MFA mode)
• How to communicate that thing to users, so our support team does not get overhelmed with thousands of users being locked out?
• etc. etc.

So in a full (real) implementation, thus users of the lib (aka "implementors") of course have to consider all these quite tricky UX/security-related things.
It is strictly speaking not your responsibility to help here, but IMHO it would be very nice if you could at least provide some pointers. Even because you start it in a good way by explaining security considerations. Looking over the edge of your lib would IMHO be great.

A good link I found would be the brief but good OWASP cheat sheet on the topic, especially the resetting thing.

The data that needs to be passed between client and server for FIDO2 are nested structures containing binary strings. The go to encoding for nested data would be JSON, but JSON does not support binary strings. Inspired by the python-fido2 example I therefore used CBOR instead. This has two issues though:

• While the browser does use CBOR internally, it is not exposed to JavaScript. So a separate library is needed.
• The result of CBOR encoding is a flat binary string. This is still hard to pass to JavaScript. I used a JSON-encoded integer list, which is grossly inefficient in terms of space.

I am not sure why the FIDO2 authors chose to use structures that cannot easily be passed to the client.

Unfortunately the JavaScript runtime does not have proper base64 support either, so there are very few building blocks for handling binary data.

I currently think the best bet is to use JSON with binary strings converted to lists of integers. Whether a specific value should be converted to binary could be hard coded, as the data structures that are used in FIDO2 are known.

Currently, this library supports FIDO2 and TOTP. Theoretically, it should be simple to add more methods. The only place where these are hard-coded are MFAFormView.method and MFAKey.method.

I am not sure whether I want to go down that route or stay focused on a fixed set of methods.

Currently there are no tests for this library. This is because it is complicated:

• I want to test the glue code, not the pieces that are glued together.
• FIDO2 keys are hardware device with a physical button which are intentionally hard to automate.
• The most important issue is security, which typically manifests in non-obvious request patterns.

Integration tests for TOTP would be relatively simple. But that would only address the first issue. The third issue could maybe be addressed by fuzzing. But overall I do not have a good idea yet.

When creating a TOTP key, a new challenge is generated on every request. So when I have a typo in the code I cannot simply fix the typo. Instead I have to delete the secret from my authenticator and start from scratch. This is both annoying and non-obvious.

The same issue theoretically also exists for all other form views. However, the challenge on TOTP auth is constant (None) and for the two FIDO2 views there is not really a way to have validation errors.

The big downside to keeping the challenge across requests is that this would be yet another case of state management with potential for security-related bugs.

I started this project in 2021 because I needed FIDO2 authentication for Django and there was no good library available. However, that changed. In January 2023, version 1.15.0 of django-two-factor-auth was released with FIDO2/WebAuthn support.

django-two-factor-auth is maintained by jazzband and much more popular than django-mfa3. So even though I like working on this library, I think it is the responsible thing to deprecate it.

Steps to do:

• review django-two-factor-auth
• contribute any features that are missing compared to django-mfa3
• document the migration process
• make a release to announce the deprecation

There is a small chance that after reviewing django-two-factor-auth I find out that the approaches are different enough so that it makes sense to keep both projects around. But honestly I don't think that will happen.

From the pyotp README:

Throttle brute-force attacks against your application's login functionality

This could maybe be achieved by integrating with django-axes. But it is important to not only throttle overall login attempts, but also second-factor attempts within a login attempt.

The required file cbor.js should either be included in the package or information on how to add it to a project should be added to the usage section of README.md.

My test runner is issuing a warning regarding the change introduced in Django 3.2
(models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'

It's not big deal, but would you consider setting the default auto field at app or model level?
See this post