Puis-je stocker des mots de passe hachés?

Question

La flickr API d'authentification est décrite ici:

http://www.flickr.com/services/api/auth.spec.html

J'ai mis en place quelque chose de très similaire pour un protocole XML-RPC, pour autoriser les demandes de signature sans utiliser SSL.

Il fonctionne essentiellement comme suit:

Pour un appel de fonction à distance

doSomething(foo='hello', bar='world') 

Je premier argument de tri par nom, ce qui donne:

('bar', 'world'), ('foo', 'hello') 

je concaténer la chaîne:

m = "bar:world;foo:hello" 

alors j'append la clé secrète:

m = "bar:world;foo:hello;someSecret" 

et enfin la signature est un hachage md5 du message m.

Le même processus est effectué sur le serveur pour vérifier si celui qui a appelé la fonction connaissait réellement la clé secrète.

Pour l'instant, les mots de passe sont stockés en texte brut côté serveur. Existe-t-il un moyen de stocker les mots de passe hachés à la place? Je pense que la fonction de hachage MD5 manque d'additivité pour que cela soit possible, mais peut-être peut-il encore être réalisé par une construction intelligente?

Merci,

Answer 1

Courte réponse: pratiquement parlant, non. Réponse longue: Hacher le mot de passe à chaque extrémité n'aide pas, car le hachage du mot de passe peut maintenant être utilisé par l'attaquant pour s'authentifier. Voir this section dans l'article wikipedia sur l'authentification Challenge-Réponse pour plus de détails.

sont des algorithmes qui vous permettent de vérifier le mot de passe de l'utilisateur sans qu'il vous le fournisse ou le stocke, connu sous le nom Zero Knowledge Password Proof. Un exemple est le Secure Remote Password Protocol. De tels protocoles ont tendance à être complexes, cependant, et en mettre un en œuvre soi-même est compliqué et probablement imprudent.

Une solution plus simple consiste à utiliser la cryptographie à clé publique et à émettre les clés privées de vos utilisateurs dont vous connaissez la partie publique. Ils peuvent ensuite signer leurs messages pour s'authentifier et s'identifier. SSL/TLS fournit des implémentations prêtes à l'emploi.

Answer 2

D'abord, je suggère le déplacement hors de MD5 à une fonction de hachage plus forte, comme la famille SHA2. Cela dit, rien ne vous empêche d'utiliser la même construction que ci-dessus, où "someSecret" est en fait un hachage du mot de passe. Cela vous obligera à effectuer deux opérations de hachage sur le client et une sur le serveur, tout en conservant le mot de passe hashed en mémoire.

Je voudrais également utiliser un HMAC réel au lieu de faire votre propre construction. En outre, au lieu de hacher le mot de passe, utilisez au moins PBKDF2 avec une quantité raisonnable d'itérations. Par conséquent vous obtiendrez que votre client fasse HMAC (données, PBKDF2 (someSecret, 1000)) et le serveur stockera simplement PBKDF2 (someSecret, 1000), puis fera HMAC (data, storedResult).