Connaissez-vous des iniatives de banques ou autre organisme utilisant le
SMS pour véhiculer un code de session, en complément des habituels login
et mot de passe ?
Ainsi on ajoute au "quelquechose que je suis (login) et que je connais
(le mot de passe)", le "quelquechose que je possède".
Outre le fait que cela n'est pas une solution universelle car tout le
monde ne possède de téléphone, pensez-vous que cela puisse être un moyen
facile et relativement sûr d'éviter le phishing ?
Mais peut-être que le phishing est relativement anecdotique en France et
que les banques préfèrent rembourser les victimes plutôt que de mettre
en place des systèmes permettant d'éviter ce type de fraude.
A ma banque (fortis, en belgique) pour avoir un accès à mon compte en ligne, j'ai un digipass (taille d'une toute petite calculatrice de poche). on l'allume, on rentre son code pin et on tape le numéro affiché (à 6 chiffres) dans la case "password" du site web.
Une bonne méthode contre le phishing : le site de la banque affiche un code (calculé d'une manière similaire à ce code à six chiffres). Tu tapes ce code sur ton digipass ; celui-ci vérifie que c'est le bon code, et seulement alors te donne le code à taper.
En gros, le digipass te permet d'identifier la banque _et_ permet à la banque de t'indentifier.
On 12 Oct 2005 23:01:09 GMT, Aris <aris@0xbadc0de.be>:
A ma banque (fortis, en belgique) pour avoir un accès à mon compte en ligne,
j'ai un digipass (taille d'une toute petite calculatrice de poche).
on l'allume, on rentre son code pin et on tape le numéro affiché (à 6
chiffres) dans la case "password" du site web.
Une bonne méthode contre le phishing : le site de la banque affiche un
code (calculé d'une manière similaire à ce code à six chiffres). Tu
tapes ce code sur ton digipass ; celui-ci vérifie que c'est le bon
code, et seulement alors te donne le code à taper.
En gros, le digipass te permet d'identifier la banque _et_ permet à la
banque de t'indentifier.
A ma banque (fortis, en belgique) pour avoir un accès à mon compte en ligne, j'ai un digipass (taille d'une toute petite calculatrice de poche). on l'allume, on rentre son code pin et on tape le numéro affiché (à 6 chiffres) dans la case "password" du site web.
Une bonne méthode contre le phishing : le site de la banque affiche un code (calculé d'une manière similaire à ce code à six chiffres). Tu tapes ce code sur ton digipass ; celui-ci vérifie que c'est le bon code, et seulement alors te donne le code à taper.
En gros, le digipass te permet d'identifier la banque _et_ permet à la banque de t'indentifier.
Dominique Blas
[...]
Cette solution ne m'aurait pas plu parce qu'elle est trop intrusive : 1- je peux pas l'utiliser partout ou je veux (université par ex) Ou cybercafé avec fil. D'un autre côté ce n'est pas prudent de laisser
sa CB dans un lecteur et dans un endroit public. Gérer ses comptes réclame un minimum de précaution.
2- comme d'habitude, seuls les esclaves sous windows auront droit à utiliser le net banking. Hum, pas forcément. Enfin, là encore c'est une question de banque. A
l'époque du paiement en ligne, certaines ont développé des modules de certification pour la plate-forme Linux (Crédit Agricole par exemple). Il est vrai qu'il s'agissait là de serveurs et non de poste de travail. De toute manière il faut un module résident dialoguant et avec le lecteur via PCSC, et avec le service en ligne (via ce qu'on veut, HTTPS étant le plus simple).
Ce module résident est assez facile à écrire avec MUSCLE (l'implémentation PCSC sous Linux) mais il faut le faire, effectivement.
Mais regardons les choses en face, les banconautes sont certainement à plus de 95% équipés d'une plate-forme windows. Cela relativise bien des choses. Pour une entreprise toucher 95% de sa clientèle avec un produit c'est formidable !
db
--
Courriel : usenet blas net
[...]
Cette solution ne m'aurait pas plu parce qu'elle est trop intrusive :
1- je peux pas l'utiliser partout ou je veux (université par ex)
Ou cybercafé avec fil. D'un autre côté ce n'est pas prudent de laisser
sa CB dans un lecteur et dans un endroit public. Gérer ses comptes
réclame un minimum de précaution.
2- comme d'habitude, seuls les esclaves sous windows auront droit à utiliser
le net banking.
Hum, pas forcément. Enfin, là encore c'est une question de banque. A
l'époque du paiement en ligne, certaines ont développé des modules de
certification pour la plate-forme Linux (Crédit Agricole par exemple).
Il est vrai qu'il s'agissait là de serveurs et non de poste de travail.
De toute manière il faut un module résident dialoguant
et avec le lecteur via PCSC,
et avec le service en ligne (via ce qu'on veut, HTTPS étant le
plus simple).
Ce module résident est assez facile à écrire avec MUSCLE
(l'implémentation PCSC sous Linux) mais il faut le faire, effectivement.
Mais regardons les choses en face, les banconautes sont certainement à
plus de 95% équipés d'une plate-forme windows. Cela relativise bien des
choses. Pour une entreprise toucher 95% de sa clientèle avec un produit
c'est formidable !
Cette solution ne m'aurait pas plu parce qu'elle est trop intrusive : 1- je peux pas l'utiliser partout ou je veux (université par ex) Ou cybercafé avec fil. D'un autre côté ce n'est pas prudent de laisser
sa CB dans un lecteur et dans un endroit public. Gérer ses comptes réclame un minimum de précaution.
2- comme d'habitude, seuls les esclaves sous windows auront droit à utiliser le net banking. Hum, pas forcément. Enfin, là encore c'est une question de banque. A
l'époque du paiement en ligne, certaines ont développé des modules de certification pour la plate-forme Linux (Crédit Agricole par exemple). Il est vrai qu'il s'agissait là de serveurs et non de poste de travail. De toute manière il faut un module résident dialoguant et avec le lecteur via PCSC, et avec le service en ligne (via ce qu'on veut, HTTPS étant le plus simple).
Ce module résident est assez facile à écrire avec MUSCLE (l'implémentation PCSC sous Linux) mais il faut le faire, effectivement.
Mais regardons les choses en face, les banconautes sont certainement à plus de 95% équipés d'une plate-forme windows. Cela relativise bien des choses. Pour une entreprise toucher 95% de sa clientèle avec un produit c'est formidable !
db
--
Courriel : usenet blas net
Dominique Blas
Dominique Blas wrote:
le login ne fait pas partie de l'authentification. Il s'agit d'une identification, c'est tout. Le << être >> existe en authentification il s'agit des procédés caractérisant l'individu : biométrie, ADN, etc.
Ce que je ne saisi pas dans ce << être >> c'est qu'il couvre à la fois le << possède >> et << être >> tel que je l'entendais. Mais je dois mal entendre :) Le << être >> considère ce que l'on est (sic) c'est à dire ce qui est
constitutif de l'individu. Lorsqu'on parle de ce qu'on possède il s'agit d'un objet extérieur à l'être humain : badge, CB, clé USB, etc. Enfin, ce que l'on sait fait appel à la mémoire.
Effectivement celui qui est muet, aveugle, sourd, amputé et qui plus est alzamehrien ... pas de chance, il ne rentre pas chez lui :-(
[...]
Dans mon esprit, je possède le téléphone portable. Le SMS est une sorte de OTP, un secret partagé via un autre canal. Oui on peut le voir comme cela du point de vue de l'utilisateur. Je n'ai
pas écrit qu'il s'agissait d'une mauvaise méthode. Bien au contraire.
Si on intercepte mon mot de passe et mon login, il doit manquer à l'attaquant le troisième paramètre (envoyé par SMS). Mais plus j'y pense plus je me dis que ça cloche quelquepart :)
Pourquoi donc ?
Le seul inconvénient que l'on pourrait reprocher à ce système c'est sa << non-fermeture >> ce qui impacte certes sa disponibilité et donc la sécurité quelque part.
On introduit un circuit étranger dans le système d'authentification : le canal de données GSM. Du coup si ce canal est indiponible (à l'étranger par exemple ou hors zone de réception) : pas d'accès.
A contrario ce canal étranger a du bon dans la mesure où c'est un élement qui complique énormément le travail d'un pirate. Toutefois il le sera un peu moins lorsqu'on utilisera systématiquement le mobile pour accéder à Internet et en particulier pour accéder au portail. En effet, les tentatives d'injection de chevaux de Troie sur les mobiles seront alors aussi nombreuses qu'aujourd'hui sur les stations et, les SMS étant stockés dans la SIM ... on en déduit le reste.
En fait, si l'usge du mobile est une excellente chose aujourd'hui soit en tant que canal << hors-bande >> supplémentaire pour l'authentification soit en tant que canal privilégié son usage systématique lui fera perdre des points quant à la sécurité des transactions. Les seuls dispositifs inaltérables à moyen et long terme restent encore la carte bancaire et la calculette car ce sont et ce seront des environnmeents fermés.
Peut-être suffit-il d'équiper tout simplement la CB d'une calculette et d'enrichir son programme interne (les cartes à 64 ko sont arrivées sur le marché l'année dernière) afin quelle dialogue seule de manière sécurisée quel que soit le support (dans lequel on ne pourra raisonnablement pas avoir confiance en fonction du porteur).
[...]
Ça me fait penser que même dans un système comme celui présenté par Aris avec un token, même si le mot de passe ne dure que le temps de la session rien n'empêche l'attaquant de récupérer ce mot de passe et d'ouvrir la session à la place de l'utilisateur, puis de renvoyer une page d'erreur.
C'est un des soucis du token mis en évidence dans Kerberos du reste (entre autres choses, dans Kerberos il n'était pas confidentialisé) : son utilisation à la place du porteur légitime. Dans le principe les systèmes à jeton s'utilise en environnement fermé.
Le gros problème pour l'attaquant est qu'il lui faut maintenir la session ouverte le temps de l'exploitation, puisque sinon il perd ce mot de passe. Mais ça ne semble pas insurmontable. Effectivement, c'est somplexe aujourd'hui mais si ce genre de système
est appelé à se développer les phishers suivront.
[...]
C'est plus couteux qu'un système basé sur le portable et surtout moins sexy :) Sexy on s'en fout : si c'est sécurisé.
Ceci il parait que les prestations bancaires ont augmentées dans des proportions largement supérieures à l'augmentation moyenne du coup de la vie.
Mouais, beaucoup de choses ont augmenté au-delà du << coût de la vie >> entre la période franc et la période euro : les artciles de tous les jours (+20% entre juillet 2001 et juillet 2003), les loyers et logements parisiens (au moins 50% en 4 ans), le p'tit noir, la baguette, les services bancaires et je dois bien en oublier (le pétrole of course). C'est à se demander si l'indice INSEE, si << secret >>, ne se fout pas de la gueule du monde !
db
--
Courriel : usenet blas net
Dominique Blas wrote:
le login ne fait pas partie de l'authentification. Il s'agit d'une
identification, c'est tout.
Le << être >> existe en authentification il s'agit des procédés
caractérisant l'individu : biométrie, ADN, etc.
Ce que je ne saisi pas dans ce << être >> c'est qu'il couvre à la fois
le << possède >> et << être >> tel que je l'entendais. Mais je dois mal
entendre :)
Le << être >> considère ce que l'on est (sic) c'est à dire ce qui est
constitutif de l'individu.
Lorsqu'on parle de ce qu'on possède il s'agit d'un objet extérieur à
l'être humain : badge, CB, clé USB, etc.
Enfin, ce que l'on sait fait appel à la mémoire.
Effectivement celui qui est muet, aveugle, sourd, amputé et qui plus est
alzamehrien ...
pas de chance, il ne rentre pas chez lui :-(
[...]
Dans mon esprit, je possède le téléphone portable.
Le SMS est une sorte de OTP, un secret partagé via un autre canal.
Oui on peut le voir comme cela du point de vue de l'utilisateur. Je n'ai
pas écrit qu'il s'agissait d'une mauvaise méthode. Bien au contraire.
Si on intercepte mon mot de passe et mon login, il doit manquer à
l'attaquant le troisième paramètre (envoyé par SMS).
Mais plus j'y pense plus je me dis que ça cloche quelquepart :)
Pourquoi donc ?
Le seul inconvénient que l'on pourrait reprocher à ce système c'est sa
<< non-fermeture >> ce qui impacte certes sa disponibilité et donc la
sécurité quelque part.
On introduit un circuit étranger dans le système d'authentification : le
canal de données GSM. Du coup si ce canal est indiponible (à l'étranger
par exemple ou hors zone de réception) : pas d'accès.
A contrario ce canal étranger a du bon dans la mesure où c'est un
élement qui complique énormément le travail d'un pirate.
Toutefois il le sera un peu moins lorsqu'on utilisera systématiquement
le mobile pour accéder à Internet et en particulier pour accéder au
portail.
En effet, les tentatives d'injection de chevaux de Troie sur les mobiles
seront alors aussi nombreuses qu'aujourd'hui sur les stations et, les
SMS étant stockés dans la SIM ... on en déduit le reste.
En fait, si l'usge du mobile est une excellente chose aujourd'hui soit
en tant que canal << hors-bande >> supplémentaire pour
l'authentification soit en tant que canal privilégié son usage
systématique lui fera perdre des points quant à la sécurité des
transactions.
Les seuls dispositifs inaltérables à moyen et long terme restent encore
la carte bancaire et la calculette car ce sont et ce seront des
environnmeents fermés.
Peut-être suffit-il d'équiper tout simplement la CB d'une calculette et
d'enrichir son programme interne (les cartes à 64 ko sont arrivées sur
le marché l'année dernière) afin quelle dialogue seule de manière
sécurisée quel que soit le support (dans lequel on ne pourra
raisonnablement pas avoir confiance en fonction du porteur).
[...]
Ça me fait penser que même dans un système comme celui présenté par Aris
avec un token, même si le mot de passe ne dure que le temps de la
session rien n'empêche l'attaquant de récupérer ce mot de passe et
d'ouvrir la session à la place de l'utilisateur, puis de renvoyer une
page d'erreur.
C'est un des soucis du token mis en évidence dans Kerberos du reste
(entre autres choses, dans Kerberos il n'était pas confidentialisé) :
son utilisation à la place du porteur légitime.
Dans le principe les systèmes à jeton s'utilise en environnement fermé.
Le gros problème pour l'attaquant est qu'il lui faut
maintenir la session ouverte le temps de l'exploitation, puisque sinon
il perd ce mot de passe. Mais ça ne semble pas insurmontable.
Effectivement, c'est somplexe aujourd'hui mais si ce genre de système
est appelé à se développer les phishers suivront.
[...]
C'est plus couteux qu'un système basé sur le portable et surtout moins
sexy :)
Sexy on s'en fout : si c'est sécurisé.
Ceci il parait que les prestations bancaires ont augmentées dans des
proportions largement supérieures à l'augmentation moyenne du coup de la
vie.
Mouais, beaucoup de choses ont augmenté au-delà du << coût de la vie >>
entre la période franc et la période euro : les artciles de tous les
jours (+20% entre juillet 2001 et juillet 2003), les loyers et logements
parisiens (au moins 50% en 4 ans), le p'tit noir, la baguette, les
services bancaires et je dois bien en oublier (le pétrole of course).
C'est à se demander si l'indice INSEE, si << secret >>, ne se fout pas
de la gueule du monde !
le login ne fait pas partie de l'authentification. Il s'agit d'une identification, c'est tout. Le << être >> existe en authentification il s'agit des procédés caractérisant l'individu : biométrie, ADN, etc.
Ce que je ne saisi pas dans ce << être >> c'est qu'il couvre à la fois le << possède >> et << être >> tel que je l'entendais. Mais je dois mal entendre :) Le << être >> considère ce que l'on est (sic) c'est à dire ce qui est
constitutif de l'individu. Lorsqu'on parle de ce qu'on possède il s'agit d'un objet extérieur à l'être humain : badge, CB, clé USB, etc. Enfin, ce que l'on sait fait appel à la mémoire.
Effectivement celui qui est muet, aveugle, sourd, amputé et qui plus est alzamehrien ... pas de chance, il ne rentre pas chez lui :-(
[...]
Dans mon esprit, je possède le téléphone portable. Le SMS est une sorte de OTP, un secret partagé via un autre canal. Oui on peut le voir comme cela du point de vue de l'utilisateur. Je n'ai
pas écrit qu'il s'agissait d'une mauvaise méthode. Bien au contraire.
Si on intercepte mon mot de passe et mon login, il doit manquer à l'attaquant le troisième paramètre (envoyé par SMS). Mais plus j'y pense plus je me dis que ça cloche quelquepart :)
Pourquoi donc ?
Le seul inconvénient que l'on pourrait reprocher à ce système c'est sa << non-fermeture >> ce qui impacte certes sa disponibilité et donc la sécurité quelque part.
On introduit un circuit étranger dans le système d'authentification : le canal de données GSM. Du coup si ce canal est indiponible (à l'étranger par exemple ou hors zone de réception) : pas d'accès.
A contrario ce canal étranger a du bon dans la mesure où c'est un élement qui complique énormément le travail d'un pirate. Toutefois il le sera un peu moins lorsqu'on utilisera systématiquement le mobile pour accéder à Internet et en particulier pour accéder au portail. En effet, les tentatives d'injection de chevaux de Troie sur les mobiles seront alors aussi nombreuses qu'aujourd'hui sur les stations et, les SMS étant stockés dans la SIM ... on en déduit le reste.
En fait, si l'usge du mobile est une excellente chose aujourd'hui soit en tant que canal << hors-bande >> supplémentaire pour l'authentification soit en tant que canal privilégié son usage systématique lui fera perdre des points quant à la sécurité des transactions. Les seuls dispositifs inaltérables à moyen et long terme restent encore la carte bancaire et la calculette car ce sont et ce seront des environnmeents fermés.
Peut-être suffit-il d'équiper tout simplement la CB d'une calculette et d'enrichir son programme interne (les cartes à 64 ko sont arrivées sur le marché l'année dernière) afin quelle dialogue seule de manière sécurisée quel que soit le support (dans lequel on ne pourra raisonnablement pas avoir confiance en fonction du porteur).
[...]
Ça me fait penser que même dans un système comme celui présenté par Aris avec un token, même si le mot de passe ne dure que le temps de la session rien n'empêche l'attaquant de récupérer ce mot de passe et d'ouvrir la session à la place de l'utilisateur, puis de renvoyer une page d'erreur.
C'est un des soucis du token mis en évidence dans Kerberos du reste (entre autres choses, dans Kerberos il n'était pas confidentialisé) : son utilisation à la place du porteur légitime. Dans le principe les systèmes à jeton s'utilise en environnement fermé.
Le gros problème pour l'attaquant est qu'il lui faut maintenir la session ouverte le temps de l'exploitation, puisque sinon il perd ce mot de passe. Mais ça ne semble pas insurmontable. Effectivement, c'est somplexe aujourd'hui mais si ce genre de système
est appelé à se développer les phishers suivront.
[...]
C'est plus couteux qu'un système basé sur le portable et surtout moins sexy :) Sexy on s'en fout : si c'est sécurisé.
Ceci il parait que les prestations bancaires ont augmentées dans des proportions largement supérieures à l'augmentation moyenne du coup de la vie.
Mouais, beaucoup de choses ont augmenté au-delà du << coût de la vie >> entre la période franc et la période euro : les artciles de tous les jours (+20% entre juillet 2001 et juillet 2003), les loyers et logements parisiens (au moins 50% en 4 ans), le p'tit noir, la baguette, les services bancaires et je dois bien en oublier (le pétrole of course). C'est à se demander si l'indice INSEE, si << secret >>, ne se fout pas de la gueule du monde !
db
--
Courriel : usenet blas net
Mehdi BENKIR
Erwan David wrote:
Le phishing vient urtout du fait que la banque ne s'authentifie pas auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de vérification, SSLv3 ne fournit-il pas ce genre de services ?
-- Ce message est sur votre écran Ce message est vrai
Erwan David wrote:
Le phishing vient urtout du fait que la banque ne s'authentifie pas
auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de
vérification, SSLv3 ne fournit-il pas ce genre de services ?
--
Ce message est sur votre écran
Ce message est vrai
Le phishing vient urtout du fait que la banque ne s'authentifie pas auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de vérification, SSLv3 ne fournit-il pas ce genre de services ?
-- Ce message est sur votre écran Ce message est vrai
Erwan David
Mehdi BENKIR écrivait :
Erwan David wrote:
Le phishing vient urtout du fait que la banque ne s'authentifie pas auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de vérification, SSLv3 ne fournit-il pas ce genre de services ?
Mais non : n'importe qui peut prendre un certificat signé par un CA automatiquement dans les browsers et jouer avec les redirections... Ceux qui ne vérifient pas qu'ils sont bien sur le sitre de la banque ne vont pas vérifier que le certificat présenté est celui de la banque.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Mehdi BENKIR <medhib142@hotmail.com> écrivait :
Erwan David wrote:
Le phishing vient urtout du fait que la banque ne s'authentifie pas
auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de
vérification, SSLv3 ne fournit-il pas ce genre de services ?
Mais non : n'importe qui peut prendre un certificat signé par un CA
automatiquement dans les browsers et jouer avec les
redirections... Ceux qui ne vérifient pas qu'ils sont bien sur le
sitre de la banque ne vont pas vérifier que le certificat présenté est
celui de la banque.
--
Si vous embauchez, voici mon CV
http://www.rail.eu.org/cv/cv.pdf
Le phishing vient urtout du fait que la banque ne s'authentifie pas auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de vérification, SSLv3 ne fournit-il pas ce genre de services ?
Mais non : n'importe qui peut prendre un certificat signé par un CA automatiquement dans les browsers et jouer avec les redirections... Ceux qui ne vérifient pas qu'ils sont bien sur le sitre de la banque ne vont pas vérifier que le certificat présenté est celui de la banque.
-- Si vous embauchez, voici mon CV http://www.rail.eu.org/cv/cv.pdf
Mehdi BENKIR
Erwan David wrote:
Mehdi BENKIR écrivait :
Erwan David wrote:
Le phishing vient urtout du fait que la banque ne s'authentifie pas auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de vérification, SSLv3 ne fournit-il pas ce genre de services ?
Mais non : n'importe qui peut prendre un certificat signé par un CA automatiquement dans les browsers et jouer avec les redirections... Ceux qui ne vérifient pas qu'ils sont bien sur le sitre de la banque ne vont pas vérifier que le certificat présenté est celui de la banque.
Hmmmmmm : au risque de paraître pinailleur, les problèmes que vous évoquez relèvent plutôt des faiblesses notoires (et de l'affolante complexité) d'HTTP, du comportement par défaut des bouziciels libres (ou indissociables d'un processeur Intel tel qu'intégré par un grand intégrateur), ou éventuellement des pratiques des très rentables vendeurs en masse de certificats mais moins astreintes à quelque exigence de qualité de service que ce soit qu'un mandataire AFNIC. J'avoue encore rester perplexe à entendre des professionnels évoquer l'hypothèse de possibles relations de confiance dans ce contexte.
Le problème me semble donc plutôt être l'évidente incapacité du Web à proposer un possible contexte de relation de confiance que le procédé actuellement utilisé pour créer (à tort) cette confiance.
Erwan David wrote:
Mehdi BENKIR <medhib142@hotmail.com> écrivait :
Erwan David wrote:
Le phishing vient urtout du fait que la banque ne s'authentifie pas
auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de
vérification, SSLv3 ne fournit-il pas ce genre de services ?
Mais non : n'importe qui peut prendre un certificat signé par un CA
automatiquement dans les browsers et jouer avec les
redirections... Ceux qui ne vérifient pas qu'ils sont bien sur le
sitre de la banque ne vont pas vérifier que le certificat présenté est
celui de la banque.
Hmmmmmm : au risque de paraître pinailleur, les problèmes que vous
évoquez relèvent plutôt des faiblesses notoires (et de l'affolante
complexité) d'HTTP, du comportement par défaut des bouziciels libres (ou
indissociables d'un processeur Intel tel qu'intégré par un grand
intégrateur), ou éventuellement des pratiques des très rentables
vendeurs en masse de certificats mais moins astreintes à quelque
exigence de qualité de service que ce soit qu'un mandataire AFNIC.
J'avoue encore rester perplexe à entendre des professionnels évoquer
l'hypothèse de possibles relations de confiance dans ce contexte.
Le problème me semble donc plutôt être l'évidente incapacité du Web à
proposer un possible contexte de relation de confiance que le procédé
actuellement utilisé pour créer (à tort) cette confiance.
Le phishing vient urtout du fait que la banque ne s'authentifie pas auprès du client. C'est là le vrai problème.
Dans la limite de ce qu'on peut espérer d'un PC comme système de vérification, SSLv3 ne fournit-il pas ce genre de services ?
Mais non : n'importe qui peut prendre un certificat signé par un CA automatiquement dans les browsers et jouer avec les redirections... Ceux qui ne vérifient pas qu'ils sont bien sur le sitre de la banque ne vont pas vérifier que le certificat présenté est celui de la banque.
Hmmmmmm : au risque de paraître pinailleur, les problèmes que vous évoquez relèvent plutôt des faiblesses notoires (et de l'affolante complexité) d'HTTP, du comportement par défaut des bouziciels libres (ou indissociables d'un processeur Intel tel qu'intégré par un grand intégrateur), ou éventuellement des pratiques des très rentables vendeurs en masse de certificats mais moins astreintes à quelque exigence de qualité de service que ce soit qu'un mandataire AFNIC. J'avoue encore rester perplexe à entendre des professionnels évoquer l'hypothèse de possibles relations de confiance dans ce contexte.
Le problème me semble donc plutôt être l'évidente incapacité du Web à proposer un possible contexte de relation de confiance que le procédé actuellement utilisé pour créer (à tort) cette confiance.
Mehdi BENKIR
Thierry Herbelot wrote:
Je maintiens que les banques ne prendront en compte ce genre de problème de sécurité que quand elles seront financièrement responsables des détournements rendus possibles par l'absence de mesures de protection "raisonnables" (qui sont connues, correspondent à l'état de l'art et relativement bon marché)
Il est certain que si on me rendait responsable des accidents commis avec toutes les voitures ressemblant à la mienne, j'envisagerais de me débarasser de ma voiture. Si, de plus, je pouvais être certain que mes concurrents seraient traités selon les mêmes règles (responsabilité pécuniaire), je serais convaincu que moi-même et tous mes conccurents abandonnerions simultanément nos voitures, et tant pis pour l'industrie automobile.
Thierry Herbelot wrote:
Je maintiens que les banques ne prendront en compte ce genre de problème de
sécurité que quand elles seront financièrement responsables des
détournements rendus possibles par l'absence de mesures de protection
"raisonnables" (qui sont connues, correspondent à l'état de l'art et
relativement bon marché)
Il est certain que si on me rendait responsable des accidents commis
avec toutes les voitures ressemblant à la mienne, j'envisagerais de me
débarasser de ma voiture. Si, de plus, je pouvais être certain que mes
concurrents seraient traités selon les mêmes règles (responsabilité
pécuniaire), je serais convaincu que moi-même et tous mes conccurents
abandonnerions simultanément nos voitures, et tant pis pour l'industrie
automobile.
Je maintiens que les banques ne prendront en compte ce genre de problème de sécurité que quand elles seront financièrement responsables des détournements rendus possibles par l'absence de mesures de protection "raisonnables" (qui sont connues, correspondent à l'état de l'art et relativement bon marché)
Il est certain que si on me rendait responsable des accidents commis avec toutes les voitures ressemblant à la mienne, j'envisagerais de me débarasser de ma voiture. Si, de plus, je pouvais être certain que mes concurrents seraient traités selon les mêmes règles (responsabilité pécuniaire), je serais convaincu que moi-même et tous mes conccurents abandonnerions simultanément nos voitures, et tant pis pour l'industrie automobile.
Dominique Blas
[...]
Je maintiens que les banques ne prendront en compte ce genre de problème de sécurité que quand elles seront financièrement responsables des détournements rendus possibles par l'absence de mesures de protection "raisonnables" (qui sont connues, correspondent à l'état de l'art et relativement bon marché)
Etant donné le poids des banques, notamment en France, ce n'est pas demain la veille qu'une telle mesure sera prise. Ou du moins pas sous cette forme (beaucoup plus progressive). Et quand bien même elle serait votée, les banques fermeraient IMMEDIATEMENT tous les GAB, les DAB et, of course, les services en ligne. Soit un retour en arrière de 40 ans.
C'est effectivement bien idiot surtout dans la mesure om elles perdent des centaines de millions d'euros dans la fraude à la CB qu'elles ont elles-mêmes contribué à étendre.
Mais chut, voyons, un banquier ne peut pas être complice de vol et de détournement. C'est un non-sens.
db
--
Courriel : usenet blas net
[...]
Je maintiens que les banques ne prendront en compte ce genre de problème de
sécurité que quand elles seront financièrement responsables des
détournements rendus possibles par l'absence de mesures de protection
"raisonnables" (qui sont connues, correspondent à l'état de l'art et
relativement bon marché)
Etant donné le poids des banques, notamment en France, ce n'est pas
demain la veille qu'une telle mesure sera prise. Ou du moins pas sous
cette forme (beaucoup plus progressive).
Et quand bien même elle serait votée, les banques fermeraient
IMMEDIATEMENT tous les GAB, les DAB et, of course, les services en ligne.
Soit un retour en arrière de 40 ans.
C'est effectivement bien idiot surtout dans la mesure om elles perdent
des centaines de millions d'euros dans la fraude à la CB qu'elles ont
elles-mêmes contribué à étendre.
Mais chut, voyons, un banquier ne peut pas être complice de vol et de
détournement. C'est un non-sens.
Je maintiens que les banques ne prendront en compte ce genre de problème de sécurité que quand elles seront financièrement responsables des détournements rendus possibles par l'absence de mesures de protection "raisonnables" (qui sont connues, correspondent à l'état de l'art et relativement bon marché)
Etant donné le poids des banques, notamment en France, ce n'est pas demain la veille qu'une telle mesure sera prise. Ou du moins pas sous cette forme (beaucoup plus progressive). Et quand bien même elle serait votée, les banques fermeraient IMMEDIATEMENT tous les GAB, les DAB et, of course, les services en ligne. Soit un retour en arrière de 40 ans.
C'est effectivement bien idiot surtout dans la mesure om elles perdent des centaines de millions d'euros dans la fraude à la CB qu'elles ont elles-mêmes contribué à étendre.
Mais chut, voyons, un banquier ne peut pas être complice de vol et de détournement. C'est un non-sens.
db
--
Courriel : usenet blas net
Olivier Croquette
Manu wrote:
Connaissez-vous des iniatives de banques ou autre organisme utilisant le SMS pour véhiculer un code de session, en complément des habituels login et mot de passe ?
La Postbank en Allemagne vient d'introduire un concept original (à ma connaissance).
Jusqu'à maintenant, l'utilisateur avait une liste de codes à usage unique (TAN). Il se logue sur le site avec numéro de compte et PIN, et pour chaque transaction il donne un TAN (Transaction Number).
La nouveauté, c'est qu'il est maintenant possible de faire envoyer (après s'être identifié) un TAN par SMS. Ils appellent ça un mTAN (mobile TAN). Quand il est utilisé, un résumé de la transaction est aussi envoyé par SMS, ce qui a pour but de permettre à l'utilisation de détecter au plus tôt une fraude.
Par contre, ça ne répond pas vraiment au problème du phishing, plutôt à celui de faire des transactions quand on est itinérant.
Manu wrote:
Connaissez-vous des iniatives de banques ou autre organisme utilisant le
SMS pour véhiculer un code de session, en complément des habituels login
et mot de passe ?
La Postbank en Allemagne vient d'introduire un concept original (à ma
connaissance).
Jusqu'à maintenant, l'utilisateur avait une liste de codes à usage
unique (TAN). Il se logue sur le site avec numéro de compte et PIN, et
pour chaque transaction il donne un TAN (Transaction Number).
La nouveauté, c'est qu'il est maintenant possible de faire envoyer
(après s'être identifié) un TAN par SMS. Ils appellent ça un mTAN
(mobile TAN). Quand il est utilisé, un résumé de la transaction est
aussi envoyé par SMS, ce qui a pour but de permettre à l'utilisation de
détecter au plus tôt une fraude.
Par contre, ça ne répond pas vraiment au problème du phishing, plutôt à
celui de faire des transactions quand on est itinérant.
Connaissez-vous des iniatives de banques ou autre organisme utilisant le SMS pour véhiculer un code de session, en complément des habituels login et mot de passe ?
La Postbank en Allemagne vient d'introduire un concept original (à ma connaissance).
Jusqu'à maintenant, l'utilisateur avait une liste de codes à usage unique (TAN). Il se logue sur le site avec numéro de compte et PIN, et pour chaque transaction il donne un TAN (Transaction Number).
La nouveauté, c'est qu'il est maintenant possible de faire envoyer (après s'être identifié) un TAN par SMS. Ils appellent ça un mTAN (mobile TAN). Quand il est utilisé, un résumé de la transaction est aussi envoyé par SMS, ce qui a pour but de permettre à l'utilisation de détecter au plus tôt une fraude.
Par contre, ça ne répond pas vraiment au problème du phishing, plutôt à celui de faire des transactions quand on est itinérant.
Michel Arboi
On Thu Oct 13 2005 at 11:44, Mehdi BENKIR wrote:
Je ne crois pas que les banques soient nécessairement responsables du fait que leurs clients se fassent escroquer par des tiers.
En pratique, elles paient pour ne pas faire de vagues.
On Thu Oct 13 2005 at 11:44, Mehdi BENKIR wrote:
Je ne crois pas que les banques soient nécessairement responsables du
fait que leurs clients se fassent escroquer par des tiers.
En pratique, elles paient pour ne pas faire de vagues.
