Comment utiliser scrypt pour générer du hash pour mot de passe et sel en Python

vous avez raison - les fonctions scrypt que ces deux liens utilisent sont l'utilitaire de chiffrement de fichier scrypt, et non le kdf sous-jacent. J'ai travaillé lentement sur la création d'un hachage de mot de passe autonome basé sur scrypt pour python, et j'ai rencontré ce problème moi-même.

l'utilitaire de fichier scrypt effectue ce qui suit: sélectionne les paramètres n/r/p de scrypt spécifiques à votre système et le paramètre" min time". Il génère alors un sel de 32 octets, puis appelle scrypt(n,r,p,salt,pwd) pour créer une clé de 64 octets. La chaîne binaire que l'outil retourne est composée de: 1) un en-tête contenant n, r, p valeurs, et le sel encodé en binaire; 2) une somme de contrôle sha256 de l'en-tête; et 3) une copie signée hmac-sha256 de la somme de contrôle, en utilisant les 32 premiers octets de la clé. Par la suite, il utilise les 32 octets restants de la clé pour chiffrer les données d'entrée.

il y a quelques implications de ceci que je peux voir:

1. le les données d'entrée n'ont pas de sens, car elles n'affectent pas réellement le sel utilisé, et encrypt() génère un nouveau sel à chaque fois.

2. vous ne pouvez pas configurer la charge de travail n,r,p manuellement, ou de toute autre manière, sauf le paramètre embarrassant min-time. il ne s'agit pas d'insécurité, mais d'une façon plutôt maladroite de contrôler le facteur travail.

3. après que l'appel de décryptage régénère la clé et la compare avec le hmac, il sera rejeter tout ce qui est juste si votre mot de passe est erroné - mais si c'est juste, il passera à aussi décrypter le paquet de données. C'est beaucoup de travail supplémentaire, l'attaquant n'aurez pas à effectuer - ils n'ont même pas de dériver de 64 octets, seulement 32 pour vérifier la signature. Ce problème ne le rend pas incertain exactement, mais faire du travail que votre attaquant ne fait pas n'est jamais souhaitable.

4. il n'y a pas façon de configurer la clé salt, La Taille de clé dérivée, etc. les valeurs actuelles ne sont pas si mauvaises, mais quand même, ce n'est pas idéal.

5. la limitation" max time " de l'utilitaire de décryptage est incorrecte pour le hachage de mot de passe - chaque fois que le décryptage est appelé, il estime la vitesse de votre système, et fait quelques "deviner" quant à savoir si elle peut calculer la clé dans le temps max - qui est plus au-dessus de votre attaquant ne doit pas faire( voir #3), mais il signifie également decrypt pourrait commencer à rejeter les mots de passe sous une lourde charge système.

6. Je ne suis pas sûr pourquoi Colin Percival n'a pas fait le KDF & parameter-choosing code partie de l'api publique, mais il est en fait explicitement marqué "privé" à l'intérieur du code source - pas même exporté pour le lien. Cela me fait hésiter à y accéder directement sans beaucoup plus d'étude.

dans l'Ensemble, ce qui il faut un format de hachage agréable qui peut stocker scrypt, et une implémentation qui expose le kdf sous-jacent et l'algorithme de choix des paramètres. J'y travaille actuellement moi-même pour passlib , mais il n'a pas vu beaucoup d'attention : (

juste pour faire court - les instructions de ce site sont "ok", j'utiliserais juste une chaîne vide comme le contenu du fichier, et être conscient des frais généraux supplémentaires et les problèmes.