Melhor prática na geração de tokens de senha de reinicialização

Question

Qualquer melhor prática sobre como um token de senha de reinicialização deve ser construído?Estou pensando:

Aleatório 17 caracteres [a-za-z0-9] + um ID Globalmente exclusivo + 17 caracteres [a-za-z0-9].

Existe uma solução melhor, ou um padrão da indústria em redefinir tokens de senha?

Answer 1

Existem alguns pontos importantes a serem considerados.

.
1. O código deve ser realmente aleatório (lido de mcrypt_dev_urandom), e não deve ser derrivado de outras informações relacionadas ao usuário.
2. Idealmente o código é base62 codificado (A-Z A-Z 0-9) para evitar problemas com o URL.
3. lojas somente um hash do token no banco de dados , caso contrário, um invasor com acesso de leitura ao banco de dados pode redefinir qualquer conta.

Isso leva ao problema que você tem que encontrar o hash do token no banco de dados, depois que o usuário clicou no link. Existem duas maneiras possíveis de armazenar o token:

• você hash o token com um algoritmo hash como sha512 sem sal. Isso é seguro se o token for muito forte (tamanho mínimo 20 com 0-9 a-z A-Z). Teoricamente, você precisa verificar se tal hash já existe antes de inseri-lo no banco de dados, na prática, isso é insignificante. Eu implementei um Classe de redefinição de senha que pode lidar com tais tokens.
• você hash o token com bcrypt e sal. Isso permite tokens mais curtos, mas você não pode procurar o token do Hashed no banco de dados. Em vez disso, você precisa incluir uma linha de linha no link para encontrar o token.