C'est pour ca qu'on manipule souvent la version hexadécimale (sur 32 octets alors) plutôt que la version binaire pure, pas très facile à manipuler.
Merci beaucoup de l'information que le md5 est une clée de type Hexadécimale :) Utilisant d'autres fonction de cryptages, j'ai vu un problème là où la solution était évidente.
C'est extrémement facile à filtrer !
Cordialement
Démosthène
C'est pour ca qu'on manipule souvent la version hexadécimale (sur 32
octets alors) plutôt que la version binaire pure, pas très facile à
manipuler.
Merci beaucoup de l'information que le md5 est une clée de type
Hexadécimale :) Utilisant d'autres fonction de cryptages, j'ai vu un
problème là où la solution était évidente.
C'est pour ca qu'on manipule souvent la version hexadécimale (sur 32 octets alors) plutôt que la version binaire pure, pas très facile à manipuler.
Merci beaucoup de l'information que le md5 est une clée de type Hexadécimale :) Utilisant d'autres fonction de cryptages, j'ai vu un problème là où la solution était évidente.
C'est extrémement facile à filtrer !
Cordialement
Démosthène
Demosthene
Et ça change quoi qu'on intercepte le mot de passe en clair ou le mot de passe haché avec md5 puisque de toute façon on intercepte le mot de passe dans le format requis par le système ?
Si on veut sécuriser une interface d'identification avec couple login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur. Ainsi ce n'est jamais le même mot qui transite sur le réseau. Les solutions à base de SSL ne sont pas toujours possible à monter ;)
J'ai perdu la trace du site qui suggère celà, si quelqu'un connait.
Cordialement
Démosthène
Et ça change quoi qu'on intercepte le mot de passe en clair ou le mot de
passe haché avec md5 puisque de toute façon on intercepte le mot de
passe dans le format requis par le système ?
Si on veut sécuriser une interface d'identification avec couple
login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est
différent d'une session à l'autre.
J'évalue actuellement une manière élegante de ne pas transmettre le md5
du mot de password, mais le md5 mélangé avec une graine aléatoire
proposée par le serveur. Ainsi ce n'est jamais le même mot qui transite
sur le réseau. Les solutions à base de SSL ne sont pas toujours possible
à monter ;)
J'ai perdu la trace du site qui suggère celà, si quelqu'un connait.
Et ça change quoi qu'on intercepte le mot de passe en clair ou le mot de passe haché avec md5 puisque de toute façon on intercepte le mot de passe dans le format requis par le système ?
Si on veut sécuriser une interface d'identification avec couple login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur. Ainsi ce n'est jamais le même mot qui transite sur le réseau. Les solutions à base de SSL ne sont pas toujours possible à monter ;)
J'ai perdu la trace du site qui suggère celà, si quelqu'un connait.
Cordialement
Démosthène
Patrick Mevzek
Si on veut sécuriser une interface d'identification avec couple login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur.
Et ca ne résout pas le problème : n'importe qui peut récupérer la graine envoyée par le serveur (en écoutant le flux, chose normalement impossible en SSL), et donc transmettre après ce que le serveur attend.
Encore une fois, il n'y pas d'autres solutions : pour sécuriser l'échange, il faut HTTPS !
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Si on veut sécuriser une interface d'identification avec couple
login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est
différent d'une session à l'autre.
J'évalue actuellement une manière élegante de ne pas transmettre le md5
du mot de password, mais le md5 mélangé avec une graine aléatoire
proposée par le serveur.
Et ca ne résout pas le problème : n'importe qui peut récupérer la
graine envoyée par le serveur (en écoutant le flux, chose normalement
impossible en SSL), et donc transmettre après ce que le serveur attend.
Encore une fois, il n'y pas d'autres solutions : pour sécuriser
l'échange, il faut HTTPS !
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Si on veut sécuriser une interface d'identification avec couple login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur.
Et ca ne résout pas le problème : n'importe qui peut récupérer la graine envoyée par le serveur (en écoutant le flux, chose normalement impossible en SSL), et donc transmettre après ce que le serveur attend.
Encore une fois, il n'y pas d'autres solutions : pour sécuriser l'échange, il faut HTTPS !
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
ftc
Si on veut sécuriser une interface d'identification avec couple login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS. Celà change beaucoup lorsque le format requis par le système est
différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur.
Et ca ne résout pas le problème : n'importe qui peut récupérer la graine envoyée par le serveur (en écoutant le flux, chose normalement impossible en SSL), et donc transmettre après ce que le serveur attend.
Sauf que la personne est déjà identifiée au moment ou le cracker essaiera de pénétrer le système et le salt ne sera déjà plus valide.
Encore une fois, il n'y pas d'autres solutions : pour sécuriser l'échange, il faut HTTPS !
Je suis tout à fait d'accord, mais il est vrai que dans certaines conditions on ne peut recourir à SSL.
Si on veut sécuriser une interface d'identification avec couple
login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS.
Celà change beaucoup lorsque le format requis par le système est
différent d'une session à l'autre.
J'évalue actuellement une manière élegante de ne pas transmettre le md5
du mot de password, mais le md5 mélangé avec une graine aléatoire
proposée par le serveur.
Et ca ne résout pas le problème : n'importe qui peut récupérer la
graine envoyée par le serveur (en écoutant le flux, chose normalement
impossible en SSL), et donc transmettre après ce que le serveur attend.
Sauf que la personne est déjà identifiée au moment ou le cracker
essaiera de pénétrer le système et le salt ne sera déjà plus valide.
Encore une fois, il n'y pas d'autres solutions : pour sécuriser
l'échange, il faut HTTPS !
Je suis tout à fait d'accord, mais il est vrai que dans certaines
conditions on ne peut recourir à SSL.
Si on veut sécuriser une interface d'identification avec couple login/mot_de_passe fixés, la seule solution fiable est d'utiliser HTTPS. Celà change beaucoup lorsque le format requis par le système est
différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur.
Et ca ne résout pas le problème : n'importe qui peut récupérer la graine envoyée par le serveur (en écoutant le flux, chose normalement impossible en SSL), et donc transmettre après ce que le serveur attend.
Sauf que la personne est déjà identifiée au moment ou le cracker essaiera de pénétrer le système et le salt ne sera déjà plus valide.
Encore une fois, il n'y pas d'autres solutions : pour sécuriser l'échange, il faut HTTPS !
Je suis tout à fait d'accord, mais il est vrai que dans certaines conditions on ne peut recourir à SSL.
ftc
Celà change beaucoup lorsque le format requis par le système est différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur. Ainsi ce n'est jamais le même mot qui transite sur le réseau. Les solutions à base de SSL ne sont pas toujours possible à monter ;)
Dans ce cas, je suis d'accord, mais Iragaël parlait de transmettre le mot de passe fixe en md5, le système attendant le mot de passe en md5.
Après on peut rester disserter sur les manière de créer et gérer un "one time password".
Celà change beaucoup lorsque le format requis par le système est
différent d'une session à l'autre.
J'évalue actuellement une manière élegante de ne pas transmettre le md5
du mot de password, mais le md5 mélangé avec une graine aléatoire
proposée par le serveur. Ainsi ce n'est jamais le même mot qui transite
sur le réseau. Les solutions à base de SSL ne sont pas toujours possible
à monter ;)
Dans ce cas, je suis d'accord, mais Iragaël parlait de transmettre le
mot de passe fixe en md5, le système attendant le mot de passe en md5.
Après on peut rester disserter sur les manière de créer et gérer un "one
time password".
Celà change beaucoup lorsque le format requis par le système est différent d'une session à l'autre. J'évalue actuellement une manière élegante de ne pas transmettre le md5 du mot de password, mais le md5 mélangé avec une graine aléatoire proposée par le serveur. Ainsi ce n'est jamais le même mot qui transite sur le réseau. Les solutions à base de SSL ne sont pas toujours possible à monter ;)
Dans ce cas, je suis d'accord, mais Iragaël parlait de transmettre le mot de passe fixe en md5, le système attendant le mot de passe en md5.
Après on peut rester disserter sur les manière de créer et gérer un "one time password".
Vincent Lascaux
Et ca ne résout pas le problème : n'importe qui peut récupérer la graine envoyée par le serveur (en écoutant le flux, chose normalement impossible en SSL), et donc transmettre après ce que le serveur attend.
Si le serveur attend md5(graine + mot de passe), que tu as déjà intercepté plusieurs échanges (donc t'as plusieurs couples (graine, md5(graine + mdp)) pour des graines différentes), tu ne peux pas pour autant générer md5(graine + mot de passe) pour la graine que le serveur t'envoie... Donc cette méthode "résout le probleme" il me semble (même si c'est claire qu'en informatique et surtout en matière de sécu il est préférable de ne pas réinventer la roue)
-- Vincent
Et ca ne résout pas le problème : n'importe qui peut récupérer la
graine envoyée par le serveur (en écoutant le flux, chose normalement
impossible en SSL), et donc transmettre après ce que le serveur attend.
Si le serveur attend md5(graine + mot de passe), que tu as déjà intercepté
plusieurs échanges (donc t'as plusieurs couples (graine, md5(graine + mdp))
pour des graines différentes), tu ne peux pas pour autant générer md5(graine
+ mot de passe) pour la graine que le serveur t'envoie... Donc cette méthode
"résout le probleme" il me semble (même si c'est claire qu'en informatique
et surtout en matière de sécu il est préférable de ne pas réinventer la
roue)
Et ca ne résout pas le problème : n'importe qui peut récupérer la graine envoyée par le serveur (en écoutant le flux, chose normalement impossible en SSL), et donc transmettre après ce que le serveur attend.
Si le serveur attend md5(graine + mot de passe), que tu as déjà intercepté plusieurs échanges (donc t'as plusieurs couples (graine, md5(graine + mdp)) pour des graines différentes), tu ne peux pas pour autant générer md5(graine + mot de passe) pour la graine que le serveur t'envoie... Donc cette méthode "résout le probleme" il me semble (même si c'est claire qu'en informatique et surtout en matière de sécu il est préférable de ne pas réinventer la roue)
-- Vincent
Patrick Mevzek
Donc cette méthode "résout le probleme" il me semble
Pas tout à fait selon moi, cf mes différents arguments dans mon précédent long message pour indiquer tout ce qu'il faut dans le digest. Ici pas de secret possible (car l'envoyer au client fait disparaitre sa nature même de secret donc), ce qui affaiblit le résultat.
(même si c'est claire qu'en informatique et surtout en matière de sécu il est préférable de ne pas réinventer la roue)
D'où mon profond désaccord pour dire que cette méthode vaut mieux que HTTPS. Outre ses nombreuses limitations (il faut javascript, et MD5 n'est plus recommandé de nos jours), on croit souvent tomber sur quelque chose de génial en bidouillant, mais en sécurité/cryptographie c'est pas forcément une bonne voie.
Le problème n'est pas qu'un mot de passe, il y a bien d'autres choses à sécuriser. Par exemple le numéro de carte bancaire. Vous allez aussi l'envoyer après moulinette MD5 du côté du client ? C'est la banque qui va être contente ...
A partir du moment où l'on voit que c'est l'échange qu'on doit protéger, il faut HTTPS, il n'y a pas à tergiverser. Et les experts vous diront que les mots de passe, c'est has been de toute façon, il faut d'autres technologies en plus/à la place (biométrie, OTP, etc...)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Donc cette méthode
"résout le probleme" il me semble
Pas tout à fait selon moi, cf mes différents arguments dans mon
précédent long message pour indiquer tout ce qu'il faut dans le digest.
Ici pas de secret possible (car l'envoyer au client fait disparaitre sa
nature même de secret donc), ce qui affaiblit le résultat.
(même si c'est claire qu'en informatique
et surtout en matière de sécu il est préférable de ne pas réinventer la
roue)
D'où mon profond désaccord pour dire que cette méthode vaut mieux que
HTTPS.
Outre ses nombreuses limitations (il faut javascript, et MD5 n'est plus
recommandé de nos jours), on croit souvent tomber sur quelque chose de
génial en bidouillant, mais en sécurité/cryptographie c'est pas
forcément une bonne voie.
Le problème n'est pas qu'un mot de passe, il y a bien d'autres choses à
sécuriser. Par exemple le numéro de carte bancaire. Vous allez aussi
l'envoyer après moulinette MD5 du côté du client ? C'est la banque qui
va être contente ...
A partir du moment où l'on voit que c'est l'échange qu'on doit
protéger, il faut HTTPS, il n'y a pas à tergiverser. Et les experts vous
diront que les mots de passe, c'est has been de toute façon, il faut
d'autres technologies en plus/à la place (biométrie, OTP, etc...)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Donc cette méthode "résout le probleme" il me semble
Pas tout à fait selon moi, cf mes différents arguments dans mon précédent long message pour indiquer tout ce qu'il faut dans le digest. Ici pas de secret possible (car l'envoyer au client fait disparaitre sa nature même de secret donc), ce qui affaiblit le résultat.
(même si c'est claire qu'en informatique et surtout en matière de sécu il est préférable de ne pas réinventer la roue)
D'où mon profond désaccord pour dire que cette méthode vaut mieux que HTTPS. Outre ses nombreuses limitations (il faut javascript, et MD5 n'est plus recommandé de nos jours), on croit souvent tomber sur quelque chose de génial en bidouillant, mais en sécurité/cryptographie c'est pas forcément une bonne voie.
Le problème n'est pas qu'un mot de passe, il y a bien d'autres choses à sécuriser. Par exemple le numéro de carte bancaire. Vous allez aussi l'envoyer après moulinette MD5 du côté du client ? C'est la banque qui va être contente ...
A partir du moment où l'on voit que c'est l'échange qu'on doit protéger, il faut HTTPS, il n'y a pas à tergiverser. Et les experts vous diront que les mots de passe, c'est has been de toute façon, il faut d'autres technologies en plus/à la place (biométrie, OTP, etc...)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Demosthene
Patrick Mevzek wrote:
Donc cette méthode "résout le probleme" il me semble
Pas tout à fait selon moi, cf mes différents arguments dans mon précédent long message pour indiquer tout ce qu'il faut dans le digest. Ici pas de secret possible (car l'envoyer au client fait disparaitre sa nature même de secret donc), ce qui affaiblit le résultat.
(même si c'est claire qu'en informatique et surtout en matière de sécu il est préférable de ne pas réinventer la roue)
D'où mon profond désaccord pour dire que cette méthode vaut mieux que HTTPS.
Nulle part dans ce thread, il n'a été question de trouver quelque chose de meilleur que l'https, mais bien plutôt de la moins pire des solutions lorsque l'https n'est pas possible (coût, technique ...).
Merci de refaire le point sur l'https : plus en en parlera mieux celà vaudra pour tout le monde.
Cordialement
Démosthène
Patrick Mevzek wrote:
Donc cette méthode
"résout le probleme" il me semble
Pas tout à fait selon moi, cf mes différents arguments dans mon
précédent long message pour indiquer tout ce qu'il faut dans le digest.
Ici pas de secret possible (car l'envoyer au client fait disparaitre sa
nature même de secret donc), ce qui affaiblit le résultat.
(même si c'est claire qu'en informatique
et surtout en matière de sécu il est préférable de ne pas réinventer la
roue)
D'où mon profond désaccord pour dire que cette méthode vaut mieux que
HTTPS.
Nulle part dans ce thread, il n'a été question de trouver quelque chose
de meilleur que l'https, mais bien plutôt de la moins pire des solutions
lorsque l'https n'est pas possible (coût, technique ...).
Merci de refaire le point sur l'https : plus en en parlera mieux celà
vaudra pour tout le monde.
Donc cette méthode "résout le probleme" il me semble
Pas tout à fait selon moi, cf mes différents arguments dans mon précédent long message pour indiquer tout ce qu'il faut dans le digest. Ici pas de secret possible (car l'envoyer au client fait disparaitre sa nature même de secret donc), ce qui affaiblit le résultat.
(même si c'est claire qu'en informatique et surtout en matière de sécu il est préférable de ne pas réinventer la roue)
D'où mon profond désaccord pour dire que cette méthode vaut mieux que HTTPS.
Nulle part dans ce thread, il n'a été question de trouver quelque chose de meilleur que l'https, mais bien plutôt de la moins pire des solutions lorsque l'https n'est pas possible (coût, technique ...).
Merci de refaire le point sur l'https : plus en en parlera mieux celà vaudra pour tout le monde.
Cordialement
Démosthène
Patrick Mevzek
D'où mon profond désaccord pour dire que cette méthode vaut mieux que HTTPS.
Nulle part dans ce thread, il n'a été question de trouver quelque chose de meilleur que l'https,
Oui, c'est un raccourci de ma part.
mais bien plutôt de la moins pire des solutions lorsque l'https n'est pas possible (coût, technique ...).
Pour moi les deux seules ce sont : - faire le nécessaire pour que HTTPS soit activé - abandonner l'idée de faire une authentification et un site «sécurisé»
Mais on me dit facilement extrêmiste :-) En tout cas ces deux solutions me paraissent moins casse gueule qu'un bricolage.
Merci de refaire le point sur l'https : plus en en parlera mieux celà vaudra pour tout le monde.
Il y aurait tant à dire (rien qu'à partir de ma phrase précédente, vu que HTTPS et site sécurisé sont deux concepts orthogonaux) mais on est définitivement pas dans le groupe adapté. Si quelqu'un veut reprendre la discussion, merci de penser à basculer ailleurs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
D'où mon profond désaccord pour dire que cette méthode vaut mieux que
HTTPS.
Nulle part dans ce thread, il n'a été question de trouver quelque chose
de meilleur que l'https,
Oui, c'est un raccourci de ma part.
mais bien plutôt de la moins pire des solutions
lorsque l'https n'est pas possible (coût, technique ...).
Pour moi les deux seules ce sont :
- faire le nécessaire pour que HTTPS soit activé
- abandonner l'idée de faire une authentification et un site «sécurisé»
Mais on me dit facilement extrêmiste :-)
En tout cas ces deux solutions me paraissent moins casse gueule qu'un
bricolage.
Merci de refaire le point sur l'https : plus en en parlera mieux celà
vaudra pour tout le monde.
Il y aurait tant à dire (rien qu'à partir de ma phrase précédente,
vu que HTTPS et site sécurisé sont deux concepts orthogonaux) mais on
est définitivement pas dans le groupe adapté.
Si quelqu'un veut reprendre la discussion, merci de penser à basculer
ailleurs.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
D'où mon profond désaccord pour dire que cette méthode vaut mieux que HTTPS.
Nulle part dans ce thread, il n'a été question de trouver quelque chose de meilleur que l'https,
Oui, c'est un raccourci de ma part.
mais bien plutôt de la moins pire des solutions lorsque l'https n'est pas possible (coût, technique ...).
Pour moi les deux seules ce sont : - faire le nécessaire pour que HTTPS soit activé - abandonner l'idée de faire une authentification et un site «sécurisé»
Mais on me dit facilement extrêmiste :-) En tout cas ces deux solutions me paraissent moins casse gueule qu'un bricolage.
Merci de refaire le point sur l'https : plus en en parlera mieux celà vaudra pour tout le monde.
Il y aurait tant à dire (rien qu'à partir de ma phrase précédente, vu que HTTPS et site sécurisé sont deux concepts orthogonaux) mais on est définitivement pas dans le groupe adapté. Si quelqu'un veut reprendre la discussion, merci de penser à basculer ailleurs.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
