Paiements dits sécurisés sur internet

"cyber@caf.fr" <cyber@caf.fr> wrote in news:bqhk2r$fhv$1
@reader1.imaginet.fr:

Bonjour,

Je prépare un travail sur la "sécurité" sur Internet.
Et j'aimerai connaitre les points forts du paiement sécurisé sur
Internet et ses points faibles.
Pouvez-vous me donner quelques éléments ?

A ma connaissance, il n'y a pas eu d'attaque avec des conséquences
significatives vis à vis des protocoles de paiement, ni d'ailleurs vis à
vis des utilisateurs qui envoient leur numéro de CC par e-mail, une
pratique qui scandalise pas mal de gens mais finalement reste sans
conséquence.

Il y a eu par contre de gros problèmes de lots importants de cartes de
crédit "volés" suite à l'exploitation de vulnérabilités dans les
serveurs de grosses boutiques on-line et, surprise, off-line. Fin 2002,
nous avons donné un trainings aux USA et il semble qu'un de nos
dévelopeurs a utilisé sa carte de crédit aux USA dans un magasin "de
briques et de mortier". Pas de chance, il a fait partie du lot des
personnes qui ont été la victime d'une fraude suite à une très grosse
perte de données chez un organisme d'autorisation: un lot très important
de cartes (au minimum 50000) avait du être révoqué alors. Je suis sûr
qu'il y a des gens ici qui en savent plus que moi à ce sujet. Cette
carte avait été utilisée en ligne dès 1995 sans problème.

qqes hacks important on line

http://www.ecommercetimes.com/perl/story/8063.html

Commencez par Google, puis revenez avec vos questions.

Il n'est pas question de faire votre travail a votre place.

Salus

Bonjour,

Je prépare un travail sur la "sécurité" sur Internet.
Et j'aimerai connaitre les points forts du paiement sécurisé sur
Internet et ses points faibles.
Pouvez-vous me donner quelques éléments ?

merci

Salus wrote:

Commencez par Google, puis revenez avec vos questions.

Il n'est pas question de faire votre travail a votre place.

Salus

Bonjour,

Qui a parlé de faire un travail à la place d'un autre ?
Il ne s'agit pas d'une demande de rédaction mais d'aide de direction,
parce que merci Google je connais, et que sur un Newgr spécialisé il est
possible d'avoir des infos, etc... de professionnels qui peuvent mieux
orienter les recherches.
Maintenant si seul Google suffit alors ...

Encore un coincé de la diffusion de l'info ou un prof qui se la pête.

Bonjour,

On Tue, 02 Dec 2003 10:10:31 +0100, cyber@caf.fr <cyber@caf.fr> wrote:

Je prépare un travail sur la "sécurité" sur Internet.
Et j'aimerai connaitre les points forts du paiement sécurisé sur
Internet et ses points faibles.
Pouvez-vous me donner quelques éléments ?

Je ne suis pas sûr que ce soit le groupe le plus adapté, fr.comp.securite
(ou peut-être fr.misc.finance.banque ou fr.misc.gestion) serait
probablement un meilleur choix, mais quelques éléments:

- le paiement dit "sécurisé" consiste dans la majorité des cas simplement
en un chiffrement de la communication entre le client et le serveur
(passerelle de paiement WWW/réseau bancaire) via SSL/TLS. Ca protège
contre les gens qui pourraient avoir envie de consulter les numéros de
carte en transit, ce qui dans la pratique ne peut arriver qu'au niveau du
réseau local du client, donc c'est vraiment pour faire genre.

- l'autre élément est souvent aussi que le serveur est opéré par un tiers
(une banque ou un de ses prestataires), et que le commerçant (pas plus que
ses employés) n'ont connaissance des coordonnées bancaires du client

- un élément important est bien entendu la protection du serveur: s'il est
difficile d'intercepter les coordonnées bancaires pendant le paiement
(même sans chiffrement, à part le cas cité plus haut), il est quelquefois
beaucoup plus facile de s'attaquer au serveur, et en plus on peut ainsi
récupérer des tonnes de numéros de cartes d'un coup.

- cependant, tout ceci ne représente qu'un risque miniscule, et une
proportion quasiment nulle de la fraude lors d'un paiement en VAD

Les types de fraude recontrés sont en effet les suivants:

* vu du point du vue du client:
- on récupère ses coordonnées bancaires quand il utilise sa carte
(physiquement ou à distance) et on les utilise (ça inclut perte et vol,
bien entendu)
- on "invente" des coordonnées bancaires et on tombe sur les siennes, et
on les utilise
- un commerçant utilise ses coordonnées bancaires de façon inappropriée

Je pense qu'en VAD, le 2e risque ci-dessus est *de très loin* le plus
important à l'heure actuelle. Il faut noter cependant que le client est
très bien protégé, que ce soit légalement (en France) ou
contractuellement, et il est très facile de contester une opération
frauduleuse (tellement facile que certains en abusent, voir ci-dessous):

* vu du point de vue du commerçant.
- "on" utilise les coordonnées bancaires d'une carte qui n'est pas la
sienne (récupérées)
- idem, mais inventées
- la transaction CB n'est pas frauduleuse, mais le client "profite" de la
protection qui lui est offerte pour contester une transaction en cas de
litige commercial
- idem, mais le client (qui est dans ce cas celui qui commet la fraude)
conteste la transaction alors qu'il a bien reçu le service ou la
marchandise et que tout va bien (soit il indique n'avoir jamais effectué
la transaction, soit il invoque un litige commercial inexistant).

Comme le client est très bien protégé, forcément, le commerçant l'est
moins, ou en tous cas c'est plus complexe à mettre en oeuvre.

On peut se protéger contre le premier type de fraude par certains systèmes
(obligation de fournir le CVV/CVC si le "voleur" est idiot, vérification
de l'adresse dans certains pays...). Cette protection est très efficace
(si elle est utilisée) contre le deuxième type de fraude (facile
d'inventer un numéro de carte, plus difficile d'inventer le CVV/CVC qui va
avec... Mais je prie encore pour que le CVV/CVC soit effectivement un
numéro aléatoire, et non le résultat d'une opération cryptographique sur
le numéro de la carte comme certains le prétendent, sinon c'est
complètement idiot).

Pour le dernier cas, on peut relativement bien se protéger en accumulant
des éléments d'identification du client-fraudeur, et évidemment dans le
cas de marchandises ça devient encore plus facile, surtout si on prend la
précaution de livrer contre signature.

fu2 fr.comp.securite

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

<cyber@caf.fr> a écrit dans le message de
news:bqkdb8$8m$1@reader1.imaginet.fr...

Salus wrote:

Commencez par Google, puis revenez avec vos questions.

Il n'est pas question de faire votre travail a votre place.

Salus

Bonjour,

Qui a parlé de faire un travail à la place d'un autre ?
Il ne s'agit pas d'une demande de rédaction mais d'aide de direction,
parce que merci Google je connais, et que sur un Newgr spécialisé il est
possible d'avoir des infos, etc... de professionnels qui peuvent mieux
orienter les recherches.
Maintenant si seul Google suffit alors ...

Encore un coincé de la diffusion de l'info ou un prof qui se la pête.

crytono@mi.com, c'est donc toi ? T'as beau changer de fakename et poser des
questions à différents newsgroups, on te suit à la trace...
Pour ceux qui n'y étaient pas, ça a commencé sur fr.comp.lang.c .

-- JD

| On peut se protéger contre le premier type de fraude par certains systèmes
| (obligation de fournir le CVV/CVC si le "voleur" est idiot, vérification
| de l'adresse dans certains pays...). Cette protection est très efficace
| (si elle est utilisée) contre le deuxième type de fraude (facile
| d'inventer un numéro de carte, plus difficile d'inventer le CVV/CVC qui va
| avec... Mais je prie encore pour que le CVV/CVC soit effectivement un
| numéro aléatoire, et non le résultat d'une opération cryptographique sur
| le numéro de la carte comme certains le prétendent, sinon c'est
| complètement idiot).
|
Le CVV2/CVC2 est effectivement le résultat d'une opération cryptographique.
Si vous y réfléchissez, vous vous rendrez compte que cela vous protège d'un
employé indélicat dans une banque car ce numéro n'est pas stocké pour être
vérifié à chaque opération, mais bel et bien recalculé à chaque opération.
Il est crypté avec une clé triple DES, tout comme le CVV et le CVC qui sont
eux sur votre piste.

On 04 Dec 2003 22:39:11 GMT, Serge Ritzenthaler <rstuvwxyz@chezeux.com>
wrote:

Le CVV2/CVC2 est effectivement le résultat d'une opération
cryptographique.
Si vous y réfléchissez, vous vous rendrez compte que cela vous protège
d'un
employé indélicat dans une banque car ce numéro n'est pas stocké pour
être
vérifié à chaque opération, mais bel et bien recalculé à chaque
opération.

Si on y réfléchit bien, ça me paraît complètement idiot, parce que si un
employé indélicat communique l'algo et la clef, ce n'est alors pas
quelques cartes qui sont affectées, mais toutes les cartes qui utilisent
la même clef!

Et j'espère bien entendu que contrairement à ce que j'ai vu suggérer par
certains sites, il n'y a pas de terminaux capables de vérifier la validité
de cette info par eux-mêmes, parce que dans ce cas l'info circule, et
finira bien par tomber entre les mains de ceux qui ne devraient pas
l'avoir.

Et évidemment, même si l'info ne circule pas, le fait que la valeur soit
calculée va permettre de retrouver l'algo et la clef. Même si c'est non
trivial avec 3DES, ce genre de chose a une valeur marchande suffisante
pour que certains y mettent beaucoup de moyens, et ça finira bien par
arriver.

La seule solution qui m'aurait paru opportune serait que la valeur
*stockée dans la BDD de la banque* soit cryptée, comme un mot de passe
dans un fichier passwd (ou plutôt shadow ou master.passwd) sous Unix, mais
que la valeur stockée sur la carte et transmise soit bien une valeur
aléatoire et non calculée. Ca empêcherait le problème que vous évoquez, et
tous ceux que j'évoque moi.

Non?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

"Jacques Caron" <jc@imfeurope.com> a écrit dans le message news:
oprzpgmenlq1hokb@news.free.fr...
| On 04 Dec 2003 22:39:11 GMT, Serge Ritzenthaler <rstuvwxyz@chezeux.com>
| wrote:
|
| > Le CVV2/CVC2 est effectivement le résultat d'une opération
| > cryptographique.
| > Si vous y réfléchissez, vous vous rendrez compte que cela vous protège
| > d'un
| > employé indélicat dans une banque car ce numéro n'est pas stocké pour
| > être
| > vérifié à chaque opération, mais bel et bien recalculé à chaque
| > opération.
|
| Si on y réfléchit bien, ça me paraît complètement idiot, parce que si un
| employé indélicat communique l'algo et la clef, ce n'est alors pas
| quelques cartes qui sont affectées, mais toutes les cartes qui utilisent
| la même clef!
|
Certe mais je vous rassure les concepteurs y ont pensé

| Et j'espère bien entendu que contrairement à ce que j'ai vu suggérer par
| certains sites, il n'y a pas de terminaux capables de vérifier la validité
| de cette info par eux-mêmes, parce que dans ce cas l'info circule, et
| finira bien par tomber entre les mains de ceux qui ne devraient pas
| l'avoir.
|
Seuls des modules cryptographiques ( hardware ), style BNT "connaissent " la
clé. On la leur sert sous forme chiffrée. Donc oui il existe des matériels
qui connaisent cette clé, mais non, il n'existe aucun terminal de paiement
ou de retrait qui connait ces clés, du moins en France.

| Et évidemment, même si l'info ne circule pas, le fait que la valeur soit
| calculée va permettre de retrouver l'algo et la clef. Même si c'est non
| trivial avec 3DES, ce genre de chose a une valeur marchande suffisante
| pour que certains y mettent beaucoup de moyens, et ça finira bien par
| arriver.
|
Jusqu'à récemment une bonne partie de ces informations étaient en simple DES
( problème bien plus trivial que le triple DES ) et il n'y a pas eu de
fraudes massives.

| La seule solution qui m'aurait paru opportune serait que la valeur
| *stockée dans la BDD de la banque* soit cryptée, comme un mot de passe
| dans un fichier passwd (ou plutôt shadow ou master.passwd) sous Unix, mais
| que la valeur stockée sur la carte et transmise soit bien une valeur
| aléatoire et non calculée. Ca empêcherait le problème que vous évoquez, et
| tous ceux que j'évoque moi.

Cette méthode avec aléa est surtout utile en RSA et est effectivement
utilisée dans les puces EMV pour l'authentification. Pour un cryptage
symétrique, je ne vois ce que l'aléa rapporterai.
|
| Non?
|
Ben non

FU2 cryptologie, car l'utilisation des algos de crypto est bien de la
crypto. Petit passage par carte à puce, car c'est en charte, vu que le
groupe moyens de paiement n'est pas passé.

On 08 Dec 2003 14:34:47 GMT, Serge Ritzenthaler <rstuvwxyz@chezeux.com>
wrote:

"Jacques Caron" <jc@imfeurope.com> a écrit dans le message news:
oprzpgmenlq1hokb@news.free.fr...
| Si on y réfléchit bien, ça me paraît complètement idiot, parce que si
un
| employé indélicat communique l'algo et la clef, ce n'est alors pas
| quelques cartes qui sont affectées, mais toutes les cartes qui
utilisent
| la même clef!
|
Certe mais je vous rassure les concepteurs y ont pensé

Et?

Seuls des modules cryptographiques ( hardware ), style BNT "connaissent"
la clé. On la leur sert sous forme chiffrée. Donc oui il existe des
matériels qui connaisent cette clé, mais non, il n'existe aucun terminal
de paiement ou de retrait qui connait ces clés, du moins en France.

Et quel est l'intérêt pour ces matériels de connaître cette clef? Et au
fait, c'est quoi un "BNT"? Google ne m'a pas fourni de réponse évidente...

| La seule solution qui m'aurait paru opportune serait que la valeur
| *stockée dans la BDD de la banque* soit cryptée, comme un mot de passe
| dans un fichier passwd (ou plutôt shadow ou master.passwd) sous Unix,
| mais que la valeur stockée sur la carte et transmise soit bien une
valeur
| aléatoire et non calculée. Ca empêcherait le problème que vous
évoquez, et
| tous ceux que j'évoque moi.

Cette méthode avec aléa est surtout utile en RSA et est effectivement
utilisée dans les puces EMV pour l'authentification. Pour un cryptage
symétrique, je ne vois ce que l'aléa rapporterai.

Je ne suis pas sûr qu'on parle encore de la même chose. Moi je parle de la
façon dont le CVC2/CVV2 (les 3 chiffres au dos de la carte) est généré et
vérifié. La seule méthode qui me semblerait fiable est que cette valeur
soit générée aléatoirement, imprimée au dos de la carte, et un hash de
cette valeur stocké dans la base de données qui sert à sa vérification
(chez l'organisme émetteur de la carte), exactement comme un password Unix.

Le fait que cette valeur soit au contraire le résultat d'une opération
cryptographique sur le numéro de la carte et quelques autres éléments (la
date de validité, une clef privée...) ouvre (ouvrirait?) la porte à la
publication de cette opération, et donc à l'inutilité absolue de cette
valeur. C'est un peu comme si on comptait encore sur la seule clef de Luhn
pour se protéger des générateurs de numéros de cartes bancaires, en la
rendant juste un peu plus compliquée...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

| > Seuls des modules cryptographiques ( hardware ), style BNT "connaissent"
| > la clé. On la leur sert sous forme chiffrée. Donc oui il existe des
| > matériels qui connaisent cette clé, mais non, il n'existe aucun terminal
| > de paiement ou de retrait qui connait ces clés, du moins en France.
|
| Et quel est l'intérêt pour ces matériels de connaître cette clef? Et au
| fait, c'est quoi un "BNT"? Google ne m'a pas fourni de réponse évidente...
|
la BNT (Boite Noire Transactionnel si je ne m'abuse) est un équipement
cryptographique vendu par BULL.
Il sert à stocké des clés encrypter, a décoder ces même clés, à utiliser ces
clès decypter pour faire soit du DES, soit du triple DES, soit du RSA afin
de vérifier entre autre les codes confidentiels, les CVV, les éléments de
sécurités de la puce, les scellements des messages, ...

| > | La seule solution qui m'aurait paru opportune serait que la valeur
| > | *stockée dans la BDD de la banque* soit cryptée, comme un mot de passe
| > | dans un fichier passwd (ou plutôt shadow ou master.passwd) sous Unix,
| > | mais que la valeur stockée sur la carte et transmise soit bien une
| > valeur
| > | aléatoire et non calculée. Ca empêcherait le problème que vous
| > évoquez, et
| > | tous ceux que j'évoque moi.
| >
| > Cette méthode avec aléa est surtout utile en RSA et est effectivement
| > utilisée dans les puces EMV pour l'authentification. Pour un cryptage
| > symétrique, je ne vois ce que l'aléa rapporterai.
|
| Je ne suis pas sûr qu'on parle encore de la même chose. Moi je parle de la
| façon dont le CVC2/CVV2 (les 3 chiffres au dos de la carte) est généré et
| vérifié. La seule méthode qui me semblerait fiable est que cette valeur
| soit générée aléatoirement, imprimée au dos de la carte, et un hash de
| cette valeur stocké dans la base de données qui sert à sa vérification
| (chez l'organisme émetteur de la carte), exactement comme un password
Unix.
|
| Le fait que cette valeur soit au contraire le résultat d'une opération
| cryptographique sur le numéro de la carte et quelques autres éléments (la
| date de validité, une clef privée...) ouvre (ouvrirait?) la porte à la
| publication de cette opération, et donc à l'inutilité absolue de cette
| valeur. C'est un peu comme si on comptait encore sur la seule clef de Luhn
| pour se protéger des générateurs de numéros de cartes bancaires, en la
| rendant juste un peu plus compliquée...
|
Le CVV est le résultat d'une opérationcryptographique sur des éléments tels
que le numéro de carte et d'autres. Je n'ai plus la liste en tête, mais je
pourrais la retrouver facilement et je pense que c'est trouvable sur le net
du coté de MasterCard.
Ensuite c'est codé par une clé et c'est le résultat de ce code que vous
voyez.

Il va falloir que l'on m'explique en quoi un chiffre calculé et codé est
moins sur qu'un chiffre tiré au hasard et codé.
De plus, je pense que la BNT est plus sur pour stocké des données chiffrées
qu'un fichier de password Unix vu les conditions de saisies et
d'introduction des clès.

| Jacques.
| --
| Interactive Media Factory
| Création, développement et hébergement
| de services interactifs: SMS, SMS+, Audiotel...
| http://www.imfeurope.com/