Discussion :

[poussinvert]

Bonjour,
Je voudrais avoir un peu plus d'informations sur le cryptage symétrique, son fonctionnement en général, et les bonnes manières pour la persistance des mot de passe.

J'ai un peu de mal entre les seeds et les salts. Ce que je comprends :

- un seed est utilisé pour crypter/décrypter un mot de passe.
- un salt est utilisé pour hasher un mot de passe.

J'ai lu que dans une base de données, il faut stocker le hash et le salt du mot de passe.
Prenons une application web par exemple. Elle stocke de manière sécurisée des comptes d’utilisateurs.

Quand l'utilisateur crée son compte
1. Il rentre son mot de passe en clair (ex : password)
2. On rajouter un salt au mot de passe (ex : password+Salt)
3. Le mot de passe est hashé grace à un algorithme de hash tel que blowfish par exemple (ex : XXXpassHashXXX).

Du coup, dans la base de donnée, je stocke XXXpassHashXXX et Salt. C'est bien ça ?
Ce qui veut dire que lorsqu'il va se connecter :
1. il saisit son mot de passe (ex : passwordErreur)
2. On rajouter le salt provenant de la base au mot de passe (ex : passwordErreur+Salt)
3. on hash le mot de passe (ex : XXXotherHashXXX)
4. On teste si ce hash est égal avec le hash en base (XXXotherHashXXX et XXXpassHashXXX)
5. On constate que les deux hashs sont différents, donc on interdit l'entrée.

J'espère que je ne me suis pas trompé jusqu'ici. En tout cas si c'est bien comme ça que ça fonctionne... à quoi sert le seed ???
Je ne l'ai pas utilisé jusqu'ici, et j'ai bien stocké ce qu'il fallait dans la base ?

Merci pour vos éclaircissements.

[ram-0000]

seed (graine) et salt (sel), c'est la même chose dans ce contexte. Certains préfère seed, d'autre salt, c'est selon.

Le seed/salt est utilisé pour introduire une certaine variabilité dans les hash des mots de passe. Tous les utilisateurs qui ont comme mot de passe "toto" n'auront ainsi pas le même hash puis que le seed/salt risque fort d'être différent.

J'ai vu certaines applications qui construisaient le seed/salt avec le numéro de pid du process ainsi que la date courante, en brassant cela et en sortant un nombre pseudo variable (mais suffisant variable pour le cas qui nous intéresse).

Sinon, ce que tu décrit est parfaitement juste.

Au fait, en français, on chiffre et on déchiffre. Crypter, c'est un barbarisme qui provient du verbe anglais "to crypt"

Autre chose, on ne devrait JAMAIS chiffrer et déchiffrer un mot de passe, c'est un pêché, c'est le mal. Si on peut le déchiffrer, c'est qu'il est chiffré avec une clé secrète et que quelqu'un d'autre qui possède cette clé secrète peut déchiffrer ce mot de passe (et les autres).

Par contre, on peut le hasher et comparer le hash obtenu avec celui en base de données.

[poussinvert]

Merci pour les précisions,
Au moins je suis sûr d'avoir bien compris.

seed (graine) et salt (sel), c'est la même chose dans ce contexte. Certains préfère seed, d'autre salt, c'est selon.

Dans ce contexte.... ça veut dire que dans un autre contexte, ces deux choses sont différentes ?

J'essaie de bien comprendre parce qu'il faut que je crée une application android qui échange avec un site web réalisé avec le framework phpcake (v2.3). Il faut que l'utilisateur puisse se connecter sur le site depuis son terminal android. La sécurité mise en place est assez élevée puisque le système de chiffrement / hashage par le framework utilise seed ET salt (en utilisant blowfish).

Du coup, je ne comprends pas ce que le seed vient faire là, mais ce qui est sûr c'est qu'il est utilisé avec le salt...

Alors est-ce que quelqu'un peut m'expliquer dans quels cas on peut les mélanger ?

J'ai l'impression que ce n'est pas expliqué dans la doc comment les deux sont mélangés avec blowfish pour obtenir le hash final : Cliquer là et ctrl+F + "salt" ou "seed" pour arriver directement aux endroits ou ils en parlent.

[ram-0000]

Je viens de lire le doc (en diagonale) et

seed et salt sont pareils, c'est de la variabilité dans les algo MAIS dans CakePHPCookbook, ils introduisent une nuance :

• seed est utilisé par les algorithmes de chiffrement symétriques
• salt est utilisé par les algorithme de hash

Ce sont 2 nombres/chaines de caractères qui ne doivent pas être facilement devinable

[poussinvert]

Ah d'accord,
Mais est ce que ça veut dire que les deux (seed et salt) sont utilisés pour le mot de passe ? Pas forcément en fait...

[Loceka]

En fait, même si dans la pratique ça revient au même, le seed et le salt n'ont pas tout à fait la même finalité.

Le seed est utilisé comme une "séquence aléatoire fixe" et remplace donc le côté aléatoire du chiffrement afin d'obtenir un résultat qui sera toujours identique.

Un exemple très simple pour comprendre : dans la plupart des langages, il est possible d'utiliser un seed avec fonction random, ce qui lui permet de générer toujours la même suite aléatoire pour un seed donné.
En cryptographie, ça doit être utilisé pour la génération des clefs (ou de la clef en symétrique) afin de s'assurer que la/les clef(s) générée soit toujours la même pour un seed donné. Le seed pouvant donc être un mot de passe.

Le salt, lui, a pour but d'altérer le résultat donné par un algorithme, principalement pour éviter d'avoir des résultats trop prévisibles.

Par exemple en md5, il existe des bases de données entières de "hash connus" faisant un lien entre un mot de passe et son hash md5. L'ajout d'un salt permet de ne pas hasher directement le mot de passe mais de modifier ce dernier afin que le hash généré soit altéré. Ce procédé permet donc de rendre plus "fort" le hash généré, quelque soit le mot de passe de départ.

En résumé :
- parler de seed pour une fonction de hashage n'a pas de sens vu qu'il n'y a pas de notion d'aléatoire en hash.
- un salt est "juste" une sécurité pour s'assurer que le hash généré (je ne suis pas certain que le salt soit utile pour du chiffrement) ne soit pas facilement reliable à la chaîne hashée.

[poussinvert]

Ok merci pour ces infos. Finalement le framework n'utilise pas le seed et le salt pour créer le hash comme j'ai pu le dire précédemment.

Le framework utilise bcrypt pour hasher le pass, et il est tout à fait possible de comparer deux password avec jbcrypt, une adaptation de bcrypt pour JAVA.

En fait je me compliquais carrément. Merci pour vos éclaircissements.