johnraz ( Jonathan Liuti )

No. Only a prefix and hash (and previously salt) are stored in the db. The whole point is that an attacker will be unable to calculate the token even if they get a copy of the DB.

so that I can use a non-expiring token for my client facing API keys?

You can configure knox for non-expiring tokens.

REST_KNOX = {
    "TOKEN_TTL": None,
}

steverecio

comment created time in 15 days

issue commentJames1345/django-rest-knox

Migrating from rest_framework.TokenAuthentication without logging users out

Something like this would work:

from django.db import migrations
from knox import crypto
from knox.settings import CONSTANTS


def convert_tokens(apps, schema_editor):
    Token = apps.get_model("authtoken", "token")
    AuthToken = apps.get_model("knox", "authtoken")
    db_alias = schema_editor.connection.alias

    for token in Token.objects.using(db_alias).all():
        digest = crypto.hash_token(token.key)
        # bypass custom manager
        AuthToken.objects.using(db_alias).bulk_create(
            [
                AuthToken(
                    digest=digest,
                    token_key=token.key[: CONSTANTS.TOKEN_KEY_LENGTH],
                    user_id=token.user_id,
                    expiry=None,  # or whatever logic you want
                )
            ]
        )
        # bypass auto_now_add restriction
        AuthToken.objects.using(db_alias).filter(digest=digest).update(
            created=token.created
        )

    Token.objects.using(db_alias).all().delete()


class Migration(migrations.Migration):

    dependencies = [
        ("knox", "0008_remove_authtoken_salt"),
    ]

    operations = [migrations.RunPython(convert_tokens)]

(keep in mind this is for the latest unreleased version of knox where the salt has been removed from AuthToken)

Remove "rest_framework.authentication.TokenAuthentication" from your views and default authentication, but keep both "rest_framework.authtoken" and "knox" in INSTALLED_APPS until the migration has run everywhere.

oaosman84

comment created time in 15 days

issue openedJames1345/django-rest-knox

token_key isn't needed if salt is gone and hashing function is secure

We could remove token_key and directly filter the DB by digest during authentication.

With the salt gone, I think there are only 2 reasons to search the DB by token_key before matching digests.

If there isn't a matching token_key, the webserver avoids calculating the digest.
hmac.compare_digest prevents timing attacks being used to calculate the digest. Timing attacks can calculate the token_key, but not the digest.

1 shouldn't matter for denial of service attacks because a DB call is being made either way. Webservers can scale until the hash is no longer the limiting factor. Or an attacker could find a token_key that exists in the db and start forcing a hash (or potentially multiple, with the current implementation) for each request.

2 shouldn't matter because it would require a near-fully-reversed hashing function just to calculate the tokens needed to continue the timing attack. To calculate the 20th character of the hash, they'd need to calculate 16 different tokens with the same 19-character start to the hash. And once they finally calculated the token's hash, they'd need to reverse that to get a token that could actually be used for authentication.

created time in 15 days

startedhypercore-protocol/hyperspace-client

started time in 15 days

startedfsteff/hyperpubsub

started time in 15 days

startedsocketio/socket.io-adapter

started time in 15 days

startedLog1x/acf-composer

started time in 18 days