Bonjour
Si vous avez encore une ligne france telecom, vous avez droit à un
espace client on line sur lequel vous pouvez régler vos factures par
cb
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas
sur un layer https : qu'en pensez vous, puis je me risquer à utiliser
cette interface de paiement ? Celà vous parrait il normal de la part
d'une grande entreprise du secteur telecom informatique ?
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
Xavier Roche
mrique wrote:
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas sur un layer https
L'important c'est que la ressource qui réceptionne ce numéro soit en https (càd probablement la page d'arrivée, celle indiquée dans le <form action="..">) . Que la page initiale soit en HTTP n'a que peu d'importance. C'est le cas ici, si je ne me trompe.
On peut même imaginer une page en http, avec un formulaire qui envoie sur du https, qui a son tour retourne un code de redirection HTTP (erreur 30X). Le client ne "verra" jamais de https mais tout sera sécurisé.
La plupart des sites proposent du https DES la saisie du n° de CB, pour permettre au client 1- d'être rassuré (même si ca sert à rien, encore une fois) 2- éventuellement de vérifier tranquillement que le certificat est OK
Le point 1 est plus important qu'on ne croit, visiblement :p
mrique wrote:
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas
sur un layer https
L'important c'est que la ressource qui réceptionne ce numéro soit en
https (càd probablement la page d'arrivée, celle indiquée dans le <form
action="..">) . Que la page initiale soit en HTTP n'a que peu
d'importance. C'est le cas ici, si je ne me trompe.
On peut même imaginer une page en http, avec un formulaire qui envoie
sur du https, qui a son tour retourne un code de redirection HTTP
(erreur 30X). Le client ne "verra" jamais de https mais tout sera sécurisé.
La plupart des sites proposent du https DES la saisie du n° de CB, pour
permettre au client
1- d'être rassuré (même si ca sert à rien, encore une fois)
2- éventuellement de vérifier tranquillement que le certificat est OK
Le point 1 est plus important qu'on ne croit, visiblement :p
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas sur un layer https
L'important c'est que la ressource qui réceptionne ce numéro soit en https (càd probablement la page d'arrivée, celle indiquée dans le <form action="..">) . Que la page initiale soit en HTTP n'a que peu d'importance. C'est le cas ici, si je ne me trompe.
On peut même imaginer une page en http, avec un formulaire qui envoie sur du https, qui a son tour retourne un code de redirection HTTP (erreur 30X). Le client ne "verra" jamais de https mais tout sera sécurisé.
La plupart des sites proposent du https DES la saisie du n° de CB, pour permettre au client 1- d'être rassuré (même si ca sert à rien, encore une fois) 2- éventuellement de vérifier tranquillement que le certificat est OK
Le point 1 est plus important qu'on ne croit, visiblement :p
Cedric Blancher
Le Sat, 12 Mar 2005 12:55:04 +0000, Xavier Roche a écrit :
L'important c'est que la ressource qui réceptionne ce numéro soit en https (càd probablement la page d'arrivée, celle indiquée dans le <form action="..">) . Que la page initiale soit en HTTP n'a que peu d'importance. C'est le cas ici, si je ne me trompe.
Effectivement, c'est aussi ce que j'avais répondu benoîtement il y a quelques temps à une question du même genre. Mais le fait est que si la page du formulaire n'est pas en HTTPS, qu'est-ce qui t'assure que la cible du formulaire est bien la bonne tant que tu n'auras pas regardé le code source de la page ? Ben en fait pas grand chose. C'est que Alain et Jacques me faisait très justement remarquer dans ces deux messages :
On peut en effet tout à fait imaginer un faux site de base avec un formulaire qui pointera sur un faux site HTTPS avec un certificat tout à fait cohérent avec le site en question. Si c'est bien fait, tu n'y verras pas grand chose.
-- Si maintenant on introduit le concept de normalité des bugs, où va l'informatique ? Chez Microsoft ? Ah oui, pas faux ça. -+- GG in Guide du Macounet Pervers : R i F, you'll be Buggified -+-
Le Sat, 12 Mar 2005 12:55:04 +0000, Xavier Roche a écrit :
L'important c'est que la ressource qui réceptionne ce numéro soit en
https (càd probablement la page d'arrivée, celle indiquée dans le <form
action="..">) . Que la page initiale soit en HTTP n'a que peu
d'importance. C'est le cas ici, si je ne me trompe.
Effectivement, c'est aussi ce que j'avais répondu benoîtement il y a
quelques temps à une question du même genre. Mais le fait est que si la
page du formulaire n'est pas en HTTPS, qu'est-ce qui t'assure que la cible
du formulaire est bien la bonne tant que tu n'auras pas regardé le code
source de la page ? Ben en fait pas grand chose. C'est que Alain et
Jacques me faisait très justement remarquer dans ces deux messages :
On peut en effet tout à fait imaginer un faux site de base avec un
formulaire qui pointera sur un faux site HTTPS avec un certificat tout à
fait cohérent avec le site en question. Si c'est bien fait, tu n'y verras
pas grand chose.
--
Si maintenant on introduit le concept de normalité des bugs, où va
l'informatique ?
Chez Microsoft ? Ah oui, pas faux ça.
-+- GG in Guide du Macounet Pervers : R i F, you'll be Buggified -+-
Le Sat, 12 Mar 2005 12:55:04 +0000, Xavier Roche a écrit :
L'important c'est que la ressource qui réceptionne ce numéro soit en https (càd probablement la page d'arrivée, celle indiquée dans le <form action="..">) . Que la page initiale soit en HTTP n'a que peu d'importance. C'est le cas ici, si je ne me trompe.
Effectivement, c'est aussi ce que j'avais répondu benoîtement il y a quelques temps à une question du même genre. Mais le fait est que si la page du formulaire n'est pas en HTTPS, qu'est-ce qui t'assure que la cible du formulaire est bien la bonne tant que tu n'auras pas regardé le code source de la page ? Ben en fait pas grand chose. C'est que Alain et Jacques me faisait très justement remarquer dans ces deux messages :
On peut en effet tout à fait imaginer un faux site de base avec un formulaire qui pointera sur un faux site HTTPS avec un certificat tout à fait cohérent avec le site en question. Si c'est bien fait, tu n'y verras pas grand chose.
-- Si maintenant on introduit le concept de normalité des bugs, où va l'informatique ? Chez Microsoft ? Ah oui, pas faux ça. -+- GG in Guide du Macounet Pervers : R i F, you'll be Buggified -+-
Xavier Roche
Cedric Blancher wrote:
Effectivement, c'est aussi ce que j'avais répondu benoîtement il y a quelques temps à une question du même genre. Mais le fait est que si la page du formulaire n'est pas en HTTPS, qu'est-ce qui t'assure que la cible du formulaire est bien la bonne tant que tu n'auras pas regardé le code source de la page ? Ben en fait pas grand chose.
C'est à double sens: le page initiale peut être en https, et la page du formulaire en http! Selon le navigateur, un avertisement est généré ou pas (testé en local, mais avec un certificat de test: aucun avertisement avec un IE de base, avertissement avec Mozilla) Disons qu'avec une sécurité configurée correctement, un avertissement doit être affiché.
Cedric Blancher wrote:
Effectivement, c'est aussi ce que j'avais répondu benoîtement il y a
quelques temps à une question du même genre. Mais le fait est que si la
page du formulaire n'est pas en HTTPS, qu'est-ce qui t'assure que la cible
du formulaire est bien la bonne tant que tu n'auras pas regardé le code
source de la page ? Ben en fait pas grand chose.
C'est à double sens: le page initiale peut être en https, et la page du
formulaire en http! Selon le navigateur, un avertisement est généré ou
pas (testé en local, mais avec un certificat de test: aucun avertisement
avec un IE de base, avertissement avec Mozilla)
Disons qu'avec une sécurité configurée correctement, un avertissement
doit être affiché.
Effectivement, c'est aussi ce que j'avais répondu benoîtement il y a quelques temps à une question du même genre. Mais le fait est que si la page du formulaire n'est pas en HTTPS, qu'est-ce qui t'assure que la cible du formulaire est bien la bonne tant que tu n'auras pas regardé le code source de la page ? Ben en fait pas grand chose.
C'est à double sens: le page initiale peut être en https, et la page du formulaire en http! Selon le navigateur, un avertisement est généré ou pas (testé en local, mais avec un certificat de test: aucun avertisement avec un IE de base, avertissement avec Mozilla) Disons qu'avec une sécurité configurée correctement, un avertissement doit être affiché.
Vincent Bernat
OoO Peu avant le début de l'après-midi du samedi 12 mars 2005, vers 13:32, (mrique) disait:
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas sur un layer https : qu'en pensez vous, puis je me risquer à utiliser cette interface de paiement ? Celà vous parrait il normal de la part d'une grande entreprise du secteur telecom informatique ?
Tu peux demander la page en https. J'ai fait la remarque, on m'a répondu à côté de la plaque. -- /* * We used to try various strange things. Let's not. */ 2.2.16 /usr/src/linux/fs/buffer.c
OoO Peu avant le début de l'après-midi du samedi 12 mars 2005, vers
13:32, mrique@hotmail.com (mrique) disait:
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas
sur un layer https : qu'en pensez vous, puis je me risquer à utiliser
cette interface de paiement ? Celà vous parrait il normal de la part
d'une grande entreprise du secteur telecom informatique ?
Tu peux demander la page en https. J'ai fait la remarque, on m'a
répondu à côté de la plaque.
--
/*
* We used to try various strange things. Let's not.
*/
2.2.16 /usr/src/linux/fs/buffer.c
OoO Peu avant le début de l'après-midi du samedi 12 mars 2005, vers 13:32, (mrique) disait:
J'ai été assez étonné que la page d'envoi du numéro de cb ne soit pas sur un layer https : qu'en pensez vous, puis je me risquer à utiliser cette interface de paiement ? Celà vous parrait il normal de la part d'une grande entreprise du secteur telecom informatique ?
Tu peux demander la page en https. J'ai fait la remarque, on m'a répondu à côté de la plaque. -- /* * We used to try various strange things. Let's not. */ 2.2.16 /usr/src/linux/fs/buffer.c
Cedric Blancher
Le Sat, 12 Mar 2005 13:28:18 +0000, Xavier Roche a écrit :
C'est à double sens: le page initiale peut être en https, et la page du formulaire en http!
Ne me fais pas dire ce que je n'ai pas écrit. Il est _évident_ que la cible du formulaire doit être en HTTPS, sinon, on s'en va et vite. Ce que je dis, c'est qu'avoir le formulaire en HTTP fait courir un risque.
Selon le navigateur, un avertisement est généré ou pas (testé en local, mais avec un certificat de test: aucun avertisement avec un IE de base, avertissement avec Mozilla) Disons qu'avec une sécurité configurée correctement, un avertissement doit être affiché.
Oui.
-- BOFH excuse #58:
high pressure system failure
Le Sat, 12 Mar 2005 13:28:18 +0000, Xavier Roche a écrit :
C'est à double sens: le page initiale peut être en https, et la page du
formulaire en http!
Ne me fais pas dire ce que je n'ai pas écrit. Il est _évident_ que la
cible du formulaire doit être en HTTPS, sinon, on s'en va et vite. Ce que
je dis, c'est qu'avoir le formulaire en HTTP fait courir un risque.
Selon le navigateur, un avertisement est généré ou pas (testé en
local, mais avec un certificat de test: aucun avertisement avec un IE de
base, avertissement avec Mozilla) Disons qu'avec une sécurité
configurée correctement, un avertissement doit être affiché.
Le Sat, 12 Mar 2005 13:28:18 +0000, Xavier Roche a écrit :
C'est à double sens: le page initiale peut être en https, et la page du formulaire en http!
Ne me fais pas dire ce que je n'ai pas écrit. Il est _évident_ que la cible du formulaire doit être en HTTPS, sinon, on s'en va et vite. Ce que je dis, c'est qu'avoir le formulaire en HTTP fait courir un risque.
Selon le navigateur, un avertisement est généré ou pas (testé en local, mais avec un certificat de test: aucun avertisement avec un IE de base, avertissement avec Mozilla) Disons qu'avec une sécurité configurée correctement, un avertissement doit être affiché.
Oui.
-- BOFH excuse #58:
high pressure system failure
Dominique Blas
[...]
On peut en effet tout à fait imaginer un faux site de base avec un formulaire qui pointera sur un faux site HTTPS avec un certificat tout à fait cohérent avec le site en question. Si c'est bien fait, tu n'y verras pas grand chose.
Ayant réalisé des développements dans ce domaine (encaissement sur site Web associé à un site marchand) à la fois pour des raisons de communication, de visibilité et de simplicité, l'accès au site d'encaissement est réalisé, en HTTPS bien entendu mais surtout via une fenêtre fille et JAMAIS via un cadre.
Pour les cas plus critiques la page du site d'encaissement se substitue à la page en cours du site marchand (sécurisée ou pas cette dernière). On peut aller encore plus loin avec un certif client.
En ce qui concerne la fenêtre-fille le fait qu'il n'y ait pas d'URL affiché ne change rien à l'affaire. La plupart des sites d'encaissement n'ont rien à voir avec le site marchand et peu à voir avec la banque qui, accessoirement, les héberge (Atos par exemple et un autre de mes cas était celui d'un intermédiaire du GIE inconnu du grand public). On supprime la fenêtre -fille lorsque la population concernée est un peu plus soupçonneuse mais fondamentalement, lrosque l'utilisateur est sur IE, on truande aussi bien une << grande >> fenêtre qu'une fille fenêtre URL ou pas.
Pour l'instant, à part le certif client réservé tout de même à une population restreinte je n'ai pas de solution satisfaisante. On entend parler de signature de site mais bon, c'est comme pour la protection de CD, il y a toujours un brevet qui trâine derrière. Donc ...
Pour répondre dans le sujet initial : c'est avant tout un pb de communication, oui !
Car fondamentalement la chance que la signature du porteur soit interceptée est bien faible et quant bien même, le porteur est bien protégé en France : n'ayant pas saisi de code secret il peut demander le remboursement. Toutefois, le saut technologique pour passer du HTTP au HTTPS étant insignifiant côté fournisseur de services autant le réclamer et refouler tous ceux qui ne proposent pas HTTPS. Oui.
Par ailleurs quel pirate se ferait c.... à intercepter des numéros : il est bien plus rentable de pirater le serveur qui, de toute manière, ne DOIT, en aucun cas stocker ce genre d'information mais que voulez-vous ...
Il y a pire : ceux qui stockent carrément le numéro de carte, sa date d'expiration et le CVV soi-disant pour simplifier la vie de l'internaute. Je ne cite donc pas la FNAC sur son site fnac.com. C'est une procédure à laquelle on n'est pas obligé de souscrire (encore heureux) mais le fait qu'il existe me choque.
A l'heure d'aujourd'hui ce genre de politique me sidère. J'ignore qui les conseille mais il ferait mieux de prendre sa retraite.
db
--
Courriel : usenet blas net
[...]
On peut en effet tout à fait imaginer un faux site de base avec un
formulaire qui pointera sur un faux site HTTPS avec un certificat tout à
fait cohérent avec le site en question. Si c'est bien fait, tu n'y verras
pas grand chose.
Ayant réalisé des développements dans ce domaine (encaissement sur site
Web associé à un site marchand) à la fois pour des raisons de
communication, de visibilité et de simplicité, l'accès au site
d'encaissement est réalisé, en HTTPS bien entendu mais surtout via une
fenêtre fille et JAMAIS via un cadre.
Pour les cas plus critiques la page du site d'encaissement se substitue
à la page en cours du site marchand (sécurisée ou pas cette dernière).
On peut aller encore plus loin avec un certif client.
En ce qui concerne la fenêtre-fille le fait qu'il n'y ait pas d'URL
affiché ne change rien à l'affaire. La plupart des sites d'encaissement
n'ont rien à voir avec le site marchand et peu à voir avec la banque
qui, accessoirement, les héberge (Atos par exemple et un autre de mes
cas était celui d'un intermédiaire du GIE inconnu du grand public).
On supprime la fenêtre -fille lorsque la population concernée est un peu
plus soupçonneuse mais fondamentalement, lrosque l'utilisateur est sur
IE, on truande aussi bien une << grande >> fenêtre qu'une fille fenêtre
URL ou pas.
Pour l'instant, à part le certif client réservé tout de même à une
population restreinte je n'ai pas de solution satisfaisante.
On entend parler de signature de site mais bon, c'est comme pour la
protection de CD, il y a toujours un brevet qui trâine derrière. Donc ...
Pour répondre dans le sujet initial : c'est avant tout un pb de
communication, oui !
Car fondamentalement la chance que la signature du porteur soit
interceptée est bien faible et quant bien même, le porteur est bien
protégé en France : n'ayant pas saisi de code secret il peut demander le
remboursement.
Toutefois, le saut technologique pour passer du HTTP au HTTPS étant
insignifiant côté fournisseur de services autant le réclamer et refouler
tous ceux qui ne proposent pas HTTPS. Oui.
Par ailleurs quel pirate se ferait c.... à intercepter
des numéros : il est bien plus rentable de pirater le serveur qui, de
toute manière, ne DOIT, en aucun cas stocker ce genre d'information mais
que voulez-vous ...
Il y a pire : ceux qui stockent carrément le numéro de carte, sa date
d'expiration et le CVV soi-disant pour simplifier la vie de
l'internaute. Je ne cite donc pas la FNAC sur son site fnac.com.
C'est une procédure à laquelle on n'est pas obligé de souscrire (encore
heureux) mais le fait qu'il existe me choque.
A l'heure d'aujourd'hui ce genre de politique me sidère. J'ignore qui
les conseille mais il ferait mieux de prendre sa retraite.
On peut en effet tout à fait imaginer un faux site de base avec un formulaire qui pointera sur un faux site HTTPS avec un certificat tout à fait cohérent avec le site en question. Si c'est bien fait, tu n'y verras pas grand chose.
Ayant réalisé des développements dans ce domaine (encaissement sur site Web associé à un site marchand) à la fois pour des raisons de communication, de visibilité et de simplicité, l'accès au site d'encaissement est réalisé, en HTTPS bien entendu mais surtout via une fenêtre fille et JAMAIS via un cadre.
Pour les cas plus critiques la page du site d'encaissement se substitue à la page en cours du site marchand (sécurisée ou pas cette dernière). On peut aller encore plus loin avec un certif client.
En ce qui concerne la fenêtre-fille le fait qu'il n'y ait pas d'URL affiché ne change rien à l'affaire. La plupart des sites d'encaissement n'ont rien à voir avec le site marchand et peu à voir avec la banque qui, accessoirement, les héberge (Atos par exemple et un autre de mes cas était celui d'un intermédiaire du GIE inconnu du grand public). On supprime la fenêtre -fille lorsque la population concernée est un peu plus soupçonneuse mais fondamentalement, lrosque l'utilisateur est sur IE, on truande aussi bien une << grande >> fenêtre qu'une fille fenêtre URL ou pas.
Pour l'instant, à part le certif client réservé tout de même à une population restreinte je n'ai pas de solution satisfaisante. On entend parler de signature de site mais bon, c'est comme pour la protection de CD, il y a toujours un brevet qui trâine derrière. Donc ...
Pour répondre dans le sujet initial : c'est avant tout un pb de communication, oui !
Car fondamentalement la chance que la signature du porteur soit interceptée est bien faible et quant bien même, le porteur est bien protégé en France : n'ayant pas saisi de code secret il peut demander le remboursement. Toutefois, le saut technologique pour passer du HTTP au HTTPS étant insignifiant côté fournisseur de services autant le réclamer et refouler tous ceux qui ne proposent pas HTTPS. Oui.
Par ailleurs quel pirate se ferait c.... à intercepter des numéros : il est bien plus rentable de pirater le serveur qui, de toute manière, ne DOIT, en aucun cas stocker ce genre d'information mais que voulez-vous ...
Il y a pire : ceux qui stockent carrément le numéro de carte, sa date d'expiration et le CVV soi-disant pour simplifier la vie de l'internaute. Je ne cite donc pas la FNAC sur son site fnac.com. C'est une procédure à laquelle on n'est pas obligé de souscrire (encore heureux) mais le fait qu'il existe me choque.
A l'heure d'aujourd'hui ce genre de politique me sidère. J'ignore qui les conseille mais il ferait mieux de prendre sa retraite.
db
--
Courriel : usenet blas net
Fabien LE LEZ
On 16 Mar 2005 02:04:23 GMT, Dominique Blas :
Il y a pire : ceux qui stockent carrément le numéro de carte, sa date d'expiration et le CVV soi-disant pour simplifier la vie de l'internaute. Je ne cite donc pas la FNAC sur son site fnac.com.
Amazon fait pareil (et pourtant eux ont une certaine réputation de sérieux).
-- ;-)
On 16 Mar 2005 02:04:23 GMT, Dominique Blas <db@internet.invalid>:
Il y a pire : ceux qui stockent carrément le numéro de carte, sa date
d'expiration et le CVV soi-disant pour simplifier la vie de
l'internaute. Je ne cite donc pas la FNAC sur son site fnac.com.
Amazon fait pareil (et pourtant eux ont une certaine réputation de
sérieux).
Il y a pire : ceux qui stockent carrément le numéro de carte, sa date d'expiration et le CVV soi-disant pour simplifier la vie de l'internaute. Je ne cite donc pas la FNAC sur son site fnac.com.
Amazon fait pareil (et pourtant eux ont une certaine réputation de sérieux).
