Gerenciamento de senhas no Django

O gerenciamento de senha é algo que não deve ser reinventado desnecessariamente, e o Django se esforça para fornecer um conjunto de ferramentas seguras e flexíveis para gerenciar senhas de usuários. Este documento descreve como o Django armazena senhas, como o armazenamento de “hashes” pode ser configurado, e algumas utilidade para trabalhar com senhas criptografadas.

Ver também

Mesmo que os usuários usem senha fortes, ataques podem ser capazes de bisbilhotar suas conexões. Use conexões HTTPS para evitar o envio de senhas (ou qualquer outro dado sensível) sobre conexões HTTP porque eles estarão vulneráveis a sequestros de senhas.

Como o Django armazena as senhas

O Django fornece um sistema flexível de armazenamento de senhas e usa PBKDF2 por padrão.

O atributo password de um objeto User é uma string nesse formato:

<algorithm>$<iterations>$<salt>$<hash>

Estes são os componentes usados para armazenamento de senha do “User”, separados pelo caracter de sinal do dólar e consistem em: o algoritmo de “hash”, o número de iterações do algoritmo (fator de trabalho), o “salt” randômico, e o “hash” de senha resultante. O algoritmo é um dos vários algoritmos “hash” de via única ou de armazenamento de senha que o Django pode usar; veja abaixo. O iterações descreve o número de vezes que o algoritmo é executado sobre o “hash”. “Salt” é a string randômica inicial usada e o “hash” é o resultado da função de via única.

Por padrão, Django usa o algoritmo PBKDF2 com um hash SHA256, um mecanismo de elasticidade de senha recomendado pelo NIST. Isso deve ser suficiente para a maior parte dos usuários: é bastante seguro, e requer quantidades massivas de tempo computacional para quebrar.

Contudo, dependendo das suas necessidades, você pode escolher um algoritmo diferente, ou até mesmo usar um algoritmo customizado para suprir suas necessidades específicas de segurança. Novamente, a maioria dos usuários não precisam disso – se você não tem certeza, provavelmente não precisa. Se você precisa, por favor, leia:

Django escolhe o algoritmo para usar consultando a configuração :setting:’PASSWORD_HASHERS’. Essa é uma lista de classes de algoritmos hash que essa instalação Django suporta. A primeira entrada nessa lista (ou seja, settings.PASSWORD_HASHERS[0]) será usada para armazenar senhas, e todas as outras entradas são hashers válidos que podem ser usados para checar senhas existentes. Isso significa que, se você quiser usar um algoritmo diferente, precisará modificar PASSWORD_HASHERS para listar seu algoritmo preferido como primeira entrada na lista.

O padrão para PASSWORD_HASHERS é:

PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
    'django.contrib.auth.hashers.ScryptPasswordHasher',
]

Isso significa que o Django vai usar o PBKFD2 para armazenar todas as senhas, mas vai suportar a conferência de senhas armazenadas com PBKDF2SHA1, argon2, and bcrypt.

As próximas seções descreverão jeitos comuns que usuários avançados podem querer usar para modificar essas configurações.

Usando Argon2 com Django

Argon2 é o campeão 2015 da ‘Competição de Senhas Hashing’_ uma competição aberta organizada organizada pela comunidade para eleger a próxima geração de algoritmo hashing. É um algoritmo projetado para não ser mais fácil de computar num hardware customizado do que é em um CPU normal.

Argon2 não é o padrão do Django porque precisa de uma biblioteca de terceiros. A equipe da Competição de Senhas Hashing, contudo, recomenda o uso imediato de Argon2 em vez de outros algoritmos suportados pelo Django.

Para usar Argon2 como seu algoritmo de armazenamento padrão, faça o seguinte:

  1. Install the argon2-cffi library. This can be done by running python -m pip install django[argon2], which is equivalent to python -m pip install argon2-cffi (along with any version requirement from Django’s setup.cfg).

  2. Modificar PASSWORD_HASHERS`para listar primeiro ``Argon2PasswordHasher. Ou seja, no seu arquivo de configurações, você colocaria:

    PASSWORD_HASHERS = [
        'django.contrib.auth.hashers.Argon2PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
        'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
        'django.contrib.auth.hashers.ScryptPasswordHasher',
    ]
    

    Mantenha ou adicione quaisquer entradas nessa lista se você precisa que o Django atualize senhas.

Usando bcrypt com Django

Bcrypt é um algoritmo popular de armazenamento de senhas que é especificamente desenhado para armazenamento de senhas de longo prazo. Não é o padrão utilizado pelo Django porque requer uso de bibliotecas de terceiros, mas, já que muita gente pode querer usá-lo, Django suporta o o Bcrypt com mínimo esforço.

Para utilizar Bcrypt como seu algoritmo de armazenamento padrão, faça o seguinte:

  1. Install the bcrypt library. This can be done by running python -m pip install django[bcrypt], which is equivalent to python -m pip install bcrypt (along with any version requirement from Django’s setup.cfg).

  2. Modifique PASSWORD_HASHERS para listar primeiro BCryptSHA256PasswordHasher. Ou seja, no seu arquivo de configurações, você colocará:

    PASSWORD_HASHERS = [
        'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
        'django.contrib.auth.hashers.Argon2PasswordHasher',
        'django.contrib.auth.hashers.ScryptPasswordHasher',
    ]
    

    Mantenha ou adicione quaisquer entradas nessa lista se você precisa que o Django atualize senhas.

É isso - agora a sua instalação do Django usará Bcrypt como o algoritmo de armazenamento padrão.

Using scrypt with Django

New in Django 4.0.

scrypt is similar to PBKDF2 and bcrypt in utilizing a set number of iterations to slow down brute-force attacks. However, because PBKDF2 and bcrypt do not require a lot of memory, attackers with sufficient resources can launch large-scale parallel attacks in order to speed up the attacking process. scrypt is specifically designed to use more memory compared to other password-based key derivation functions in order to limit the amount of parallelism an attacker can use, see RFC 7914 for more details.

To use scrypt as your default storage algorithm, do the following:

  1. Modify PASSWORD_HASHERS to list ScryptPasswordHasher first. That is, in your settings file:

    PASSWORD_HASHERS = [
        'django.contrib.auth.hashers.ScryptPasswordHasher',
        'django.contrib.auth.hashers.PBKDF2PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
        'django.contrib.auth.hashers.Argon2PasswordHasher',
        'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
    ]
    

    Mantenha ou adicione quaisquer entradas nessa lista se você precisa que o Django atualize senhas.

Nota

scrypt requires OpenSSL 1.1+.

Increasing the salt entropy

New in Django 3.2.

Most password hashes include a salt along with their password hash in order to protect against rainbow table attacks. The salt itself is a random value which increases the size and thus the cost of the rainbow table and is currently set at 128 bits with the salt_entropy value in the BasePasswordHasher. As computing and storage costs decrease this value should be raised. When implementing your own password hasher you are free to override this value in order to use a desired entropy level for your password hashes. salt_entropy is measured in bits.

Implementation detail

Due to the method in which salt values are stored the salt_entropy value is effectively a minimum value. For instance a value of 128 would provide a salt which would actually contain 131 bits of entropy.

Aumentando o fator de trabalho

PBKDF2 e bcrypt

The PBKDF2 and bcrypt algorithms use a number of iterations or rounds of hashing. This deliberately slows down attackers, making attacks against hashed passwords harder. However, as computing power increases, the number of iterations needs to be increased. We’ve chosen a reasonable default (and will increase it with each release of Django), but you may wish to tune it up or down, depending on your security needs and available processing power. To do so, you’ll subclass the appropriate algorithm and override the iterations parameter (use the rounds parameter when subclassing a bcrypt hasher). For example, to increase the number of iterations used by the default PBKDF2 algorithm:

  1. Criar uma subclasse de django.contrib.auth.hashers.PBKDF2PasswordHasher:

    from django.contrib.auth.hashers import PBKDF2PasswordHasher
    
    class MyPBKDF2PasswordHasher(PBKDF2PasswordHasher):
        """
        A subclass of PBKDF2PasswordHasher that uses 100 times more iterations.
        """
        iterations = PBKDF2PasswordHasher.iterations * 100
    

    Salve isso em algum lugar no seu projeto. Por exemplo, você pode coloca-lo em um arquivo como meuprojeto/hashers.py.

  2. Adicione seu novo hasher como a primeira entrada em: setting:PASSWORD_HASHERS:

    PASSWORD_HASHERS = [
        'myproject.hashers.MyPBKDF2PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2PasswordHasher',
        'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
        'django.contrib.auth.hashers.Argon2PasswordHasher',
        'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
        'django.contrib.auth.hashers.ScryptPasswordHasher',
    ]
    

É isso – agora seu Django install usará mais iterações ao armazenar senhas usando PBKDF2.

Nota

bcrypt rounds is a logarithmic work factor, e.g. 12 rounds means 2 ** 12 iterations.

Argon2

Argon2 tem três atributos que podem ser personalizados:

  1. time_cost controla o número de iterações dentro do hash.
  2. memory_cost controla o tamanho da memória que deve ser usada durante a computação do hash.
  3. parallelism controla quantas CPUs podem ser paralelizadas na computação do hash.

Os valores padrão desses atributos provavelmente estarão bons para você. Se você determinar que o seu hash de senha está muito rápido ou muito lento, você pode ajusta-lo como segue:

  1. Escolha parallelism para ser o número de threads que você pode disponibilizar para computar o hash.
  2. Escolha memory_cost para ser o quanto de memória em KiB que você pode disponibilizar.
  3. Ajuste time_cost e meça o tempo gasto para gerar o hash de uma senha. Escolha um time_cost que tome um tempo aceitável para você. Se time_cost configurado para 1 for inaceitavelmente lento para você, reduza time_cost.

memory_cost interpretação

O utilitário de linha de comando argon2 e algumas outras bibliotecas interpretam o parâmetro memory_cost diferentemente do valor que Django usa. A conversão é dada por memory_cost == 2 ** memory_cost_commandline.

scrypt

New in Django 4.0.

scrypt has four attributes that can be customized:

  1. work_factor controls the number of iterations within the hash.
  2. block_size
  3. parallelism controls how many threads will run in parallel.
  4. maxmem limits the maximum size of memory that can be used during the computation of the hash. Defaults to 0, which means the default limitation from the OpenSSL library.

We’ve chosen reasonable defaults, but you may wish to tune it up or down, depending on your security needs and available processing power.

Estimating memory usage

The minimum memory requirement of scrypt is:

work_factor * 2 * block_size * 64

so you may need to tweak maxmem when changing the work_factor or block_size values.

Atualização de senha

Quando usuários entram, se suas senhas estão armazenadas com qualquer outra coisa que não o o algoritmo preferido, Django atualizará automaticamente o algoritmo para o preferido. Isto significa que instalações antigas de Django ficarão mais seguras a medida que os usuários entram, isso também significa que você pode mudar para novos (e melhores) algoritmos de armazenamento quando eles forem inventados.

However, Django can only upgrade passwords that use algorithms mentioned in PASSWORD_HASHERS, so as you upgrade to new systems you should make sure never to remove entries from this list. If you do, users using unmentioned algorithms won’t be able to upgrade. Hashed passwords will be updated when increasing (or decreasing) the number of PBKDF2 iterations, bcrypt rounds, or argon2 attributes.

Esteja ciente que se nem todas as senhas armazenadas em seu banco de dados estiverem codificadas através do algoritmo padrão de hash, você pode estar vulnerável a ataques de enumeração de usuários baseado em tempo devido a uma diferença entre a duração do pedido de login para um usuário com uma senha codificada por um algoritmo não-padrão e a duração de um pedido de login para um usuário inexistente (o qual roda o hash padrão). Você pode ser capaz de mitigar isso:ref:atualizando hashes de senhas mais antigos <wrapping-password-hashers>.

Atualização de senha sem exigência de login

Se você tem um banco de dados existente com um hash mais antigo e fraco, tal como MD5 ou SHA1, você pode desejar atualizar esses hashes você mesmo em vez de esperar que a atualização aconteça quando um usuário faça login (o que pode nunca acontecer se um usuário não voltar ao seu site). Neste caso você pode utilizar um hasher de senha “envolta”.

Para esse exemplo, vamos migrar a coleção de hashes SHA1 para usar PBKDF2(SHA1(password)) e adicionar o hasher de senha correspondente para checar se um usuário inserir a senha correta no login. Vamos assumir que estamos usando o modelo User padrão e o nosso projeto tem uma aplicação contas. Você pode modificar o padrão para trabalhar com qualquer algoritmo ou com um modelo de usuário customizado.

Primeiro, vamos adicionar um hasher customizado:

accounts/hashers.py
from django.contrib.auth.hashers import (
    PBKDF2PasswordHasher, SHA1PasswordHasher,
)


class PBKDF2WrappedSHA1PasswordHasher(PBKDF2PasswordHasher):
    algorithm = 'pbkdf2_wrapped_sha1'

    def encode_sha1_hash(self, sha1_hash, salt, iterations=None):
        return super().encode(sha1_hash, salt, iterations)

    def encode(self, password, salt, iterations=None):
        _, _, sha1_hash = SHA1PasswordHasher().encode(password, salt).split('$', 2)
        return self.encode_sha1_hash(sha1_hash, salt, iterations)

A migração pode parecer algo como:

accounts/migrations/0002_migrate_sha1_passwords.py
from django.db import migrations

from ..hashers import PBKDF2WrappedSHA1PasswordHasher


def forwards_func(apps, schema_editor):
    User = apps.get_model('auth', 'User')
    users = User.objects.filter(password__startswith='sha1$')
    hasher = PBKDF2WrappedSHA1PasswordHasher()
    for user in users:
        algorithm, salt, sha1_hash = user.password.split('$', 2)
        user.password = hasher.encode_sha1_hash(sha1_hash, salt)
        user.save(update_fields=['password'])


class Migration(migrations.Migration):

    dependencies = [
        ('accounts', '0001_initial'),
        # replace this with the latest migration in contrib.auth
        ('auth', '####_migration_name'),
    ]

    operations = [
        migrations.RunPython(forwards_func),
    ]

Tenha cuidado que essa migração deve ser tomará uma ordem de vários minutos para milhares de usuários, dependendo da velocidade do seu hardware.

Finalmente, vamos adicionar a configuração PASSWORD_HASHERS:

mysite/settings.py
PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'accounts.hashers.PBKDF2WrappedSHA1PasswordHasher',
]

Inclua quaisquer outros hashers que seu site usa nessa lista.

Hashers incluídos

A lista completa de hashers incluídas no Django são:

[
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
    'django.contrib.auth.hashers.BCryptPasswordHasher',
    'django.contrib.auth.hashers.ScryptPasswordHasher',
    'django.contrib.auth.hashers.SHA1PasswordHasher',
    'django.contrib.auth.hashers.MD5PasswordHasher',
    'django.contrib.auth.hashers.UnsaltedSHA1PasswordHasher',
    'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
    'django.contrib.auth.hashers.CryptPasswordHasher',
]

Os nomes de algoritmos correspondentes são:

  • pbkdf2_sha256
  • pbkdf2_sha1
  • argon2
  • bcrypt_sha256
  • bcrypt
  • scrypt
  • sha1
  • md5
  • unsalted_sha1
  • unsalted_md5
  • crypt

Escrevendo seu próprio hasher

If you write your own password hasher that contains a work factor such as a number of iterations, you should implement a harden_runtime(self, password, encoded) method to bridge the runtime gap between the work factor supplied in the encoded password and the default work factor of the hasher. This prevents a user enumeration timing attack due to difference between a login request for a user with a password encoded in an older number of iterations and a nonexistent user (which runs the default hasher’s default number of iterations).

Taking PBKDF2 as example, if encoded contains 20,000 iterations and the hasher’s default iterations is 30,000, the method should run password through another 10,000 iterations of PBKDF2.

If your hasher doesn’t have a work factor, implement the method as a no-op (pass).

Manually managing a user’s password

The django.contrib.auth.hashers module provides a set of functions to create and validate hashed passwords. You can use them independently from the User model.

check_password(password, encoded)

If you’d like to manually authenticate a user by comparing a plain-text password to the hashed password in the database, use the convenience function check_password(). It takes two arguments: the plain-text password to check, and the full value of a user’s password field in the database to check against, and returns True if they match, False otherwise.

make_password(password, salt=None, hasher='default')

Creates a hashed password in the format used by this application. It takes one mandatory argument: the password in plain-text (string or bytes). Optionally, you can provide a salt and a hashing algorithm to use, if you don’t want to use the defaults (first entry of PASSWORD_HASHERS setting). See Hashers incluídos for the algorithm name of each hasher. If the password argument is None, an unusable password is returned (one that will never be accepted by check_password()).

is_password_usable(encoded_password)

Returns False if the password is a result of User.set_unusable_password().

Validação de senha

Users often choose poor passwords. To help mitigate this problem, Django offers pluggable password validation. You can configure multiple password validators at the same time. A few validators are included in Django, but you can write your own as well.

Each password validator must provide a help text to explain the requirements to the user, validate a given password and return an error message if it does not meet the requirements, and optionally receive passwords that have been set. Validators can also have optional settings to fine tune their behavior.

Validation is controlled by the AUTH_PASSWORD_VALIDATORS setting. The default for the setting is an empty list, which means no validators are applied. In new projects created with the default startproject template, a set of validators is enabled by default.

By default, validators are used in the forms to reset or change passwords and in the createsuperuser and changepassword management commands. Validators aren’t applied at the model level, for example in User.objects.create_user() and create_superuser(), because we assume that developers, not users, interact with Django at that level and also because model validation doesn’t automatically run as part of creating models.

Nota

Validação de senha pode previnir que o usuário utilize muitos tipos de senhas fracas. No entanto, o fato de uma senha passar em todos os validadores não garante que a senha é forte. Existem muitos outros fatores que podem enfraquecer uma senha que não é detectado nem mesmo pelos validadores de senha mais avançados.

Habilitando validação de senha

A validação de senha é configurada utilizando a variável AUTH_PASSWORD_VALIDATORS:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 9,
        }
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

Este exemplo habilita todos os quatro validadores incluídos:

  • UserAttributeSimilarityValidator, que verifica a similaridade entre a senha e um conjunto de atributos do usuário.
  • MinimumLengthValidator, which checks whether the password meets a minimum length. This validator is configured with a custom option: it now requires the minimum length to be nine characters, instead of the default eight.
  • CommonPasswordValidator, which checks whether the password occurs in a list of common passwords. By default, it compares to an included list of 20,000 common passwords.
  • NumericPasswordValidator, que verifica se a senha não é completamente numérica.

For UserAttributeSimilarityValidator and CommonPasswordValidator, we’re using the default settings in this example. NumericPasswordValidator has no settings.

Os textos de ajuda e qualquer erro dos validadores de senha sempre retornam na ordem que eles foram listados no AUTH_PASSWORD_VALIDATORS.

Validadores incluídos

Django inclui quatro validadores:

class MinimumLengthValidator(min_length=8)

Valida se a senha possui um tamanho mínimo. O tamanho mínimo pode ser customizado com o parâmetro min_length.

class UserAttributeSimilarityValidator(user_attributes=DEFAULT_USER_ATTRIBUTES, max_similarity=0.7)

Valida se a senha é suficientemente diferente dos atributos do usuário.

O parâmetro user_attributes deve ser um iterável de nomes de atributos de usuário para serem comparados. Se este argumento não for fornecido, o padrão será utilizado: 'username', 'first_name', 'last_name', 'email'. Atributos que não existem são ignorados.

The maximum allowed similarity of passwords can be set on a scale of 0.1 to 1.0 with the max_similarity parameter. This is compared to the result of difflib.SequenceMatcher.quick_ratio(). A value of 0.1 rejects passwords unless they are substantially different from the user_attributes, whereas a value of 1.0 rejects only passwords that are identical to an attribute’s value.

Changed in Django 2.2.26:

The max_similarity parameter was limited to a minimum value of 0.1.

class CommonPasswordValidator(password_list_path=DEFAULT_PASSWORD_LIST_PATH)

Validates whether the password is not a common password. This converts the password to lowercase (to do a case-insensitive comparison) and checks it against a list of 20,000 common password created by Royce Williams.

The password_list_path can be set to the path of a custom file of common passwords. This file should contain one lowercase password per line and may be plain text or gzipped.

class NumericPasswordValidator

Validates whether the password is not entirely numeric.

Integrating validation

There are a few functions in django.contrib.auth.password_validation that you can call from your own forms or other code to integrate password validation. This can be useful if you use custom forms for password setting, or if you have API calls that allow passwords to be set, for example.

validate_password(password, user=None, password_validators=None)

Validates a password. If all validators find the password valid, returns None. If one or more validators reject the password, raises a ValidationError with all the error messages from the validators.

The user object is optional: if it’s not provided, some validators may not be able to perform any validation and will accept any password.

password_changed(password, user=None, password_validators=None)

Informs all validators that the password has been changed. This can be used by validators such as one that prevents password reuse. This should be called once the password has been successfully changed.

For subclasses of AbstractBaseUser, the password field will be marked as “dirty” when calling set_password() which triggers a call to password_changed() after the user is saved.

password_validators_help_texts(password_validators=None)

Returns a list of the help texts of all validators. These explain the password requirements to the user.

password_validators_help_text_html(password_validators=None)

Returns an HTML string with all help texts in an <ul>. This is helpful when adding password validation to forms, as you can pass the output directly to the help_text parameter of a form field.

get_password_validators(validator_config)

Returns a set of validator objects based on the validator_config parameter. By default, all functions use the validators defined in AUTH_PASSWORD_VALIDATORS, but by calling this function with an alternate set of validators and then passing the result into the password_validators parameter of the other functions, your custom set of validators will be used instead. This is useful when you have a typical set of validators to use for most scenarios, but also have a special situation that requires a custom set. If you always use the same set of validators, there is no need to use this function, as the configuration from AUTH_PASSWORD_VALIDATORS is used by default.

The structure of validator_config is identical to the structure of AUTH_PASSWORD_VALIDATORS. The return value of this function can be passed into the password_validators parameter of the functions listed above.

Note that where the password is passed to one of these functions, this should always be the clear text password - not a hashed password.

Escrevendo seu próprio validador

If Django’s built-in validators are not sufficient, you can write your own password validators. Validators have a fairly small interface. They must implement two methods:

  • validate(self, password, user=None): validate a password. Return None if the password is valid, or raise a ValidationError with an error message if the password is not valid. You must be able to deal with user being None - if that means your validator can’t run, return None for no error.
  • get_help_text(): provide a help text to explain the requirements to the user.

Any items in the OPTIONS in AUTH_PASSWORD_VALIDATORS for your validator will be passed to the constructor. All constructor arguments should have a default value.

Here’s a basic example of a validator, with one optional setting:

from django.core.exceptions import ValidationError
from django.utils.translation import gettext as _

class MinimumLengthValidator:
    def __init__(self, min_length=8):
        self.min_length = min_length

    def validate(self, password, user=None):
        if len(password) < self.min_length:
            raise ValidationError(
                _("This password must contain at least %(min_length)d characters."),
                code='password_too_short',
                params={'min_length': self.min_length},
            )

    def get_help_text(self):
        return _(
            "Your password must contain at least %(min_length)d characters."
            % {'min_length': self.min_length}
        )

You can also implement password_changed(password, user=None), which will be called after a successful password change. That can be used to prevent password reuse, for example. However, if you decide to store a user’s previous passwords, you should never do so in clear text.