bonjour,
je ne fonction me permettant de crypter un mot de passe.
je souhaite pouvoir décrypter mon mot de passe pour pouvoir en cas d'oubli
de le renvoyer au membre.
c'est ce que font les gros sites je crois.
pouvez vous me donner la meilleure solution.
des sites tels que yahoo change le mot de passe en cas de perte. ils doivent
utiliser donc une fonction telle que md5.
l'intérêt du md5 est qu'il est strictement impossible de repasser au mot de passe d'origine
md5crack tu connais.
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
l'intérêt du md5 est qu'il est strictement impossible de repasser au mot de passe d'origine
md5crack tu connais.
non, mais si tu arrives à retrouver les chaines initiales qui ont servi
à générer les empreintes, alors je pense que toute la communauté des
programmeurs et de la crypto va devoir se suicider ...
je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste
de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
l'intérêt du md5 est qu'il est strictement impossible de repasser au mot de passe d'origine
md5crack tu connais.
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
tyoup
Pimousse wrote:
l'intérêt du md5 est qu'il est strictement impossible de repasser au mot de passe d'origine
md5crack tu connais.
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ...
tout est une question de temps en crypto d'ailleurs
-- tyoup
Pimousse wrote:
l'intérêt du md5 est qu'il est strictement impossible de repasser au
mot de passe d'origine
md5crack tu connais.
non, mais si tu arrives à retrouver les chaines initiales qui ont servi
à générer les empreintes, alors je pense que toute la communauté des
programmeurs et de la crypto va devoir se suicider ...
je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste
de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ...
tout est une question de temps en crypto d'ailleurs
l'intérêt du md5 est qu'il est strictement impossible de repasser au mot de passe d'origine
md5crack tu connais.
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ...
tout est une question de temps en crypto d'ailleurs
-- tyoup
Pimousse
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ... tout est une question de temps en crypto d'ailleurs
tout à fait d'accord ... sauf que md5 (et son successeur SHA) génère une empreinte de fichier qui a une taille ..... constante quel que soit le fichier à 128 bits (SHA : 160) dc je ne vois pas en quoi le fait que la chaine de départ soit courte ou non simplifie ou rende possible le décodage
non, mais si tu arrives à retrouver les chaines initiales qui ont servi
à générer les empreintes, alors je pense que toute la communauté des
programmeurs et de la crypto va devoir se suicider ...
je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste
de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ...
tout est une question de temps en crypto d'ailleurs
tout à fait d'accord ... sauf que md5 (et son successeur SHA) génère une
empreinte de fichier qui a une taille ..... constante quel que soit le
fichier à 128 bits (SHA : 160)
dc je ne vois pas en quoi le fait que la chaine de départ soit courte ou non
simplifie ou rende possible le décodage
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ... tout est une question de temps en crypto d'ailleurs
tout à fait d'accord ... sauf que md5 (et son successeur SHA) génère une empreinte de fichier qui a une taille ..... constante quel que soit le fichier à 128 bits (SHA : 160) dc je ne vois pas en quoi le fait que la chaine de départ soit courte ou non simplifie ou rende possible le décodage
tyoup
Pimousse wrote:
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ... tout est une question de temps en crypto d'ailleurs
tout à fait d'accord ... sauf que md5 (et son successeur SHA) génère une empreinte de fichier qui a une taille ..... constante quel que soit le fichier à 128 bits (SHA : 160) dc je ne vois pas en quoi le fait que la chaine de départ soit courte ou non simplifie ou rende possible le décodage
il "suffit" de calculer les sommes de toutes les chaînes de moins de x caractères.. certes ça peut être extrèmement long..
on peut aussi utiliser un dictionnaire
-- tyoup
Pimousse wrote:
non, mais si tu arrives à retrouver les chaines initiales qui ont servi
à générer les empreintes, alors je pense que toute la communauté des
programmeurs et de la crypto va devoir se suicider ...
je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste
de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ...
tout est une question de temps en crypto d'ailleurs
tout à fait d'accord ... sauf que md5 (et son successeur SHA) génère une
empreinte de fichier qui a une taille ..... constante quel que soit le
fichier à 128 bits (SHA : 160)
dc je ne vois pas en quoi le fait que la chaine de départ soit courte ou non
simplifie ou rende possible le décodage
il "suffit" de calculer les sommes de toutes les chaînes de moins de x
caractères.. certes ça peut être extrèmement long..
non, mais si tu arrives à retrouver les chaines initiales qui ont servi à générer les empreintes, alors je pense que toute la communauté des programmeurs et de la crypto va devoir se suicider ... je parle peut etre sans savoir, mais ayant eu un cours d'un spécialiste de crypto il y a 2 mois où il affirmait que md5 était irréversible ...
sur une chaîne courte c'est juste une question de temps ... tout est une question de temps en crypto d'ailleurs
tout à fait d'accord ... sauf que md5 (et son successeur SHA) génère une empreinte de fichier qui a une taille ..... constante quel que soit le fichier à 128 bits (SHA : 160) dc je ne vois pas en quoi le fait que la chaine de départ soit courte ou non simplifie ou rende possible le décodage
il "suffit" de calculer les sommes de toutes les chaînes de moins de x caractères.. certes ça peut être extrèmement long..
on peut aussi utiliser un dictionnaire
-- tyoup
Pimousse
il "suffit" de calculer les sommes de toutes les chaînes de moins de x caractères.. certes ça peut être extrèmement long..
on peut aussi utiliser un dictionnaire
donc on est tranquille qd on génère des mdp de passe de 8 caractères aléatoires alphanum sensibles à la casse.
62 possibilités pour chaque caractère .... 218 340 105 584 896 possibilités au total ... calcul mental bien sur ;o)
tout ça pour récupérer un mdp qui sert à protéger au pire des emails ... c'est dans ce sens que j'entendais "md5 est unidirectionnel" : c'est que c'est tellement dur de retrouver l'original que personne n'essaye de casser le mdp.
@++ Pimousse
il "suffit" de calculer les sommes de toutes les chaînes de moins de x
caractères.. certes ça peut être extrèmement long..
on peut aussi utiliser un dictionnaire
donc on est tranquille qd on génère des mdp de passe de 8 caractères
aléatoires alphanum sensibles à la casse.
62 possibilités pour chaque caractère ....
218 340 105 584 896 possibilités au total ... calcul mental bien sur ;o)
tout ça pour récupérer un mdp qui sert à protéger au pire des emails ...
c'est dans ce sens que j'entendais "md5 est unidirectionnel" : c'est que
c'est tellement dur de retrouver l'original que personne n'essaye de
casser le mdp.
il "suffit" de calculer les sommes de toutes les chaînes de moins de x caractères.. certes ça peut être extrèmement long..
on peut aussi utiliser un dictionnaire
donc on est tranquille qd on génère des mdp de passe de 8 caractères aléatoires alphanum sensibles à la casse.
62 possibilités pour chaque caractère .... 218 340 105 584 896 possibilités au total ... calcul mental bien sur ;o)
tout ça pour récupérer un mdp qui sert à protéger au pire des emails ... c'est dans ce sens que j'entendais "md5 est unidirectionnel" : c'est que c'est tellement dur de retrouver l'original que personne n'essaye de casser le mdp.
@++ Pimousse
lapin.killer
Non, on uilise crypt() avec le sel qui va bien, on évite donc de se retrouver avec la même somme MD5 pour deux utilisateurs ayant le même mot de passe.
pour eviter ce probleme, et si on tient à utiliser md5, il suffit de faire quelque chose comme md5($login.$pass)
Non, on uilise crypt() avec le sel qui va bien, on évite donc de se
retrouver avec la même somme MD5 pour deux utilisateurs ayant le même mot de
passe.
pour eviter ce probleme, et si on tient à utiliser md5, il suffit de
faire quelque chose comme md5($login.$pass)
Non, on uilise crypt() avec le sel qui va bien, on évite donc de se retrouver avec la même somme MD5 pour deux utilisateurs ayant le même mot de passe.
pour eviter ce probleme, et si on tient à utiliser md5, il suffit de faire quelque chose comme md5($login.$pass)
Eric Daspet
Saloprilopette wrote:
pour eviter ce probleme, et si on tient à utiliser md5, il suffit de faire quelque chose comme md5($login.$pass)
Suivant les algorithmes ta procédure d'injection aléatoire pourrait même diminuer la force du hachage (puisque le login est connu) au lieu de l'améliorer.
Connais tu assez le fonctionnement interne de md5 pour être sûr que cette procédure ne permet pas tout de même d'avoir des informations quand deux mots de passe sont identiques ?
Personnellement je répondrai non, donc je m'abstiendrai de telles techniques et utiliserai crypt() qui est fait par des gens qui savent ce qu'ils font.
J'ai vu tellement de gens faire des choses complètement idiotes coté mot de passe parce qu'ils ne connaissent pas exactement comment marchent les outils utilisés (intuitivement leur truc marche mais manque de pot en pratique c'est négatif au lieu d'être positif) que je m'abstiens de faire de telles manipulations sans *savoir* (et pas simplement supposer) que c'est utile.
-- Eric Daspet Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
Saloprilopette wrote:
pour eviter ce probleme, et si on tient à utiliser md5, il suffit de
faire quelque chose comme md5($login.$pass)
Suivant les algorithmes ta procédure d'injection aléatoire pourrait même
diminuer la force du hachage (puisque le login est connu) au lieu de
l'améliorer.
Connais tu assez le fonctionnement interne de md5 pour être sûr que
cette procédure ne permet pas tout de même d'avoir des informations
quand deux mots de passe sont identiques ?
Personnellement je répondrai non, donc je m'abstiendrai de telles
techniques et utiliserai crypt() qui est fait par des gens qui savent ce
qu'ils font.
J'ai vu tellement de gens faire des choses complètement idiotes coté mot
de passe parce qu'ils ne connaissent pas exactement comment marchent les
outils utilisés (intuitivement leur truc marche mais manque de pot en
pratique c'est négatif au lieu d'être positif) que je m'abstiens de
faire de telles manipulations sans *savoir* (et pas simplement supposer)
que c'est utile.
--
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
pour eviter ce probleme, et si on tient à utiliser md5, il suffit de faire quelque chose comme md5($login.$pass)
Suivant les algorithmes ta procédure d'injection aléatoire pourrait même diminuer la force du hachage (puisque le login est connu) au lieu de l'améliorer.
Connais tu assez le fonctionnement interne de md5 pour être sûr que cette procédure ne permet pas tout de même d'avoir des informations quand deux mots de passe sont identiques ?
Personnellement je répondrai non, donc je m'abstiendrai de telles techniques et utiliserai crypt() qui est fait par des gens qui savent ce qu'ils font.
J'ai vu tellement de gens faire des choses complètement idiotes coté mot de passe parce qu'ils ne connaissent pas exactement comment marchent les outils utilisés (intuitivement leur truc marche mais manque de pot en pratique c'est négatif au lieu d'être positif) que je m'abstiens de faire de telles manipulations sans *savoir* (et pas simplement supposer) que c'est utile.
-- Eric Daspet Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
Armel FAUVEAU
Bonjour Eric,
Quelques réactions en vrac.
Pourquoi tout le monde en réponse a l'air de parler de md5() ? à l'origine ça n'a rien d'une fonction de gestion de mot de passe (au final non plus d'ailleurs).
Ah ? :)
- elle gère en interne des chaînes d'initialisation pour limiter les attaques par dictionnaire (en gros si on crypte deux fois le même mot de passe on aura deux chaînes cryptées différentes)
Chaines d'initialisation qui ne présentent pas d'intérêt particulier avec les puissances de calcul dont on dipose actuellement (et depuis des années déjà). Si le choix de l'algorithme DES (utilisé par crypt() en standard) semblait suffisament sécuritaire aux origines d'Unix, c'est vraiment très loin d'être le cas de nos jours :)
De plus, ce n'est pas le mot de passe qui est chiffré, mais une chaine constante. Ton mot de passe joue ici le rôle de clef. Ni plus, ni moins :)
D'un point de vue général, si DES est un standard industriel et s'il est probablement le plus utilisé des algos de chiffrement, son degré de sécurité est faible. Ce qui plait précisement dans cet algo, c'est le fait qu'il soit...rapide (et facile à cabler, je pense).
Et puisque tu parlais de MD5, son degré de sécurité est plus élevé (si si). Mais il est aussi plus lent :)
Pour info, mes servers sous FreeBSD utilisent MD5 pour gérer mot de passe système et autre. Et non DES.
Bon, ceci dit, je partage, tout du moins dans les grandes lignes, ta vision quant à l'intérêt d'utiliser la fonction crytp() de PHP. C'est certainement un choix judicieux.
Armel.
Bonjour Eric,
Quelques réactions en vrac.
Pourquoi tout le monde en réponse a l'air de parler de md5() ? à
l'origine ça n'a rien d'une fonction de gestion de mot de passe (au
final non plus d'ailleurs).
Ah ? :)
- elle gère en interne des chaînes d'initialisation pour limiter les
attaques par dictionnaire (en gros si on crypte deux fois le même mot
de passe on aura deux chaînes cryptées différentes)
Chaines d'initialisation qui ne présentent pas d'intérêt particulier avec
les puissances de calcul dont on dipose actuellement (et depuis des années
déjà). Si le choix de l'algorithme DES (utilisé par crypt() en standard)
semblait suffisament sécuritaire aux origines d'Unix, c'est vraiment très
loin d'être le cas de nos jours :)
De plus, ce n'est pas le mot de passe qui est chiffré, mais une chaine
constante.
Ton mot de passe joue ici le rôle de clef. Ni plus, ni moins :)
D'un point de vue général, si DES est un standard industriel et s'il est
probablement le plus utilisé des algos de chiffrement, son degré de sécurité
est faible. Ce qui plait précisement dans cet algo, c'est le fait qu'il
soit...rapide (et facile à cabler, je pense).
Et puisque tu parlais de MD5, son degré de sécurité est plus élevé (si si).
Mais il est aussi plus lent :)
Pour info, mes servers sous FreeBSD utilisent MD5 pour gérer mot de passe
système et autre. Et non DES.
Bon, ceci dit, je partage, tout du moins dans les grandes lignes, ta vision
quant à l'intérêt d'utiliser la fonction crytp() de PHP. C'est certainement
un choix judicieux.
Pourquoi tout le monde en réponse a l'air de parler de md5() ? à l'origine ça n'a rien d'une fonction de gestion de mot de passe (au final non plus d'ailleurs).
Ah ? :)
- elle gère en interne des chaînes d'initialisation pour limiter les attaques par dictionnaire (en gros si on crypte deux fois le même mot de passe on aura deux chaînes cryptées différentes)
Chaines d'initialisation qui ne présentent pas d'intérêt particulier avec les puissances de calcul dont on dipose actuellement (et depuis des années déjà). Si le choix de l'algorithme DES (utilisé par crypt() en standard) semblait suffisament sécuritaire aux origines d'Unix, c'est vraiment très loin d'être le cas de nos jours :)
De plus, ce n'est pas le mot de passe qui est chiffré, mais une chaine constante. Ton mot de passe joue ici le rôle de clef. Ni plus, ni moins :)
D'un point de vue général, si DES est un standard industriel et s'il est probablement le plus utilisé des algos de chiffrement, son degré de sécurité est faible. Ce qui plait précisement dans cet algo, c'est le fait qu'il soit...rapide (et facile à cabler, je pense).
Et puisque tu parlais de MD5, son degré de sécurité est plus élevé (si si). Mais il est aussi plus lent :)
Pour info, mes servers sous FreeBSD utilisent MD5 pour gérer mot de passe système et autre. Et non DES.
Bon, ceci dit, je partage, tout du moins dans les grandes lignes, ta vision quant à l'intérêt d'utiliser la fonction crytp() de PHP. C'est certainement un choix judicieux.
Armel.
ED
Armel FAUVEAU wrote:
Si le choix de l'algorithme DES (utilisé par crypt() en standard) semblait suffisament sécuritaire aux origines d'Unix, c'est vraiment très loin d'être le cas de nos jours :)
C'est vrai, mais de nos jours les systèmes utilisent un backend à base de md5() pour crypt(). Il ne s'agit plus de triple DES, donc la sécurité éventuelle de DES n'est pas un problème. (par contre c'est vrai que comme avantage crypt() permet aussi de vérifier de manière transparente des anciens mots de passe qu'on aurait déjà avec un algo 3DES)
Et puisque tu parlais de MD5, son degré de sécurité est plus élevé (si si). Mais il est aussi plus lent :)
La comparaison ne se fait pas entre md5 et 3des, mais entre md5() et crypt() (éventuellement basé sur md5). D'ailleurs à vrai dire non, c'est plutot entre "une fonction de hachage précise qui n'est en rien dédiée aux mots de passe" et "une fonction spécifique aux mots de passe qui sait utilisé de manière transparente ce qu'il y a de plus adapté".
Pour info, mes servers sous FreeBSD utilisent MD5 pour gérer mot de passe système et autre. Et non DES.
Oui et non. Ils n'utilisent pas md5() directement justement, mais la version du système de la fonction crypt(), qui elle a un backend md5 (ce qui ne correspond pas exactement à l'utilisation de md5 mais c'est une autre histoire). Bref, tu confirmes justement ce que je dis ;)
À vrai dire le problème n'est pas tant l'algo, mais d'utiliser une fonction dédiée, plus ou moins standard face aux autres applis avec lesquelles on peut avoir à interagir, et qui saura évoluer en fonction des besoin (ce qu'elle a déjà fait en passant de3DES à MD5) J'ai tendance à refuser d'implémenter des solutions persos ... surtout pour les concepts d'algo qui demandes des bonnes notions avant d'être sûr de quoi que ce soit et qui évoluent rapidement avec la puissance des machines ou l'évolution des techniques mathématiques.
-- Eric
Armel FAUVEAU wrote:
Si le choix de l'algorithme DES (utilisé par crypt() en standard)
semblait suffisament sécuritaire aux origines d'Unix, c'est vraiment très
loin d'être le cas de nos jours :)
C'est vrai, mais de nos jours les systèmes utilisent un backend à base
de md5() pour crypt(). Il ne s'agit plus de triple DES, donc la sécurité
éventuelle de DES n'est pas un problème. (par contre c'est vrai que
comme avantage crypt() permet aussi de vérifier de manière transparente
des anciens mots de passe qu'on aurait déjà avec un algo 3DES)
Et puisque tu parlais de MD5, son degré de sécurité est plus élevé (si si).
Mais il est aussi plus lent :)
La comparaison ne se fait pas entre md5 et 3des, mais entre md5() et
crypt() (éventuellement basé sur md5). D'ailleurs à vrai dire non, c'est
plutot entre "une fonction de hachage précise qui n'est en rien dédiée
aux mots de passe" et "une fonction spécifique aux mots de passe qui
sait utilisé de manière transparente ce qu'il y a de plus adapté".
Pour info, mes servers sous FreeBSD utilisent MD5 pour gérer mot de passe
système et autre. Et non DES.
Oui et non. Ils n'utilisent pas md5() directement justement, mais la
version du système de la fonction crypt(), qui elle a un backend md5 (ce
qui ne correspond pas exactement à l'utilisation de md5 mais c'est une
autre histoire). Bref, tu confirmes justement ce que je dis ;)
À vrai dire le problème n'est pas tant l'algo, mais d'utiliser une
fonction dédiée, plus ou moins standard face aux autres applis avec
lesquelles on peut avoir à interagir, et qui saura évoluer en fonction
des besoin (ce qu'elle a déjà fait en passant de3DES à MD5)
J'ai tendance à refuser d'implémenter des solutions persos ... surtout
pour les concepts d'algo qui demandes des bonnes notions avant d'être
sûr de quoi que ce soit et qui évoluent rapidement avec la puissance des
machines ou l'évolution des techniques mathématiques.
Si le choix de l'algorithme DES (utilisé par crypt() en standard) semblait suffisament sécuritaire aux origines d'Unix, c'est vraiment très loin d'être le cas de nos jours :)
C'est vrai, mais de nos jours les systèmes utilisent un backend à base de md5() pour crypt(). Il ne s'agit plus de triple DES, donc la sécurité éventuelle de DES n'est pas un problème. (par contre c'est vrai que comme avantage crypt() permet aussi de vérifier de manière transparente des anciens mots de passe qu'on aurait déjà avec un algo 3DES)
Et puisque tu parlais de MD5, son degré de sécurité est plus élevé (si si). Mais il est aussi plus lent :)
La comparaison ne se fait pas entre md5 et 3des, mais entre md5() et crypt() (éventuellement basé sur md5). D'ailleurs à vrai dire non, c'est plutot entre "une fonction de hachage précise qui n'est en rien dédiée aux mots de passe" et "une fonction spécifique aux mots de passe qui sait utilisé de manière transparente ce qu'il y a de plus adapté".
Pour info, mes servers sous FreeBSD utilisent MD5 pour gérer mot de passe système et autre. Et non DES.
Oui et non. Ils n'utilisent pas md5() directement justement, mais la version du système de la fonction crypt(), qui elle a un backend md5 (ce qui ne correspond pas exactement à l'utilisation de md5 mais c'est une autre histoire). Bref, tu confirmes justement ce que je dis ;)
À vrai dire le problème n'est pas tant l'algo, mais d'utiliser une fonction dédiée, plus ou moins standard face aux autres applis avec lesquelles on peut avoir à interagir, et qui saura évoluer en fonction des besoin (ce qu'elle a déjà fait en passant de3DES à MD5) J'ai tendance à refuser d'implémenter des solutions persos ... surtout pour les concepts d'algo qui demandes des bonnes notions avant d'être sûr de quoi que ce soit et qui évoluent rapidement avec la puissance des machines ou l'évolution des techniques mathématiques.
-- Eric
Armel FAUVEAU
Oui et non. Ils n'utilisent pas md5() directement justement, mais la version du système de la fonction crypt(), qui elle a un backend md5 (ce qui ne correspond pas exactement à l'utilisation de md5 mais c'est une autre histoire). Bref, tu confirmes justement ce que je dis ;)
Oui.
À vrai dire le problème n'est pas tant l'algo, mais d'utiliser une fonction dédiée, plus ou moins standard face aux autres applis avec lesquelles on peut avoir à interagir, et qui saura évoluer en fonction des besoin (ce qu'elle a déjà fait en passant de3DES à MD5)
Oui.
J'ai tendance à refuser d'implémenter des solutions persos ... surtout pour les concepts d'algo qui demandes des bonnes notions avant d'être sûr de quoi que ce soit et qui évoluent rapidement avec la puissance des machines ou l'évolution des techniques mathématiques.
Et tu as également raison, amha.
Bref, nous sommes en phase :)
Armel.
Oui et non. Ils n'utilisent pas md5() directement justement, mais la
version du système de la fonction crypt(), qui elle a un backend md5 (ce
qui ne correspond pas exactement à l'utilisation de md5 mais c'est une
autre histoire). Bref, tu confirmes justement ce que je dis ;)
Oui.
À vrai dire le problème n'est pas tant l'algo, mais d'utiliser une
fonction dédiée, plus ou moins standard face aux autres applis avec
lesquelles on peut avoir à interagir, et qui saura évoluer en fonction
des besoin (ce qu'elle a déjà fait en passant de3DES à MD5)
Oui.
J'ai tendance à refuser d'implémenter des solutions persos ... surtout
pour les concepts d'algo qui demandes des bonnes notions avant d'être
sûr de quoi que ce soit et qui évoluent rapidement avec la puissance des
machines ou l'évolution des techniques mathématiques.
Oui et non. Ils n'utilisent pas md5() directement justement, mais la version du système de la fonction crypt(), qui elle a un backend md5 (ce qui ne correspond pas exactement à l'utilisation de md5 mais c'est une autre histoire). Bref, tu confirmes justement ce que je dis ;)
Oui.
À vrai dire le problème n'est pas tant l'algo, mais d'utiliser une fonction dédiée, plus ou moins standard face aux autres applis avec lesquelles on peut avoir à interagir, et qui saura évoluer en fonction des besoin (ce qu'elle a déjà fait en passant de3DES à MD5)
Oui.
J'ai tendance à refuser d'implémenter des solutions persos ... surtout pour les concepts d'algo qui demandes des bonnes notions avant d'être sûr de quoi que ce soit et qui évoluent rapidement avec la puissance des machines ou l'évolution des techniques mathématiques.
