Est-ce une bonne idée de conserver la clé avec les données chiffrées ?
6 réponses
Vincent
Bonjour,
J'utilise Blowfish pour chiffrer le contenu de fichiers au moyen d'un
logiciel que je développe. Pour le chiffrement, je calcule un hash md5
du mot de passe, puis j'utilise ce hash comme clé pour l'algorithme
Blowfish.
Au moment du déchiffrage, j'aimerais détecter lorsque le mot de passe
est faux pour afficher un message du genre « Mot de passe non valable »
au lieu de fournir des données aléatoires.
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données
chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille
quelque part ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick 'Zener' Brunet
Bonsoir.
"Vincent" a écrit dans le message de news:
J'utilise Blowfish pour chiffrer le contenu de fichiers au moyen d'un logiciel que je développe. Pour le chiffrement, je calcule un hash md5 du mot de passe, puis j'utilise ce hash comme clé pour l'algorithme Blowfish.
Au moment du déchiffrage, j'aimerais détecter lorsque le mot de passe est faux pour afficher un message du genre « Mot de passe non valable » au lieu de fournir des données aléatoires.
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille quelque part ?
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe, et de concaténer cette valeur à la donnée. C'est "probablement" suffisant pour le diagnostic booléen voulu, sans compromettre la clé elle-même.
-- Cordialement. -- * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe
Bonsoir.
"Vincent" <chezvincent@gmail.com> a écrit dans le message de news:
5tcuefF1cotouU1@mid.individual.net...
J'utilise Blowfish pour chiffrer le contenu de fichiers au moyen d'un
logiciel que je développe. Pour le chiffrement, je calcule un hash md5
du mot de passe, puis j'utilise ce hash comme clé pour l'algorithme
Blowfish.
Au moment du déchiffrage, j'aimerais détecter lorsque le mot de passe
est faux pour afficher un message du genre « Mot de passe non valable »
au lieu de fournir des données aléatoires.
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données
chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille
quelque part ?
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou
mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe,
et de concaténer cette valeur à la donnée.
C'est "probablement" suffisant pour le diagnostic booléen voulu, sans
compromettre la clé elle-même.
--
Cordialement.
--
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
J'utilise Blowfish pour chiffrer le contenu de fichiers au moyen d'un logiciel que je développe. Pour le chiffrement, je calcule un hash md5 du mot de passe, puis j'utilise ce hash comme clé pour l'algorithme Blowfish.
Au moment du déchiffrage, j'aimerais détecter lorsque le mot de passe est faux pour afficher un message du genre « Mot de passe non valable » au lieu de fournir des données aléatoires.
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille quelque part ?
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe, et de concaténer cette valeur à la donnée. C'est "probablement" suffisant pour le diagnostic booléen voulu, sans compromettre la clé elle-même.
-- Cordialement. -- * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe
Al
Bonsoir.
"Vincent" a écrit dans le message de news:
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille quelque part ?
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe, et de concaténer cette valeur à la donnée. C'est "probablement" suffisant pour le diagnostic booléen voulu, sans compromettre la clé elle-même. le problème c'est que de faire une check sur le mot de passer réduit
l'espace de clé d'autant...
bon, si ta clé est bien plus grosse que le digest, ce n'est pas dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton mot de passe est long et complexe)
une idée ce serait plutot de faire un checksum de ce qui est à chiffre, et de l'ajouter à la fin.
ca me rappelle une norme de chiffrement... bon évidemment il faut aussi que tu puisse détecter la fin de ton message. soit il est de taille fixe, et tu stocke chiffre_Clé_(message,hash(message)) soit il est terminé par un truc défini et tu stocke chiffre_Clé_(message,terminateur,hash(message)) soit il est de taille variable
chiffre_Clé_(longueur,message,hash(message))
a noter que si le message est trop court il faudrait aussi convenir d'un padding aléatoire chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))
sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut être modeste) regarde les standards de chiffrement PKCS... il doit y en avoir un qui te convient.
n'oublie pas tout les détails, tesl que longuer minimal, padding aléatoire, hash, ordre des opérations
en effet le padding crée plus d'entropie et complique encore le travail à texte connu (qui ne l'est plus a cause du bourrage), mais c'est peutêtre de la zoophilie pour mouches... un principe en crypto c'est que si d'autres ont eu le même problème (là c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème voir trouvé un truc solide et standardisé qui a tenus quelque temps face a des scientifiques vicieux
Bonsoir.
"Vincent" <chezvincent@gmail.com> a écrit dans le message de news:
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données
chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille
quelque part ?
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou
mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe,
et de concaténer cette valeur à la donnée.
C'est "probablement" suffisant pour le diagnostic booléen voulu, sans
compromettre la clé elle-même.
le problème c'est que de faire une check sur le mot de passer réduit
l'espace de clé d'autant...
bon, si ta clé est bien plus grosse que le digest, ce n'est pas
dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de
véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton
mot de passe est long et complexe)
une idée ce serait plutot de faire un checksum de ce qui est à chiffre,
et de l'ajouter à la fin.
ca me rappelle une norme de chiffrement...
bon évidemment il faut aussi que tu puisse détecter la fin de ton message.
soit il est de taille fixe, et tu stocke
chiffre_Clé_(message,hash(message))
soit il est terminé par un truc défini et tu stocke
chiffre_Clé_(message,terminateur,hash(message))
soit il est de taille variable
chiffre_Clé_(longueur,message,hash(message))
a noter que si le message est trop court il faudrait aussi convenir d'un
padding aléatoire
chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))
sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins
dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut
être modeste) regarde les standards de chiffrement PKCS...
il doit y en avoir un qui te convient.
n'oublie pas tout les détails, tesl que longuer minimal, padding
aléatoire, hash, ordre des opérations
en effet le padding crée plus d'entropie et complique encore le travail
à texte connu (qui ne l'est plus a cause du bourrage), mais c'est
peutêtre de la zoophilie pour mouches...
un principe en crypto c'est que si d'autres ont eu le même problème (là
c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris
pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème
voir trouvé un truc solide et standardisé qui a tenus quelque temps face
a des scientifiques vicieux
Mon idée est d'enregistrer la clé (sous forme chiffrée) avec les données chiffrées, puis de la vérifier au moment du déchiffrage.
Est-ce que cela affaiblirait le chiffrement ou introduirait une faille quelque part ?
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe, et de concaténer cette valeur à la donnée. C'est "probablement" suffisant pour le diagnostic booléen voulu, sans compromettre la clé elle-même. le problème c'est que de faire une check sur le mot de passer réduit
l'espace de clé d'autant...
bon, si ta clé est bien plus grosse que le digest, ce n'est pas dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton mot de passe est long et complexe)
une idée ce serait plutot de faire un checksum de ce qui est à chiffre, et de l'ajouter à la fin.
ca me rappelle une norme de chiffrement... bon évidemment il faut aussi que tu puisse détecter la fin de ton message. soit il est de taille fixe, et tu stocke chiffre_Clé_(message,hash(message)) soit il est terminé par un truc défini et tu stocke chiffre_Clé_(message,terminateur,hash(message)) soit il est de taille variable
chiffre_Clé_(longueur,message,hash(message))
a noter que si le message est trop court il faudrait aussi convenir d'un padding aléatoire chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))
sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut être modeste) regarde les standards de chiffrement PKCS... il doit y en avoir un qui te convient.
n'oublie pas tout les détails, tesl que longuer minimal, padding aléatoire, hash, ordre des opérations
en effet le padding crée plus d'entropie et complique encore le travail à texte connu (qui ne l'est plus a cause du bourrage), mais c'est peutêtre de la zoophilie pour mouches... un principe en crypto c'est que si d'autres ont eu le même problème (là c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème voir trouvé un truc solide et standardisé qui a tenus quelque temps face a des scientifiques vicieux
Vincent
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe, et de concaténer cette valeur à la donnée. C'est "probablement" suffisant pour le diagnostic booléen voulu, sans compromettre la clé elle-même.
Merci, celà me parait en effet plus sûr... Pourrais-je stocker le hash md5 de la clé au lieu de la clé ? (la taille n'a pas beaucoup d'importance)
Vincent
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou
mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe,
et de concaténer cette valeur à la donnée.
C'est "probablement" suffisant pour le diagnostic booléen voulu, sans
compromettre la clé elle-même.
Merci, celà me parait en effet plus sûr... Pourrais-je stocker le hash
md5 de la clé au lieu de la clé ? (la taille n'a pas beaucoup d'importance)
Pourquoi faciliter le moins du monde la tâche d'un attaquant ?
Pour un tel diagnostic, je pense qu'il suffit de calculer un petit xor, ou mieux une checksum modulaire, sur moins de 8 bits à partir du mot de passe, et de concaténer cette valeur à la donnée. C'est "probablement" suffisant pour le diagnostic booléen voulu, sans compromettre la clé elle-même.
Merci, celà me parait en effet plus sûr... Pourrais-je stocker le hash md5 de la clé au lieu de la clé ? (la taille n'a pas beaucoup d'importance)
Vincent
Vincent
...
le problème c'est que de faire une check sur le mot de passer réduit l'espace de clé d'autant...
bon, si ta clé est bien plus grosse que le digest, ce n'est pas dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton mot de passe est long et complexe)
une idée ce serait plutot de faire un checksum de ce qui est à chiffre, et de l'ajouter à la fin.
ca me rappelle une norme de chiffrement... bon évidemment il faut aussi que tu puisse détecter la fin de ton message. soit il est de taille fixe, et tu stocke chiffre_Clé_(message,hash(message)) soit il est terminé par un truc défini et tu stocke chiffre_Clé_(message,terminateur,hash(message)) soit il est de taille variable
chiffre_Clé_(longueur,message,hash(message))
a noter que si le message est trop court il faudrait aussi convenir d'un padding aléatoire chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))
sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut être modeste) regarde les standards de chiffrement PKCS... il doit y en avoir un qui te convient.
n'oublie pas tout les détails, tesl que longuer minimal, padding aléatoire, hash, ordre des opérations
en effet le padding crée plus d'entropie et complique encore le travail à texte connu (qui ne l'est plus a cause du bourrage), mais c'est peutêtre de la zoophilie pour mouches... un principe en crypto c'est que si d'autres ont eu le même problème (là c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème voir trouvé un truc solide et standardisé qui a tenus quelque temps face a des scientifiques vicieux
Merci, je vais donc essayer de voir les standards PKCS. Juste une question : quelque chose m'échappe dans ton explication, pourrais-tu préciser ce que représente "chiffre_clé" ? Dans mon fichier je stocke le "salt", le vecteur d'initialisation, puis les données chiffrées.
Vincent
...
le problème c'est que de faire une check sur le mot de passer réduit
l'espace de clé d'autant...
bon, si ta clé est bien plus grosse que le digest, ce n'est pas
dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de
véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton
mot de passe est long et complexe)
une idée ce serait plutot de faire un checksum de ce qui est à chiffre,
et de l'ajouter à la fin.
ca me rappelle une norme de chiffrement...
bon évidemment il faut aussi que tu puisse détecter la fin de ton message.
soit il est de taille fixe, et tu stocke
chiffre_Clé_(message,hash(message))
soit il est terminé par un truc défini et tu stocke
chiffre_Clé_(message,terminateur,hash(message))
soit il est de taille variable
chiffre_Clé_(longueur,message,hash(message))
a noter que si le message est trop court il faudrait aussi convenir d'un
padding aléatoire
chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))
sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins
dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut
être modeste) regarde les standards de chiffrement PKCS...
il doit y en avoir un qui te convient.
n'oublie pas tout les détails, tesl que longuer minimal, padding
aléatoire, hash, ordre des opérations
en effet le padding crée plus d'entropie et complique encore le travail
à texte connu (qui ne l'est plus a cause du bourrage), mais c'est
peutêtre de la zoophilie pour mouches...
un principe en crypto c'est que si d'autres ont eu le même problème (là
c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris
pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème
voir trouvé un truc solide et standardisé qui a tenus quelque temps face
a des scientifiques vicieux
Merci, je vais donc essayer de voir les standards PKCS. Juste une
question : quelque chose m'échappe dans ton explication, pourrais-tu
préciser ce que représente "chiffre_clé" ? Dans mon fichier je stocke le
"salt", le vecteur d'initialisation, puis les données chiffrées.
le problème c'est que de faire une check sur le mot de passer réduit l'espace de clé d'autant...
bon, si ta clé est bien plus grosse que le digest, ce n'est pas dramatique, mais a mon avis tu n'a pas beaucoup plus de 128bits de véritable entropie (et d'ailleurs si tu en as plus de 15, c'est que ton mot de passe est long et complexe)
une idée ce serait plutot de faire un checksum de ce qui est à chiffre, et de l'ajouter à la fin.
ca me rappelle une norme de chiffrement... bon évidemment il faut aussi que tu puisse détecter la fin de ton message. soit il est de taille fixe, et tu stocke chiffre_Clé_(message,hash(message)) soit il est terminé par un truc défini et tu stocke chiffre_Clé_(message,terminateur,hash(message)) soit il est de taille variable
chiffre_Clé_(longueur,message,hash(message))
a noter que si le message est trop court il faudrait aussi convenir d'un padding aléatoire chiffre_Clé_(longueur,message,paddingsuffisant,hash(message))
sinon plutot que d'écouter ce que je te dis (j'estime que c'est moins dangereux que ce que j'ai lu jusque la, mais dans ce domaine il faut être modeste) regarde les standards de chiffrement PKCS... il doit y en avoir un qui te convient.
n'oublie pas tout les détails, tesl que longuer minimal, padding aléatoire, hash, ordre des opérations
en effet le padding crée plus d'entropie et complique encore le travail à texte connu (qui ne l'est plus a cause du bourrage), mais c'est peutêtre de la zoophilie pour mouches... un principe en crypto c'est que si d'autres ont eu le même problème (là c'est vrai il faut faire gaffe que ce soit vraiment le même, y compris pour les détails) il faut voir s'ils n'ont pas mieux étudié le problème voir trouvé un truc solide et standardisé qui a tenus quelque temps face a des scientifiques vicieux
Merci, je vais donc essayer de voir les standards PKCS. Juste une question : quelque chose m'échappe dans ton explication, pourrais-tu préciser ce que représente "chiffre_clé" ? Dans mon fichier je stocke le "salt", le vecteur d'initialisation, puis les données chiffrées.
Vincent
Al
Merci, je vais donc essayer de voir les standards PKCS. Juste une question : quelque chose m'échappe dans ton explication, pourrais-tu préciser ce que représente "chiffre_clé" ?
c'est une notation pas claire du cliffrement par la clé
Chiffrement(clé,donnée) mais comme j'ai des données complexes
en plus toi tu aurait Chiffrement(clé, vecteur d'init, (salt,longueur,message,hash(salt,longueur,message)))
note qu'on peut utiliser un hash non crypto: une parité, un crc, une checksum... on n'est pas la pour signer, juste pour vérifier
Dans mon fichier je stocke le "salt", le vecteur d'initialisation, puis les données chiffrées.
le salt joue un peu le rôle du padding, mais pas pour bourer, juste pour bruiter... regarde comment je l'utilise ci-avant
dans certains docs standards on parle du vecteur d'init qui n'est pas une clé, mais un paramètre (public) de l'algo...
j'ai pas tout suivi et donc prudence
Merci, je vais donc essayer de voir les standards PKCS. Juste une
question : quelque chose m'échappe dans ton explication, pourrais-tu
préciser ce que représente "chiffre_clé" ?
c'est une notation pas claire du cliffrement par la clé
Chiffrement(clé,donnée)
mais comme j'ai des données complexes
en plus toi tu aurait
Chiffrement(clé, vecteur d'init,
(salt,longueur,message,hash(salt,longueur,message)))
note qu'on peut utiliser un hash non crypto: une parité, un crc, une
checksum... on n'est pas la pour signer, juste pour vérifier
Dans mon fichier je stocke le
"salt", le vecteur d'initialisation, puis les données chiffrées.
le salt joue un peu le rôle du padding, mais pas pour bourer, juste pour
bruiter...
regarde comment je l'utilise ci-avant
dans certains docs standards on parle du vecteur d'init qui n'est pas
une clé, mais un paramètre (public) de l'algo...
Merci, je vais donc essayer de voir les standards PKCS. Juste une question : quelque chose m'échappe dans ton explication, pourrais-tu préciser ce que représente "chiffre_clé" ?
c'est une notation pas claire du cliffrement par la clé
Chiffrement(clé,donnée) mais comme j'ai des données complexes
en plus toi tu aurait Chiffrement(clé, vecteur d'init, (salt,longueur,message,hash(salt,longueur,message)))
note qu'on peut utiliser un hash non crypto: une parité, un crc, une checksum... on n'est pas la pour signer, juste pour vérifier
Dans mon fichier je stocke le "salt", le vecteur d'initialisation, puis les données chiffrées.
le salt joue un peu le rôle du padding, mais pas pour bourer, juste pour bruiter... regarde comment je l'utilise ci-avant
dans certains docs standards on parle du vecteur d'init qui n'est pas une clé, mais un paramètre (public) de l'algo...
j'ai pas tout suivi et donc prudence
Patrick 'Zener' Brunet
Bonsoir.
"Al" a écrit dans le message de news: 47742772$0$897$
[...] note qu'on peut utiliser un hash non crypto: une parité, un crc, une checksum... on n'est pas la pour signer, juste pour vérifier
Tout à fait, précisément il n'y a pas d'objectif de sécurité au sens de l'authentification. Si j'ai bien compris, l'objectif est seulement de diagnostiquer un mot de passe incorrect afin que l'utilisateur ne reste pas devant un refus d'accès incompréhensible ?
Avec une simple checksum de type XOR sur 5 bits indexant une clé alphanumérique, il aurait seulement une chance sur 32 de trouver un mauvais mot de passe qui ne soit pas diagnostiqué et provoque seulement un refus d'accès. A moins de viser une population de malchanceux chroniques, cela semble largement suffisant, non ?
-- Cordialement. -- * Patrick BRUNET www.ipzb.fr * E-mail: lien sur http://zener131.free.fr/ContactMe
Bonsoir.
"Al" <aln@nospam.fr> a écrit dans le message de news:
47742772$0$897$ba4acef3@news.orange.fr...
[...]
note qu'on peut utiliser un hash non crypto: une parité, un crc,
une checksum... on n'est pas la pour signer, juste pour vérifier
Tout à fait, précisément il n'y a pas d'objectif de sécurité au sens de
l'authentification.
Si j'ai bien compris, l'objectif est seulement de diagnostiquer un mot de
passe incorrect afin que l'utilisateur ne reste pas devant un refus d'accès
incompréhensible ?
Avec une simple checksum de type XOR sur 5 bits indexant une clé
alphanumérique, il aurait seulement une chance sur 32 de trouver un mauvais
mot de passe qui ne soit pas diagnostiqué et provoque seulement un refus
d'accès. A moins de viser une population de malchanceux chroniques, cela
semble largement suffisant, non ?
--
Cordialement.
--
* Patrick BRUNET www.ipzb.fr
* E-mail: lien sur http://zener131.free.fr/ContactMe
"Al" a écrit dans le message de news: 47742772$0$897$
[...] note qu'on peut utiliser un hash non crypto: une parité, un crc, une checksum... on n'est pas la pour signer, juste pour vérifier
Tout à fait, précisément il n'y a pas d'objectif de sécurité au sens de l'authentification. Si j'ai bien compris, l'objectif est seulement de diagnostiquer un mot de passe incorrect afin que l'utilisateur ne reste pas devant un refus d'accès incompréhensible ?
Avec une simple checksum de type XOR sur 5 bits indexant une clé alphanumérique, il aurait seulement une chance sur 32 de trouver un mauvais mot de passe qui ne soit pas diagnostiqué et provoque seulement un refus d'accès. A moins de viser une population de malchanceux chroniques, cela semble largement suffisant, non ?
-- Cordialement. -- * Patrick BRUNET www.ipzb.fr * E-mail: lien sur http://zener131.free.fr/ContactMe
