Un site auquel j'accède régulièrement utilise un accès sécurisé RC4 128 bits
Ce qui me semble bizarre, c'est que je puisse, en capturant les entêtes
HTTP, voire les informations "en clair". Est-ce normal? Sûr?
Ci-dessous, copie de l'entête (j'ai modifé les informations sensibles)
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
Sylvain Eche
quand tu parles d'accès sécurisé RC4 128 bits j'imagine que tu parles de HTTPS (ssl)
si ton site est encodé en ssl, c'est une couche entre tcp et http donc la totalité des trames HTTPS sont chiffrées, tu ne dois rien voir. après il faut voir comment tu captures tes entêtes HTTP : si c'est avec un pluggin firefox, il se peut que tu les récupère avant que le moteur SSL ait agit. fait une capture réseau avec ethereal pour en être sur et la tu verras que tout en chiffré a+
Bonjour,
Un site auquel j'accède régulièrement utilise un accès sécurisé RC4 128 bits Ce qui me semble bizarre, c'est que je puisse, en capturant les entêtes HTTP, voire les informations "en clair". Est-ce normal? Sûr? Ci-dessous, copie de l'entête (j'ai modifé les informations sensibles)
quand tu parles d'accès sécurisé RC4 128 bits j'imagine que tu parles de
HTTPS (ssl)
si ton site est encodé en ssl, c'est une couche entre tcp et http donc
la totalité des trames HTTPS sont chiffrées, tu ne dois rien voir.
après il faut voir comment tu captures tes entêtes HTTP : si c'est avec
un pluggin firefox, il se peut que tu les récupère avant que le moteur
SSL ait agit.
fait une capture réseau avec ethereal pour en être sur et la tu verras
que tout en chiffré
a+
Bonjour,
Un site auquel j'accède régulièrement utilise un accès sécurisé RC4 128 bits
Ce qui me semble bizarre, c'est que je puisse, en capturant les entêtes
HTTP, voire les informations "en clair". Est-ce normal? Sûr?
Ci-dessous, copie de l'entête (j'ai modifé les informations sensibles)
quand tu parles d'accès sécurisé RC4 128 bits j'imagine que tu parles de HTTPS (ssl)
si ton site est encodé en ssl, c'est une couche entre tcp et http donc la totalité des trames HTTPS sont chiffrées, tu ne dois rien voir. après il faut voir comment tu captures tes entêtes HTTP : si c'est avec un pluggin firefox, il se peut que tu les récupère avant que le moteur SSL ait agit. fait une capture réseau avec ethereal pour en être sur et la tu verras que tout en chiffré a+
Bonjour,
Un site auquel j'accède régulièrement utilise un accès sécurisé RC4 128 bits Ce qui me semble bizarre, c'est que je puisse, en capturant les entêtes HTTP, voire les informations "en clair". Est-ce normal? Sûr? Ci-dessous, copie de l'entête (j'ai modifé les informations sensibles)
Un site auquel j'accède régulièrement utilise un accès sécurisé RC4 128 bits Ce qui me semble bizarre, c'est que je puisse, en capturant les entêtes HTTP, voire les informations "en clair". Est-ce normal? Sûr?
La réponse de Sylvain est tout à fait juste : en HTTPS, tout est chiffré et les informations reniflées sur le réseau ne sont pas exploitables. Cependant, la transmission d'un mot de passe sur le serveur n'est pas pour rassurer, car cela signifie qu'il est sans doute stocké en clair dans la base de données et que l'administrateur du système y a accès.
Si l'ordinateur est piraté, le pirate a accès aux mots de passe...
-- David Jourand
Omvdc a écrit :
Un site auquel j'accède régulièrement utilise un accès sécurisé
RC4 128 bits Ce qui me semble bizarre, c'est que je puisse, en capturant
les entêtes HTTP, voire les informations "en clair". Est-ce normal?
Sûr?
La réponse de Sylvain est tout à fait juste : en HTTPS, tout est
chiffré et les informations reniflées sur le réseau ne sont pas
exploitables. Cependant, la transmission d'un mot de passe sur le serveur
n'est pas pour rassurer, car cela signifie qu'il est sans doute stocké en
clair dans la base de données et que l'administrateur du système y a
accès.
Si l'ordinateur est piraté, le pirate a accès aux mots de passe...
Un site auquel j'accède régulièrement utilise un accès sécurisé RC4 128 bits Ce qui me semble bizarre, c'est que je puisse, en capturant les entêtes HTTP, voire les informations "en clair". Est-ce normal? Sûr?
La réponse de Sylvain est tout à fait juste : en HTTPS, tout est chiffré et les informations reniflées sur le réseau ne sont pas exploitables. Cependant, la transmission d'un mot de passe sur le serveur n'est pas pour rassurer, car cela signifie qu'il est sans doute stocké en clair dans la base de données et que l'administrateur du système y a accès.
Si l'ordinateur est piraté, le pirate a accès aux mots de passe...
-- David Jourand
Nicolas George
David JOURAND wrote in message :
La réponse de Sylvain est tout à fait juste : en HTTPS, tout est chiffré et les informations reniflées sur le réseau ne sont pas exploitables. Cependant, la transmission d'un mot de passe sur le serveur n'est pas pour rassurer, car cela signifie qu'il est sans doute stocké en clair dans la base de données et que l'administrateur du système y a accès.
Si l'ordinateur est piraté, le pirate a accès aux mots de passe...
À moins d'avoir recours à la crypto asymétrique (des certificats, donc, ce qui est nettement plus lourd à mettre en place, et très nettement plus difficile à faire comprendre aux utilisateurs), on a au mieux :
- le mot de passe est envoyé en clair, et stocké sous forme de hash sur le serveur ;
- le mot de passe est envoyé sous forme de hash avec un sel fourni par le serveur, mais il doit alors être stocké en clair sur le serveur.
Si on a déjà du HTTPS, la seconde solution n'apporte vraiment rien, et complique considérablement les chose (miam, calculer un SHA-256 en javascript).
Au contraire, le fait que le mot de passe soit envoyé en clair laisse ouverte la possibilité qu'il soit stocké en chiffré sur le serveur.
David JOURAND wrote in message
<pan.2006.08.28.13.00.59.802013@cutthis.laposte.net.invalid>:
La réponse de Sylvain est tout à fait juste : en HTTPS, tout est
chiffré et les informations reniflées sur le réseau ne sont pas
exploitables. Cependant, la transmission d'un mot de passe sur le serveur
n'est pas pour rassurer, car cela signifie qu'il est sans doute stocké en
clair dans la base de données et que l'administrateur du système y a
accès.
Si l'ordinateur est piraté, le pirate a accès aux mots de passe...
À moins d'avoir recours à la crypto asymétrique (des certificats, donc, ce
qui est nettement plus lourd à mettre en place, et très nettement plus
difficile à faire comprendre aux utilisateurs), on a au mieux :
- le mot de passe est envoyé en clair, et stocké sous forme de hash sur le
serveur ;
- le mot de passe est envoyé sous forme de hash avec un sel fourni par le
serveur, mais il doit alors être stocké en clair sur le serveur.
Si on a déjà du HTTPS, la seconde solution n'apporte vraiment rien, et
complique considérablement les chose (miam, calculer un SHA-256 en
javascript).
Au contraire, le fait que le mot de passe soit envoyé en clair laisse
ouverte la possibilité qu'il soit stocké en chiffré sur le serveur.
La réponse de Sylvain est tout à fait juste : en HTTPS, tout est chiffré et les informations reniflées sur le réseau ne sont pas exploitables. Cependant, la transmission d'un mot de passe sur le serveur n'est pas pour rassurer, car cela signifie qu'il est sans doute stocké en clair dans la base de données et que l'administrateur du système y a accès.
Si l'ordinateur est piraté, le pirate a accès aux mots de passe...
À moins d'avoir recours à la crypto asymétrique (des certificats, donc, ce qui est nettement plus lourd à mettre en place, et très nettement plus difficile à faire comprendre aux utilisateurs), on a au mieux :
- le mot de passe est envoyé en clair, et stocké sous forme de hash sur le serveur ;
- le mot de passe est envoyé sous forme de hash avec un sel fourni par le serveur, mais il doit alors être stocké en clair sur le serveur.
Si on a déjà du HTTPS, la seconde solution n'apporte vraiment rien, et complique considérablement les chose (miam, calculer un SHA-256 en javascript).
Au contraire, le fait que le mot de passe soit envoyé en clair laisse ouverte la possibilité qu'il soit stocké en chiffré sur le serveur.
Omvdc
"Sylvain Eche" a écrit dans le message de news: 44f1ff6e$0$26005$
quand tu parles d'accès sécurisé RC4 128 bits j'imagine que tu parles de HTTPS (ssl)
si ton site est encodé en ssl, c'est une couche entre tcp et http donc la totalité des trames HTTPS sont chiffrées, tu ne dois rien voir. après il faut voir comment tu captures tes entêtes HTTP : si c'est avec un pluggin firefox, il se peut que tu les récupère avant que le moteur SSL ait agit. fait une capture réseau avec ethereal pour en être sur et la tu verras que tout en chiffré a+
Snip
en effet, en utilisant Ethereal, j'ai pu me rendre compte que les informations sortantes sont totalement illisibles. Me voilà rassuré :-)
Merci pour votre aide
Omvdc
"Sylvain Eche" <sylvaineche@free.fr> a écrit dans le message de news:
44f1ff6e$0$26005$626a54ce@news.free.fr...
quand tu parles d'accès sécurisé RC4 128 bits j'imagine que tu parles de
HTTPS (ssl)
si ton site est encodé en ssl, c'est une couche entre tcp et http donc la
totalité des trames HTTPS sont chiffrées, tu ne dois rien voir.
après il faut voir comment tu captures tes entêtes HTTP : si c'est avec un
pluggin firefox, il se peut que tu les récupère avant que le moteur SSL
ait agit.
fait une capture réseau avec ethereal pour en être sur et la tu verras que
tout en chiffré
a+
Snip
en effet, en utilisant Ethereal, j'ai pu me rendre compte que les
informations sortantes sont totalement illisibles. Me voilà rassuré :-)
"Sylvain Eche" a écrit dans le message de news: 44f1ff6e$0$26005$
quand tu parles d'accès sécurisé RC4 128 bits j'imagine que tu parles de HTTPS (ssl)
si ton site est encodé en ssl, c'est une couche entre tcp et http donc la totalité des trames HTTPS sont chiffrées, tu ne dois rien voir. après il faut voir comment tu captures tes entêtes HTTP : si c'est avec un pluggin firefox, il se peut que tu les récupère avant que le moteur SSL ait agit. fait une capture réseau avec ethereal pour en être sur et la tu verras que tout en chiffré a+
Snip
en effet, en utilisant Ethereal, j'ai pu me rendre compte que les informations sortantes sont totalement illisibles. Me voilà rassuré :-)
Merci pour votre aide
Omvdc
David JOURAND
Nicolas George a écrit :
- le mot de passe est envoyé en clair, et stocké sous forme de hash sur le serveur ;
- le mot de passe est envoyé sous forme de hash avec un sel fourni par le serveur, mais il doit alors être stocké en clair sur le serveur.
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript MD5 est très rapide). Bien sûr, ce n'est pas une solution miracle, mais elle offre de bonne garantie à l'utilisateur, tout en restant simple à expliquer.
-- David Jourand
Nicolas George a écrit :
- le mot de passe est envoyé en clair, et stocké sous forme de hash sur le
serveur ;
- le mot de passe est envoyé sous forme de hash avec un sel fourni par le
serveur, mais il doit alors être stocké en clair sur le serveur.
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
MD5 est très rapide). Bien sûr, ce n'est pas une solution miracle, mais
elle offre de bonne garantie à l'utilisateur, tout en restant simple à
expliquer.
- le mot de passe est envoyé en clair, et stocké sous forme de hash sur le serveur ;
- le mot de passe est envoyé sous forme de hash avec un sel fourni par le serveur, mais il doit alors être stocké en clair sur le serveur.
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript MD5 est très rapide). Bien sûr, ce n'est pas une solution miracle, mais elle offre de bonne garantie à l'utilisateur, tout en restant simple à expliquer.
-- David Jourand
Nicolas George
David JOURAND wrote in message :
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
De deux choses l'une :
- soit le client envoie au serveur le hash du mot de passe tout seul,
- soit le client envoie au serveur le hash du mot de passe salé par une information variable imposée par le serveur.
Dans le premier cas, l'opération de hash ne sert à rien : le hashé est constant, et suffit à s'authentifier. En quelque sorte, c'est le hashé qui est le vrai mot de passe, et ce que tape l'utilisateur n'est qu'un moyen mnémotechnique pour le retrouver. Ce schéma élimine les attaquants ineptes qui ne savent que taper le mot de passe intercepté dans le formulaire original. Mais dès que l'attaquant sait faire ses propres requêtes, ce schéma n'apporte strictement aucune sécurité par rapport à l'envoi du mot de passe en clair.
Dans le second cas, il y a effectivement de la sécurité accrue : un hashé intercepté ne sert à rien, parce que le serveur ne réutilisera pas le même sel. Mais pour pouvoir vérifier un hashé, le serveur a besoin d'avoir, dans sa base de données des utilisateurs, le mot de passe en clair. Ce qui est précisément ce dont se plaignait le posteur original.
Dans les deux cas, quelqu'un qui arrive à espionner côté serveur a tout le nécessaire pour s'authentifier à l'avenir, soit venant du client, soit venant des bases de données du serveur.
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de l'employer de manière sûre, en faisant attention, mais il est déconseillé de l'utiliser dans la conception de nouveaux protocoles.
David JOURAND wrote in message
<pan.2006.08.30.09.14.09.392088@cutthis.laposte.net.invalid>:
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
De deux choses l'une :
- soit le client envoie au serveur le hash du mot de passe tout seul,
- soit le client envoie au serveur le hash du mot de passe salé par une
information variable imposée par le serveur.
Dans le premier cas, l'opération de hash ne sert à rien : le hashé est
constant, et suffit à s'authentifier. En quelque sorte, c'est le hashé qui
est le vrai mot de passe, et ce que tape l'utilisateur n'est qu'un moyen
mnémotechnique pour le retrouver. Ce schéma élimine les attaquants ineptes
qui ne savent que taper le mot de passe intercepté dans le formulaire
original. Mais dès que l'attaquant sait faire ses propres requêtes, ce
schéma n'apporte strictement aucune sécurité par rapport à l'envoi du mot de
passe en clair.
Dans le second cas, il y a effectivement de la sécurité accrue : un hashé
intercepté ne sert à rien, parce que le serveur ne réutilisera pas le même
sel. Mais pour pouvoir vérifier un hashé, le serveur a besoin d'avoir, dans
sa base de données des utilisateurs, le mot de passe en clair. Ce qui est
précisément ce dont se plaignait le posteur original.
Dans les deux cas, quelqu'un qui arrive à espionner côté serveur a tout le
nécessaire pour s'authentifier à l'avenir, soit venant du client, soit
venant des bases de données du serveur.
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de
l'employer de manière sûre, en faisant attention, mais il est déconseillé de
l'utiliser dans la conception de nouveaux protocoles.
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
De deux choses l'une :
- soit le client envoie au serveur le hash du mot de passe tout seul,
- soit le client envoie au serveur le hash du mot de passe salé par une information variable imposée par le serveur.
Dans le premier cas, l'opération de hash ne sert à rien : le hashé est constant, et suffit à s'authentifier. En quelque sorte, c'est le hashé qui est le vrai mot de passe, et ce que tape l'utilisateur n'est qu'un moyen mnémotechnique pour le retrouver. Ce schéma élimine les attaquants ineptes qui ne savent que taper le mot de passe intercepté dans le formulaire original. Mais dès que l'attaquant sait faire ses propres requêtes, ce schéma n'apporte strictement aucune sécurité par rapport à l'envoi du mot de passe en clair.
Dans le second cas, il y a effectivement de la sécurité accrue : un hashé intercepté ne sert à rien, parce que le serveur ne réutilisera pas le même sel. Mais pour pouvoir vérifier un hashé, le serveur a besoin d'avoir, dans sa base de données des utilisateurs, le mot de passe en clair. Ce qui est précisément ce dont se plaignait le posteur original.
Dans les deux cas, quelqu'un qui arrive à espionner côté serveur a tout le nécessaire pour s'authentifier à l'avenir, soit venant du client, soit venant des bases de données du serveur.
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de l'employer de manière sûre, en faisant attention, mais il est déconseillé de l'utiliser dans la conception de nouveaux protocoles.
David JOURAND
Nicolas George a écrit :
David JOURAND wrote in message :
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
Vous avez raison...
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de l'employer de manière sûre, en faisant attention, mais il est déconseillé de l'utiliser dans la conception de nouveaux protocoles.
Cela dépend du niveau de sécurité que l'on souhaite mettre en place. On peut toujours utiliser MD5 si l'on ne souhaite pas avoir une protection digne du pentagone ;-)
-- David Jourand
Nicolas George a écrit :
David JOURAND wrote in message
<pan.2006.08.30.09.14.09.392088@cutthis.laposte.net.invalid>:
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
Vous avez raison...
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de
l'employer de manière sûre, en faisant attention, mais il est déconseillé de
l'utiliser dans la conception de nouveaux protocoles.
Cela dépend du niveau de sécurité que l'on souhaite mettre en place. On
peut toujours utiliser MD5 si l'on ne souhaite pas avoir une protection
digne du pentagone ;-)
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
Vous avez raison...
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de l'employer de manière sûre, en faisant attention, mais il est déconseillé de l'utiliser dans la conception de nouveaux protocoles.
Cela dépend du niveau de sécurité que l'on souhaite mettre en place. On peut toujours utiliser MD5 si l'on ne souhaite pas avoir une protection digne du pentagone ;-)
-- David Jourand
Omvdc
Snip
David JOURAND wrote in message :
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
Vous avez raison...
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de l'employer de manière sûre, en faisant attention, mais il est déconseillé de l'utiliser dans la conception de nouveaux protocoles.
Cela dépend du niveau de sécurité que l'on souhaite mettre en place. On peut toujours utiliser MD5 si l'on ne souhaite pas avoir une protection digne du pentagone ;-)
-- David Jourand
Tout ça c'est bien joli, mais est-ce que l'utilisateur peut mettre en place ces méthodes de chiffrement depuis chez lui ou bien est-il tributaire de la "politique de sécurité" mis en place par le fournisseur de service? Je me vois mal arriver avec ma clef PGP chez mon banquier en lui disant que c'est avec ça dorénavant qu'il faut communiquer (je ne vous raconte pas la difficulté que j'ai eu à expliquer à mes amis proches de l'utilité de crypter ses mails, même si "je n'ai rien à cacher")
Omvdc
Snip
David JOURAND wrote in message
<pan.2006.08.30.09.14.09.392088@cutthis.laposte.net.invalid>:
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
Vous avez raison...
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de
l'employer de manière sûre, en faisant attention, mais il est déconseillé
de
l'utiliser dans la conception de nouveaux protocoles.
Cela dépend du niveau de sécurité que l'on souhaite mettre en place. On
peut toujours utiliser MD5 si l'on ne souhaite pas avoir une protection
digne du pentagone ;-)
--
David Jourand
Tout ça c'est bien joli, mais est-ce que l'utilisateur peut mettre en place
ces méthodes de chiffrement depuis chez lui ou bien est-il tributaire de la
"politique de sécurité" mis en place par le fournisseur de service?
Je me vois mal arriver avec ma clef PGP chez mon banquier en lui disant que
c'est avec ça dorénavant qu'il faut communiquer (je ne vous raconte pas la
difficulté que j'ai eu à expliquer à mes amis proches de l'utilité de
crypter ses mails, même si "je n'ai rien à cacher")
Troisième possibilité : HTTPS + envoyer le hash au serveur (javascript
Non, ça ne marche pas, justement.
Vous avez raison...
MD5 est très rapide)
Je rappelle au passage que MD5 est cassé. Il est toujours possible de l'employer de manière sûre, en faisant attention, mais il est déconseillé de l'utiliser dans la conception de nouveaux protocoles.
Cela dépend du niveau de sécurité que l'on souhaite mettre en place. On peut toujours utiliser MD5 si l'on ne souhaite pas avoir une protection digne du pentagone ;-)
-- David Jourand
Tout ça c'est bien joli, mais est-ce que l'utilisateur peut mettre en place ces méthodes de chiffrement depuis chez lui ou bien est-il tributaire de la "politique de sécurité" mis en place par le fournisseur de service? Je me vois mal arriver avec ma clef PGP chez mon banquier en lui disant que c'est avec ça dorénavant qu'il faut communiquer (je ne vous raconte pas la difficulté que j'ai eu à expliquer à mes amis proches de l'utilité de crypter ses mails, même si "je n'ai rien à cacher")
Omvdc
Fabien LE LEZ
On 31 Aug 2006 00:52:08 GMT, David JOURAND :
On peut toujours utiliser MD5
Ben... Bof. On sait qu'il est cassé, et il y a des alternatives plus sûres et tout aussi faciles à utiliser. Je ne vois pas de raison valable de baser un nouveau système sur MD5.
On 31 Aug 2006 00:52:08 GMT, David JOURAND :
On peut toujours utiliser MD5
Ben... Bof. On sait qu'il est cassé, et il y a des alternatives plus
sûres et tout aussi faciles à utiliser. Je ne vois pas de raison
valable de baser un nouveau système sur MD5.
Ben... Bof. On sait qu'il est cassé, et il y a des alternatives plus sûres et tout aussi faciles à utiliser. Je ne vois pas de raison valable de baser un nouveau système sur MD5.
