[gull] e-banking
Daniel Cordey
dc at mjt.ch
Wed Aug 8 11:00:30 CEST 2007
On Wednesday 08 August 2007, magnus anderssen wrote:
> heu, d'accord mais seulement si c'est bien conçu et implémenté correctement
> (dans les règle de l'art).
Absolument.
> C'est pas parce que c'est complexe pour l'utilisateur que c'est sûr!
Oh oui :-)
> . Dans l'absolu, il est vrai, on diminue la probabilité d'un accès
> frauduleux en utilisant les moyens traditionnels de connexion, mais à
> quel prix?
Je sais... c'est toujours une question de compromis. Il faut que cette
complexite reste minimale pour l'utilisateur, tout en etant tres
contraignante pour le pirate. Les pirates ont parfois (de plus en plus) de
gros moyen et souvent beaucpup de connaissances de la cible. Je suppose que
les codes sur les cartes matrices ne sont pas une "fonction" et qu'il s'agit
de valeur aleatoires, dument memorisee par le serveur e-banking. Il semble
que le seul moyen, ou le meilleur compromis, soit justement d'utiliser ces
valeurs "aleatoires" (ou pseudos) en etendant le domaine de recherche afin de
rendre la vie "tres" difficile aux pirates.
> En termes d'argent
> et de complexité pour l'utilisateur (je dois avoir le lecteur si je veux me
> connecter alors qu'avec une carte matrice c'est plus portable. Le compromis
> reste à trouver.
Oui, dans le vas de l'UBS, je dois me balader avec cette "calculatrice"; ce
qui n'est pas pratique et represente donc un danger de perte ou de vol ! A
contrario, les cartes matrices des BCs se glissent facilement dans un
porte-monnaie, mais le domaine "aleatoire" est sans doute moins grand. Le
pire etant que qu'un pirate pourait photocopier cette carte (ce qui devient
inquietant), alors que pour la carte UBS, c'est plus difficile... quoique...
duplication des informations sur la puce de votre EC UBS, plus utilisation
d'une de ces "calculatrice... Le resultat est le meme, mais necessite un peu
plus de matos.
Pour l'utilisateur, le probleme se resume a s'assurer qu'aucune personne
tierce n'a acces a ces informations. C''est donc a l'utilisateur de garantir
la confidentialite de ces infos, alors que l'on essaie de focaliser
l'attention de l'utilisateur sur l'OS de son PC. C'est assez idiot puisque
cette connaissance represente un danger massivement plus grave que le
piratage du PC du client ! C'est donc la qu'est surtout la responsabilite du
client; et non dans l'OS.
> Un peu de futurologie (il faut bien remplacer William Gibson :-) ), si on
> continue sur cette lancée, on aura bientôt 5 connaissances à mémoriser, 12
> tokens générateur de code, 7 cartes à puce avec chacune son lecteur....
Et c'est la que M* a deja fait des tentatives de centralisation et
de "controle" de l'ensemble de ces connaisances. Et je ne pense pas qu'ils
aient rennonce !!! Donc, attention... :-(
> Le résultat principal est que l'utilisateur met tout ça dans le même
> classeur car il a peur de perdre un des éléments. (Sauf la carte à puce qui
> a un autre utiiisation dans le cas de la poste). Où est finalement la
> valeur ajouté par rapport aux autres méthodes (sans entrer dans un débat
> mathématique ayant pour sujet l'espace de combinaison).
Un bon exemple est l'utilisation d'agenda electroniques... quand la pile est
a plat ou que vous l'avez perdu, les scenarios d'horreurs defilent dans votre
tete, bien plus vite et plus fort que si vous utilisiez des bout de papiers.
La perte et les consequences de compromission sont alors de 100%... mais ce
genre d'usage represente aussi une "enrgie" minimum. Raison pour laquelle ce
genre de solution est privilegie par le plus grand nombre, et seul un petit
nombre de gens se soucie reellement et consciement des vertitables problemes
et de la valeur ajoutee.
Dans le cas de la question initiale, l'utilisateur doit simplement s'assurer
qu'il respecte les regles essentielles de la prudence, en fonction de ses
connaisance et en toute bonne foi. Les problemes legaux surgissent lorsque
les deux parties sont de "bonne foi" :-)
dc
More information about the gull
mailing list