cz-nic / django-fido Goto Github PK

If user tries to register a token with an unknown attestation type, the resulting exception is uncaught and causes server error. It should instead produce a helpful error about unsupported token type.

Django authentication system is built upon the idea of single-request authentication. User sends a request, it's evaluated and then django either logs user in or not.

Approach of django-fido is different. It provides second step authentication for user, who is already authenticated. This does not work with a general django app without creating some kind of additional authentication checking mechanism.

It should be possible to use one step authentication with django-fido i.e. use single form that sends username, password and fido credentials all at once. For maintaining backwards compatibility, we should create a new setting (perhaps DJANGO_FIDO_TWO_STEP) which default value will maintain the current behaviour.

Currently the registration view code is omitting the resident_key param, could we add an check box on the frontend to enable this field to set to True?

I would like to have this functionality to implement passwordless on top of this package.

Hi, Tom from Codecov here.

We noticed that you are using Codecov with fairly high frequency, and we’re so excited to see that! However, because you are not using our app, you may have experienced issues with uploading reports or viewing coverage information. This is due to rate-limiting issues from GitHub.

In order to prevent any future outages, we ask that you move over to our GitHub app integration.

The process is extremely simple and shouldn’t require more than a few clicks, and you should not expect any downtime. By moving to our app, you will no longer need an admin or separate account to manage the relationship with GitHub as the team bot.

Let me know if you have any questions, or if I can help at all with this process.

travis.org is dead, we need to move to Github Actions for our CI.

Authonticator model should have a label(models.CharField) field to store user defined label for easier handling of multiple keys.

Hello, thanks for the package, it works great with django views.

Now I need to integrate it with our single page app, which the login is via API, is there a chance for you to include a guide or restframework integration code so I can use in my project?

Make DJANGO_FIDO_RP_NAME setting optional even for python-fido >= 0.15. Use RP ID, if RP name is not defined.

Since #21 the makemessages command is broken on JS domain. It needs to be fixed.

attestation.verify (called in Fido2RegistrationView.complete_registration) can raise InvalidData which is unhandled and causes a server error.

This should be handled, logged and somewhat displayed to user.

Right now authenticator can only be assigned to user registering it. It would be useful to allow admins to register authenticators for someone else (through django admin interface).

If there is no Subject Key Identifier in extension, generate it from certificate data:

#!/usr/bin/python3
from cryptography import x509
from cryptography.hazmat.backends import default_backend
import binascii
import sys
der_data = sys.stdin.buffer.read()
issuer_cert = x509.load_der_x509_certificate(der_data, default_backend())
ski_data = x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_cert.public_key())
ski = binascii.hexlify(ski_data.key_identifier)
print(ski)

JS is very basic. It should be updated to provide:

• customization
• style check
• tests

If fetching of the registration request fails (the response is not OK), the JS simply skips the process and does nothing.

In reality, it should probably produce some (helpful) error message, that can be displayed to the user.

We can probably display the content of the error message. If it is empty (can it be?) we should output an unknown error.

Some backends require request argument of authenticate method to be positional, not keyword. It's fundamental flaw in these other backends, but in order to make django_fido more compatible with them, I suggest to make this change which is backwards all the way back to Django 1.11.

We should add a "Settings" section to README with details of individual description of django-fido settings.

Currently, there is an error in MDS where there are two AuthenticatorMetadata object with the same identifier. This should not happen, but there are apparently no safeguards on MDS side, so we should probably handle that on our side as well.

For now, we are ignoring the hash validation (obtained from the TOC) of the downloaded MDS statement.

We should probably validate it.

Certificate validation silences all errors, it should report them instead.

django-fido is incomatible with new version of fido2: https://github.com/Yubico/python-fido2/releases/tag/0.9.0

We should either restrict the version of fido2 dependency or update django-fido to be compatible with fido2 >= 0.9.0.

Right now, rp_name needs to be overrided in some views for django-fido to work. It would be convenient to load rp_name from django settings, allowing to use django-fido views without further customization.

The display of the FIDO 2 errors require the django-fido-errors to be already present in the form. JS should be able to create the element, if it doesn't exist.

XSS vulnerability has been reported for serialize-javascript. It has been patched in version 2.1.1.
Automatic update seems to fail, so manual action is needed.

FIDO registration is throwing NotAllowedError using admin's AuthenticatorAddView in Google Chrome. Chrome asks for the PIN first and then, after correct PIN has been entered, it throws the error.

Registration is working fine in Firefox and the Authentication works fine in both Chrome and Firefox (Chrome is asking for the PIN, Firefox [still having only U2F support] is not).

It seems that this issue appears only when user.displayName is empty. I don't know why Chrome doesn't allow this, but we can fix the issue by using the username as a backup value in case that user.get_full_name() returns empty string.

From django_fido/js/fido2.js:

const submit_button = document.getElementById('submit-button')
// If is empty values, submit button reload page
submit_button.addEventListener('click', e => { … })

When there is no element with id submit-button present on the page, this code fails. I believe that this is valid case and therefore, there should probably be a condition. Even after #33, the code still shouldn't produce errors in JavaScript console.

When the certification for U2F gets extended by adding another attestation certificate, new object is created instead of updating the current one.

Matching of the existing objects has to be changed to match by URL.

In order to simplify work with django-fido, it would be useful if it provided detection whether its authentication backend (or any backend derived from it) is used. This could be a function in django_fido.backends such as:

def is_fido_backend_used() -> bool:
    ...

Add example Django project

Currently the allowed attestation formats cannot be specified during init of fido2.Server.

We should be able to do that.

If we have metadata available, we should be checking that the attestation certificate matches the one in MDS.

Counter should not be checked if it is 0 both in database and in the response. That means, the counter is not supported.

Currently, django-fido can only be used as a second authentication backend if user is already authenticated by some other backend. However, this is not directly usable in any django app without creating some kind of middleware / handler mechanism. It would be great to provide such middleware in django-fido itself.

The middleware will check whether already authenticated user has been authenticated by django_fido.backends.Fido2AuthenticationBackend. If not, it will redirect user to the FIDO2 login page.

We will also add boolean setting DJANGO_FIDO_FORCE_2FA. If this setting is True (default value), FIDO2 authentication will be required for all users. Otherwise, it will be required only for users that have a FIDO2 key associated with their account.

As we are adding a label field in #32, we want users to be actually able to fill that in before the form autosubmits.

The JS code needs to be changed to wait for a submit button.

Blocked by #69

Add optional validation of certificate chain for the metadata service.

We will need openssl library as certificate validation in cryptography is still work in progress. This should be an optional dependency.

Some hints: http://www.yothenberg.com/validate-x509-certificate-in-python/

Fido2ModelAuthenticationBackend is suitable if you want to add one step FIDO2 authentication to already existing ModelBackend authentication. However, if you use any other authentication backend (i.e. LDAP), Fido2ModelAuthenticationBackend won't help you. We should create more general solution that will enable us to add FIDO2 to any existing username–password authentication backend.

django_fido throws numerous warnings about usage of ugettext_lazy:

RemovedInDjango40Warning:
    django.utils.translation.ugettext_lazy() is deprecated in favor of django.utils.translation.gettext_lazy().

We should consider replacing ugettext_lazy with gettext_lazy at earliest convenience.

Metadata Service contains info about the attested security level of devices. We should add the ability to download and parse these and add the relevant information to the registered devices.

If enabled, the authenticator level should be queried for every new device and also on a regular basis to catch changes in certification level.

MDS should be queried on a regular basis and cached in some way (database?)

Design:
AuthLevel(Enum) with members (N, L0, L1, L2, L3, L3+)

AuthenticatorMetadata

• aaguid(UUIDField)
• level(CharField)
• attestation_root_certificate(TextField)

Authenticator:

• level -> method to query the cached MDS results.

New setting: mds_access_token = StringSetting(default=None)

New management command download_authenticator_metadata to download and parse the MDS data.

Form with data-mode=FIDO2_AUTHENTICATION_REQUEST should still have autosubmit.

Registration / authentication errors are just stacking below each other and are never deleted.

We agreed that it would be better if only the errors from the last request were visible.

Based on https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Handle.html

If I understand correctly, currently the Authenticator model stores the user FK, but does not store the userHandle encrypted string, so in the discoverable credential approach we cannot identify the user by using the userHandle provided from the security key.

When metadata verification is performed, intermediate certs present at the device are ignored. Validation thus fails (incorrectly).

In metadata verification, it is possible to define root certificates to verify the device data against it. Some devices include this root in their presented trust chain.

We should ignore error on adding the same certificate twice.

https://fidoalliance.org/metadata/

In Authenticator model, the credential_data are subset of attestation_object. Should be improved.

Just wondering if this package support passwordless single factor?

Am I understanding right that passwordless is just we skip the username+password step and completely rely on the fido2 authentication?

https://aws.amazon.com/blogs/security/how-to-implement-password-less-authentication-with-amazon-cognito-and-webauthn/

The user provides their user name and selects the sign-in button, script (running in browser) starts the sign-in process using Amazon Cognito InitiateAuth API passing the user name and indicating that authentication flow is CUSTOM_AUTH. In the demo project, this part is performed in the signIn function in webauthn-client.js.

When some kind of error occurs on the server side, django-fido simply displays An unknown error has occurred. message.

However, server often sends detailed message about what happened. E.g. when user has no authenticators, server returns status code 404 with response:

{"error": "Can't create FIDO 2 authentication request, no authenticators."}

This message would be much more helpful for the user. It's necessary to handle the translations as well.