Le problème :
=============
Les non voyants sous linux utilisent un navigateur en mode texte, links
http://artax.karlin.mff.cuni.cz/~mikulas/links/
Il est aussi tres utile lors des connexions mobiles, vu qu'il ne
recupère que le texte du document et ignore les images, qui le plus
souvent n'offrent aucune information supplémentaire.
La situation
============
Votre site ne fonctionne pas avec ce navigateur, ce qui est tres gènant.
Tout d'abord, une alerte javascript apparait, demandant si l'utilisateur
accepte que le javascript soit exécuté. si on refuse, on obtient une
page blanche, et on ne peut aller plus loin.
Si par contre on accepte, on obtient alors la page principale, dans
laquelle on ne voit aucun moyen d'entrer ses identifiants. par contre,
on peut voir un élément IFrame au milieu de l'écran.
Si on clique sur cet element IFrame, on obtient un écran indiquant qu'il
est impossible de poursuivre. (voir les captures d'écran attachées).
Analyse de la solution technique employée
=========================================
la solution technique employée pour "améliorer la sécurité" consiste a
faire afficher dans l'IFrame un clavier virtuel sur lequel il faut
déplacer la souris. si la souris reste plus de 500 millisecondes sur un
des "boutons" comportant les chiffres, alors, le chiffre en question est
sélectionné par un appel a la fonction javascript selectNumber qui
récupère le chiffre sélectionné dans l'ID du <div> et l'ajoute au code,
stocké dans le tableau codeTab.
(a noter que ce chiffre correspond au chiffre indiqué sur le bouton).
une fois le code tapé en entier, l'utilisateur clique sur le bouton
valider, qui lance la fonction sendForm.
Celle ci transforme tout d'abord le tableau codeTab en chaine de
caracteres, puis ajoute un nouveau champ au nom évocateur 'PWD' au
formulaire, et remplace la valeur du champ 'origin' par celle contenue
dans l'url appelée (qui apparamment est vide a présent).
ensuite, le formulaire est envoyé a l'url appropriée.
Ce systeme peut à priori sembler une bonne idée, mais il ne donne que
l'illusion de sécurité.
En effet, plusieurs méthodes sont utilisables pour passer outre, ou
récupérer le mot de passe du client, notamment par les logiciels espions.
le plus simple pour cela est d'utiliser une extension au navigateur,
genre barre d'outils, qui a accès a tout le fonctionnement de la
machinerie du navigateur en question, et peut donc espionner le
fonctionnement des javascript en temps réel. on peut meme simuler par un
script le fonctionnement du systeme, en ajoutant des bouts au formulaire
soi-même, notamment en effectuant les memes opérations que la fonction
sendForm.
d'autre part, les logiciels espions moins évolués peuvent aussi capturer
le mot de passe en effectuant des captures d'écran. En fonction des
finances de la victime, le jeu en vaut peut etre la chandelle pour le
crime organisé.
Conclusion
==========
Cette usine à gaz n'apporte strictement rien du point de vue de la sécurité.
Il serait nettement plus simple de faire comme vos concurrents de la
banque populaire, un formulaire tout simple avec un userID et un mot de
passe.
Certaines banques belges utilisent un systeme à base de carte à puce
type OpenSC qui effectue une opération cryptographique dans la dite
carte a puce, ce qui est ce que l'on sait faire de plus sécurisé à
l'heure actuelle. Vous montreriez votre avancée technologique en
utilisant ce procédé.
voir:
http://www.opensc-project.org/
Autres remarques
================
Votre serveur utilise actuellement l'algorithme de chiffrement RC4.
Celui ci est périmé et est même cassé depuis peu (notamment, c'est celui
qui est utilisé dans le protocole WEP du wifi), voir l'article
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2806945-4,00.html
Il serait une tres bonne idée de passer à un algorithme plus récent, par
exemple AES 256 bits.
Si votre logiciel serveur (Netscape Enterprise/3.6 SP3,
vraisemblablement sur Sun Solaris 8) ne sait pas faire, je vous
conseille de passer a Apache 2 (
http://httpd.apache.org ) qui lui sait.
