Se frayer un chemin dans SHA512 en utilisant un sel? - Python

il suffit d'ajouter le sel à vos données sensibles:

>>> import hashlib
>>> m = hashlib.sha512()
>>> m.update('salt')
>>> m.update('sensitive data')
>>> m.hexdigest()
'70197a4d3a5cd29b62d4239007b1c5c3c0009d42d190308fd855fc459b107f40a03bd427cb6d87de18911f21ae9fdfc24dadb0163741559719669c7668d7d587'
>>> n = hashlib.sha512()
>>> n.update('%ssensitive data' % 'salt')
>>> n.hexdigest()
'70197a4d3a5cd29b62d4239007b1c5c3c0009d42d190308fd855fc459b107f40a03bd427cb6d87de18911f21ae9fdfc24dadb0163741559719669c7668d7d587'
>>> hashlib.sha512('salt' + 'sensitive data').hexdigest()
'70197a4d3a5cd29b62d4239007b1c5c3c0009d42d190308fd855fc459b107f40a03bd427cb6d87de18911f21ae9fdfc24dadb0163741559719669c7668d7d587'

le salage n'est pas un processus magique dont la bibliothèque a besoin pour vous aider-c'est juste des données supplémentaires fournies pour empêcher les tables arc-en-ciel de fonctionner.

>>> import hashlib
>>> m = hashlib.sha512()
>>> m.update(b"Nobody inspects")
>>> m.update(b" the spammish repetition")
>>> m.digest()
b'\xd0\xf4\xc1LH\xadH7\x90^\xa7R\x0c\xc4\xafp\x0fd3\xce\t\x85\xe6\xbb\x87\xb6\xb4a|\xb9D\xab\xf8\x14\xbdS\x96M\xdb\xf5[A\xe5\x81+:\xfe\x90\x89\x0c\nM\xb7\\xb0Cg\xe19\xfdb\xea\xb2\xe1'
>>> m.update(b"My super-secret salt.")
>>> m.digest()
b'\xcd\xd7K\xd9!~\xa8\x1d6\x9b\xa6\xde\x06\t\x02\xa1+}\xaeNA\x94a`\xaa\xf4\xe9\xb5\xff\x1f\x9cE\x84m\xbb\x98U\xb4z\x92\x9e\xe8\xc9\xc2\xc8\x8f\x068e\xb0\r\xed\xb7\xde\x80\xa6,\n\x111w{\xa2\x9b'

si vous cherchez un remplacement pour crypt(), les nouvelles versions de glibc ont basé sur SHA-512 "$6$" avec un nombre d'itérations variable (voir Ulrich Drepper de la page, qui contient une description et des liens vers la mise en oeuvre complète de sha512_crypt_r()).

L'écriture de votre propre crypto est fortement déconseillée - le ci-dessus sha512(salt+password) n'aide pas contre une attaque brutale.

pour produire du sel, utilisez quelque chose comme os.urandom(16) pour les octets aléatoires ou ''.join(map(lambda x:'./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'[ord(x)%64], os.urandom(16))) pour aléatoire base64-shared (pour utilisation avec crypt () - alikes).

(je dis en base64, comme ce n'est pas le même que le Base64 dans PEM/MIME.)

utilisez passlib, l'écriture de votre propre mot de passe crypto est un moyen presque sûr de l'échec.

SHA512 n'est pas une bonne façon de stocker les mots de passe cryptés de nos jours. Vous devriez utiliser bcrypt ou quelque chose de similaire. Ce qui est important, c'est que le salage est intégré et que l'algorithme a un important facteur de travail.

si vous salez vos mots de passe SHA512 simplement en ajoutant (ou en préprogrammant) le sel au texte clair, toute personne qui obtient leurs mains sur un ensemble de vos mots de passe hachés et applique un outil de fissuration moderne (http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/) sera en mesure de voir les valeurs concaténées mot de passe+sel et sera probablement, par le biais de trivial pattern matching, capable de séparer la partie mot de passe de la partie sel pour la plupart sinon tous les comptes en question.

Je n'ai pas réfléchi à tout cela jusqu'au bout, et je ne suis pas du tout un expert en sécurité, mais il me semble que si vous deviez chiffrer (en utilisant, pour exemple, AES256) le mot de passe en utilisant le sel comme clé, puis hachage avec SHA512, vous seriez à l'abri de la vulnérabilité que je viens de décrire.

cependant, à ce moment-là, vous avez fait plus d'efforts qu'il n'aurait fallu pour passer à bcrypt et vous n'auriez toujours pas la protection d'un facteur de travail, donc je ne recommanderais une approche comme ça que si l'environnement dans lequel vous travaillez n'offre pas cette option.