Taille d'un champ crypté en md5

Bonjour, la taille d'un champ crypté (md5) peut-elle varier ?
Merci.

Citation:

---

Envoyé par stc074

Bonjour, la taille d'un champ crypté (md5) peut-elle varier ?
Merci.

---

Non, le retour doit être de 16 octets.

ATTENTION : une fonction de hachage n'est en aucun cas une solution de cryptage !!!

A +

Citation:

---

Envoyé par SQLpro

Non, le retour doit être de 16 octets.

ATTENTION : une fonction de hachage n'est en aucun cas une solution de cryptage !!!

A +

---

Ah, je pensais que cela suffisait à crypter, je fais ainsi

INSERT INTO table (nickname, pass) VALUES (?, MD5(?)); (requête préparée en Java)
pass est le mot de passe saisi, peux-tu me confirmer que cela ne suffit pas, et si t'as un bon lien vers un tuto je suis preneur aussi.
Merci beaucoup.

Un hachage est un algorithme qui convertit une donnée quelconque en un nombre binaire de façon à mieux ventiler les différentes valeurs. Le hachage s'avère utile lorsque la distribution des données est erratique (par exemple concentration de chaines de caractères commençant par M et très rarement par Z...). C'est généralement utilisé pour la distribution de processus dans des systèmes répartis afin de les faire fonctionner en parallèle avec un bon lissage de charge.
Rien à voir donc avec du cryptage. Il n'est d'ailleurs pas possible de "décrypter" puisque le hachage est à sens unique. En sus, plusieurs données différentes peuvent conduire au même code haché (téléscopage) !
par exemple, les chaines binaires suivantes :
d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70
et
d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70
Qui différent au 20e octet, donne la même valeur de hash :
79054025255FB1A26E4BC422AEF54EB4

Exemple avec PostGreSQL :

Code:

---

1 2 3

SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'::bytea) UNION ALL SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'::bytea)

---

On s'en sert néanmoins parfois de manière détournée pour gérer des "signatures"... Ce qui est absurde !

Si vous voulez du cryptage il faut utiliser un algorithme de chiffrement comme RSA, AES ou DES...

Vous pouvez trouver cela dans la contribution ps_crypto. Néanmoins PostGreSQL n'est pas fiable au niveau du cryptage parce qu'il n'implémente pas de "salage" automatique du cryptage. Il est alors facile de casser le code par une cryptanalyse fréquentielle.
Des SGBDR comme SQL Server ou Oracle utilisent un chiffrement automatiquement "salé" pour plus de sécurité....

A +

Merci pour ces informations, je vais crypter mes mots de passe avant de les enregistrer dans la bdd, j'ai trouvé la classe Blowfish pour java, ça a l'air bien.

Citation:

---

Envoyé par stc074

Merci pour ces informations, je vais crypter mes mots de passe avant de les enregistrer dans la bdd, j'ai trouvé la classe Blowfish pour java, ça a l'air bien.

---

Au vu des nombreuses personnes qui confondent hachage et cryptage et ne maitrisent pas le cryptage dans les SGBDR j'ai écrit un article :
http://blog.developpez.com/sqlpro/p1...dans-les-sgbdr

A +