Je suis à la recherche d'un script codant en MD5. J'avais vu il y a
plusieurs mois cela à l'occasion d'un concours sur le net, mais je ne
retrouve pas.
Vous avez une piste ?
Merci et bonne nouvelle semaine à vous,
Thierry
--
4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr>
3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais-
2 sent le système binaire et ceux qui ne le connaissent pas "
1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
Ce sera 898f3e39c22962e38a389994a49c47ae qu'il faudra envoyer au serveur, bien évidemment :p
Mais le test se fait en local :P
En local, je peux accéder à toutes les ressources que je veux sans passer par ton code JavaScript. C'est pour accéder au compte sur le serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est 898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code JavaScript vérifiant que je connais une chaîne dont le code MD5 donne ce mot de passe.
Ce sera 898f3e39c22962e38a389994a49c47ae qu'il faudra envoyer au
serveur, bien évidemment :p
Mais le test se fait en local :P
En local, je peux accéder à toutes les ressources que je veux sans
passer par ton code JavaScript. C'est pour accéder au compte sur le
serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est
898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code
JavaScript vérifiant que je connais une chaîne dont le code MD5 donne
ce mot de passe.
Ce sera 898f3e39c22962e38a389994a49c47ae qu'il faudra envoyer au serveur, bien évidemment :p
Mais le test se fait en local :P
En local, je peux accéder à toutes les ressources que je veux sans passer par ton code JavaScript. C'est pour accéder au compte sur le serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est 898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code JavaScript vérifiant que je connais une chaîne dont le code MD5 donne ce mot de passe.
À noter que, hacher le mot de passe avec md5 depuis le client est furieusement inutile. Au contraire, ça enlève une difficulté pour pirater un compte.
Trouvez le bon mot :-)
<http://astrophoto.free.fr/md5.html>
Bon personne du coup et d'un coup n'a trouvé :
nmreglgermn
Thierry -- 4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr> 3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais- 2 sent le système binaire et ceux qui ne le connaissent pas " 1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
À noter que, hacher le mot de passe avec md5 depuis le client est
furieusement inutile. Au contraire, ça enlève une difficulté pour
pirater un compte.
Trouvez le bon mot :-)
<http://astrophoto.free.fr/md5.html>
Bon personne du coup et d'un coup n'a trouvé :
nmreglgermn
Thierry
--
4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr>
3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais-
2 sent le système binaire et ceux qui ne le connaissent pas "
1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
À noter que, hacher le mot de passe avec md5 depuis le client est furieusement inutile. Au contraire, ça enlève une difficulté pour pirater un compte.
Trouvez le bon mot :-)
<http://astrophoto.free.fr/md5.html>
Bon personne du coup et d'un coup n'a trouvé :
nmreglgermn
Thierry -- 4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr> 3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais- 2 sent le système binaire et ceux qui ne le connaissent pas " 1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
loiseauthierry
Olivier Miakinen <om+ wrote:
Ce sera 898f3e39c22962e38a389994a49c47ae qu'il faudra envoyer au serveur, bien évidemment :p
Mais le test se fait en local :P
En local, je peux accéder à toutes les ressources que je veux sans passer par ton code JavaScript. C'est pour accéder au compte sur le serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est 898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code JavaScript vérifiant que je connais une chaîne dont le code MD5 donne ce mot de passe.
M*rdre ! Je ne comprends pas :
1) ta réponse 2) pourquoi toujours parler "côté serveur" ??
Thierry -- 4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr> 3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais- 2 sent le système binaire et ceux qui ne le connaissent pas " 1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
Olivier Miakinen <om+news@miakinen.net> wrote:
Ce sera 898f3e39c22962e38a389994a49c47ae qu'il faudra envoyer au
serveur, bien évidemment :p
Mais le test se fait en local :P
En local, je peux accéder à toutes les ressources que je veux sans
passer par ton code JavaScript. C'est pour accéder au compte sur le
serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est
898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code
JavaScript vérifiant que je connais une chaîne dont le code MD5 donne
ce mot de passe.
M*rdre ! Je ne comprends pas :
1) ta réponse
2) pourquoi toujours parler "côté serveur" ??
Thierry
--
4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr>
3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais-
2 sent le système binaire et ceux qui ne le connaissent pas "
1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
Ce sera 898f3e39c22962e38a389994a49c47ae qu'il faudra envoyer au serveur, bien évidemment :p
Mais le test se fait en local :P
En local, je peux accéder à toutes les ressources que je veux sans passer par ton code JavaScript. C'est pour accéder au compte sur le serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est 898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code JavaScript vérifiant que je connais une chaîne dont le code MD5 donne ce mot de passe.
M*rdre ! Je ne comprends pas :
1) ta réponse 2) pourquoi toujours parler "côté serveur" ??
Thierry -- 4 Calculs & Astronomie en Javascript : <http://astrophoto.free.fr> 3 " Il y a 10 sortes de personnes sur Terre : ceux qui connais- 2 sent le système binaire et ceux qui ne le connaissent pas " 1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
Olivier Miakinen
En local, je peux accéder à toutes les ressources que je veux sans passer par ton code JavaScript. C'est pour accéder au compte sur le serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est 898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code JavaScript vérifiant que je connais une chaîne dont le code MD5 donne ce mot de passe.
M*rdre ! Je ne comprends pas :
1) ta réponse 2) pourquoi toujours parler "côté serveur" ??
J'ai pris le fil en cours, mais -- si j'ai bien compris le contexte --, Mickaël parlait du cas où l'on transmet un mot de passe à un serveur pour accéder à un compte sur le serveur. Et il disait avec juste raison que faire un hash MD5 sur le client avant d'envoyer le résultat du hash au serveur était encore plus inefficace que d'envoyer le mot de passe en clair sur le réseau, avec un hash MD5 fait sur le serveur. En effet, supposons que tu aies eu accès à la base des mots de passe MD5-isés sur le serveur, dans le premier cas (hash sur le client) il te suffit de faire directement la requête avec le résultat du hash (que tu connais). Dans le second cas, il te faudra sniffer le réseau pour connaître le mot de passe en clair car la connaissance du hash ne te sert à rien.
En local, je peux accéder à toutes les ressources que je veux sans
passer par ton code JavaScript. C'est pour accéder au compte sur le
serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est
898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code
JavaScript vérifiant que je connais une chaîne dont le code MD5 donne
ce mot de passe.
M*rdre ! Je ne comprends pas :
1) ta réponse
2) pourquoi toujours parler "côté serveur" ??
J'ai pris le fil en cours, mais -- si j'ai bien compris le contexte --,
Mickaël parlait du cas où l'on transmet un mot de passe à un serveur
pour accéder à un compte sur le serveur. Et il disait avec juste raison
que faire un hash MD5 sur le client avant d'envoyer le résultat du hash
au serveur était encore plus inefficace que d'envoyer le mot de passe en
clair sur le réseau, avec un hash MD5 fait sur le serveur. En effet,
supposons que tu aies eu accès à la base des mots de passe MD5-isés sur
le serveur, dans le premier cas (hash sur le client) il te suffit de
faire directement la requête avec le résultat du hash (que tu connais).
Dans le second cas, il te faudra sniffer le réseau pour connaître le mot
de passe en clair car la connaissance du hash ne te sert à rien.
En local, je peux accéder à toutes les ressources que je veux sans passer par ton code JavaScript. C'est pour accéder au compte sur le serveur que j'ai besoin du bon mot de passe. Et si ce mot de passe est 898f3e39c22962e38a389994a49c47ae je n'ai pas besoin non plus d'un code JavaScript vérifiant que je connais une chaîne dont le code MD5 donne ce mot de passe.
M*rdre ! Je ne comprends pas :
1) ta réponse 2) pourquoi toujours parler "côté serveur" ??
J'ai pris le fil en cours, mais -- si j'ai bien compris le contexte --, Mickaël parlait du cas où l'on transmet un mot de passe à un serveur pour accéder à un compte sur le serveur. Et il disait avec juste raison que faire un hash MD5 sur le client avant d'envoyer le résultat du hash au serveur était encore plus inefficace que d'envoyer le mot de passe en clair sur le réseau, avec un hash MD5 fait sur le serveur. En effet, supposons que tu aies eu accès à la base des mots de passe MD5-isés sur le serveur, dans le premier cas (hash sur le client) il te suffit de faire directement la requête avec le résultat du hash (que tu connais). Dans le second cas, il te faudra sniffer le réseau pour connaître le mot de passe en clair car la connaissance du hash ne te sert à rien.
Laurent vilday
Mais au final, c'est une question de style, pas de défaut du langage. Je ne suis pas d'accord.
Le langage autorise l'omission des accolades mais je reste persuadé que c'est une erreur. Erreur induite par la présence de l'omission autorisée des points-virgules ;
L'absence des accolades n'est pas une omission. C'est justement le contraire. Le mot clé if est suivi de la condition entre parenthèse puis d'UNE instruction. L'usage d'accolades, c'est à dire l'introduction d'un bloc d'instructions, est un contournement.
Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que Douglas Crockford va dans mon sens, et comme il a largement plus de crédibilité que moi, je me sens moins seul sur le coup :)
<http://javascript.crockford.com/style1.html>
<cite>Douglas Crockford</cite> <q lang="en"> JavaScript's if statement is similar to C's: it can take statements or blocks. The problem with using statements is that a common error is very difficult to detect. It is better to write
if ((e = c.indexOf(';', s)) == -1) e = c.length;
as
if ((e = c.indexOf(';', s)) == -1) { e = c.length; }
Always use blocks in structured statements. </q>
En ce qui concerne le ;, concrètement, à quoi sert-il ? Une fin de ligne est déjà codée, pourquoi rajouter un symbole ?
euhh, peut être pour structurer les instructions et éviter les erreurs d'interprétation ? Et peut être aussi parce que un saut de ligne n'a pas beaucoup plus de signification qu'un espace, sauf dans quelques cas rares (cf [exemple A] ci dessous, exemple direct de ECMA-262 §7.9).
if ( x ) y% z3
Si on met de côté le parse error, c'est pas tout à fait pareil que
if ( x ) y = 25; z = 33;
ou encore
while ( i++ > 25 ) alert(i)
est *totalement* différent de
while ( i++ > 25 ) ; alert(i);
Le ; n'est pas obligatoire ( il devrait ) mais lorsqu'il n'est pas présent c'est à l'interpréteur de le rajouter en fourbe sans en avertir personne. Hors dès qu'il y a intervention automatique sur un source, il y a une dénaturation potentielle des instructions.
Cette règle est extrêmement dangereuse parce que ça peut tout changer lorsqu'il existe un saut de ligne (LineTerminator) à la place du ; supposé être ajouté.
return a + b
Sera transformé, par cette règle 7.9, en
return ; a + b ;
et là, baam, bug introduit par l'insertion automatique puisque à priori l'instruction désirée c'était :
return a + b;
IMO c'est un des gros défauts du langage, ça devrait être soit l'un soit l'autre, mais pas les deux.
Le défaut, c'est surtout de ne pas être typé. C'est ce que je regrette dans tout les langages de scripting (ou presque).
Tiens, c'est rigolo je trouve justement au contraire que c'est une force des langages scriptés. IMO les variables typées ça a une importance quand on compile un source et qu'on doit donc gérer très précisément les zones mémoires attribuées. Tandis que pour les langages scriptés, ben c'est pas au dev de gérer toutes ces saloperies d'adressage mémoire et par conséquent, pas besoin de typer chaque variable.
Je crois que tu n'as pas compris ce qu'est une variable globale :p . Tu as commencé par quel langage de programmation à coder ?
Ohhh que t'es vilain :D
<http://javascript.crockford.com/style2.html>
<cite>Douglas Crockford</cite> <q lang="en"> Global variables are evil </q>
-- laurent
Mais au final, c'est une question de style, pas de défaut du langage.
Je ne suis pas d'accord.
Le langage autorise l'omission des accolades mais je reste persuadé que
c'est une erreur. Erreur induite par la présence de l'omission autorisée
des points-virgules ;
L'absence des accolades n'est pas une omission. C'est justement le
contraire. Le mot clé if est suivi de la condition entre parenthèse puis
d'UNE instruction. L'usage d'accolades, c'est à dire l'introduction d'un
bloc d'instructions, est un contournement.
Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que
Douglas Crockford va dans mon sens, et comme il a largement plus de
crédibilité que moi, je me sens moins seul sur le coup :)
<http://javascript.crockford.com/style1.html>
<cite>Douglas Crockford</cite>
<q lang="en">
JavaScript's if statement is similar to C's: it can take statements or
blocks. The problem with using statements is that a common error is very
difficult to detect. It is better to write
if ((e = c.indexOf(';', s)) == -1)
e = c.length;
as
if ((e = c.indexOf(';', s)) == -1) {
e = c.length;
}
Always use blocks in structured statements.
</q>
En ce qui concerne le ;, concrètement, à quoi sert-il ? Une fin de
ligne est déjà codée, pourquoi rajouter un symbole ?
euhh, peut être pour structurer les instructions et éviter les erreurs
d'interprétation ? Et peut être aussi parce que un saut de ligne n'a pas
beaucoup plus de signification qu'un espace, sauf dans quelques cas
rares (cf [exemple A] ci dessous, exemple direct de ECMA-262 §7.9).
if ( x ) y% z3
Si on met de côté le parse error, c'est pas tout à fait pareil que
if ( x ) y = 25; z = 33;
ou encore
while ( i++ > 25 )
alert(i)
est *totalement* différent de
while ( i++ > 25 ) ;
alert(i);
Le ; n'est pas obligatoire ( il devrait ) mais lorsqu'il n'est pas
présent c'est à l'interpréteur de le rajouter en fourbe sans en avertir
personne. Hors dès qu'il y a intervention automatique sur un source, il
y a une dénaturation potentielle des instructions.
Cette règle est extrêmement dangereuse parce que ça peut tout changer
lorsqu'il existe un saut de ligne (LineTerminator) à la place du ;
supposé être ajouté.
return
a + b
Sera transformé, par cette règle 7.9, en
return ;
a + b ;
et là, baam, bug introduit par l'insertion automatique puisque à priori
l'instruction désirée c'était :
return a + b;
IMO c'est un des gros défauts du langage, ça devrait être soit l'un soit
l'autre, mais pas les deux.
Le défaut, c'est surtout de ne pas être typé. C'est ce que je regrette
dans tout les langages de scripting (ou presque).
Tiens, c'est rigolo je trouve justement au contraire que c'est une force
des langages scriptés. IMO les variables typées ça a une importance
quand on compile un source et qu'on doit donc gérer très précisément les
zones mémoires attribuées. Tandis que pour les langages scriptés, ben
c'est pas au dev de gérer toutes ces saloperies d'adressage mémoire et
par conséquent, pas besoin de typer chaque variable.
Je crois que tu n'as pas compris ce qu'est une variable globale :p .
Tu as commencé par quel langage de programmation à coder ?
Ohhh que t'es vilain :D
<http://javascript.crockford.com/style2.html>
<cite>Douglas Crockford</cite>
<q lang="en">
Global variables are evil
</q>
Mais au final, c'est une question de style, pas de défaut du langage. Je ne suis pas d'accord.
Le langage autorise l'omission des accolades mais je reste persuadé que c'est une erreur. Erreur induite par la présence de l'omission autorisée des points-virgules ;
L'absence des accolades n'est pas une omission. C'est justement le contraire. Le mot clé if est suivi de la condition entre parenthèse puis d'UNE instruction. L'usage d'accolades, c'est à dire l'introduction d'un bloc d'instructions, est un contournement.
Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que Douglas Crockford va dans mon sens, et comme il a largement plus de crédibilité que moi, je me sens moins seul sur le coup :)
<http://javascript.crockford.com/style1.html>
<cite>Douglas Crockford</cite> <q lang="en"> JavaScript's if statement is similar to C's: it can take statements or blocks. The problem with using statements is that a common error is very difficult to detect. It is better to write
if ((e = c.indexOf(';', s)) == -1) e = c.length;
as
if ((e = c.indexOf(';', s)) == -1) { e = c.length; }
Always use blocks in structured statements. </q>
En ce qui concerne le ;, concrètement, à quoi sert-il ? Une fin de ligne est déjà codée, pourquoi rajouter un symbole ?
euhh, peut être pour structurer les instructions et éviter les erreurs d'interprétation ? Et peut être aussi parce que un saut de ligne n'a pas beaucoup plus de signification qu'un espace, sauf dans quelques cas rares (cf [exemple A] ci dessous, exemple direct de ECMA-262 §7.9).
if ( x ) y% z3
Si on met de côté le parse error, c'est pas tout à fait pareil que
if ( x ) y = 25; z = 33;
ou encore
while ( i++ > 25 ) alert(i)
est *totalement* différent de
while ( i++ > 25 ) ; alert(i);
Le ; n'est pas obligatoire ( il devrait ) mais lorsqu'il n'est pas présent c'est à l'interpréteur de le rajouter en fourbe sans en avertir personne. Hors dès qu'il y a intervention automatique sur un source, il y a une dénaturation potentielle des instructions.
Cette règle est extrêmement dangereuse parce que ça peut tout changer lorsqu'il existe un saut de ligne (LineTerminator) à la place du ; supposé être ajouté.
return a + b
Sera transformé, par cette règle 7.9, en
return ; a + b ;
et là, baam, bug introduit par l'insertion automatique puisque à priori l'instruction désirée c'était :
return a + b;
IMO c'est un des gros défauts du langage, ça devrait être soit l'un soit l'autre, mais pas les deux.
Le défaut, c'est surtout de ne pas être typé. C'est ce que je regrette dans tout les langages de scripting (ou presque).
Tiens, c'est rigolo je trouve justement au contraire que c'est une force des langages scriptés. IMO les variables typées ça a une importance quand on compile un source et qu'on doit donc gérer très précisément les zones mémoires attribuées. Tandis que pour les langages scriptés, ben c'est pas au dev de gérer toutes ces saloperies d'adressage mémoire et par conséquent, pas besoin de typer chaque variable.
Je crois que tu n'as pas compris ce qu'est une variable globale :p . Tu as commencé par quel langage de programmation à coder ?
Ohhh que t'es vilain :D
<http://javascript.crockford.com/style2.html>
<cite>Douglas Crockford</cite> <q lang="en"> Global variables are evil </q>
-- laurent
SAM
Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que Douglas Crockford va dans mon sens, et comme il a largement plus de crédibilité que moi, je me sens moins seul sur le coup :)
Je vais encore me mêler de ce qui ne me regarde pas mais ...
<http://javascript.crockford.com/style1.html>
<cite>Douglas Crockford</cite> <q lang="en"> JavaScript's if statement is similar to C's: it can take statements or blocks. The problem with using statements is that a common error is very difficult to detect.
oui, comme il dit : "is that a common error is very difficult to detect" et pas plus. ou à peine ... :
It is better to write
if(...) { blabla; }
à mon idée ... au cas où. (des fois qu'on aurait à développer le statement résultant, le block est déjà là)
Ce peut donc être une bonne habitude ;-)
Bon, et puis ... pour essayer la rigueur crockfordienne : http://jslint.com/ ;-)
-- Stephane Moriaux et son vieux Mac MDD
Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que
Douglas Crockford va dans mon sens, et comme il a largement plus de
crédibilité que moi, je me sens moins seul sur le coup :)
Je vais encore me mêler de ce qui ne me regarde pas mais ...
<http://javascript.crockford.com/style1.html>
<cite>Douglas Crockford</cite>
<q lang="en">
JavaScript's if statement is similar to C's: it can take statements or
blocks. The problem with using statements is that a common error is very
difficult to detect.
oui, comme il dit :
"is that a common error is very difficult to detect"
et pas plus.
ou à peine ... :
It is better to write
if(...) {
blabla;
}
à mon idée ... au cas où.
(des fois qu'on aurait à développer le statement résultant, le block est
déjà là)
Ce peut donc être une bonne habitude ;-)
Bon, et puis ...
pour essayer la rigueur crockfordienne : http://jslint.com/ ;-)
Je ne suis toujours pas d'accord, et ce qui me rassure, c'est que Douglas Crockford va dans mon sens, et comme il a largement plus de crédibilité que moi, je me sens moins seul sur le coup :)
Je vais encore me mêler de ce qui ne me regarde pas mais ...
<http://javascript.crockford.com/style1.html>
<cite>Douglas Crockford</cite> <q lang="en"> JavaScript's if statement is similar to C's: it can take statements or blocks. The problem with using statements is that a common error is very difficult to detect.
oui, comme il dit : "is that a common error is very difficult to detect" et pas plus. ou à peine ... :
It is better to write
if(...) { blabla; }
à mon idée ... au cas où. (des fois qu'on aurait à développer le statement résultant, le block est déjà là)
Ce peut donc être une bonne habitude ;-)
Bon, et puis ... pour essayer la rigueur crockfordienne : http://jslint.com/ ;-)
