Si vous êtes comme moi, vous ne faites qu'une confiance partielle aux différents couples de login et mot de passe.
En effet, sans même entrer dans le détail du nombre de petits programmes espions que pourrait contenir votre ordinateur ou de quelqu'un qui écoute votre réseau, n'importe qui peut regarder derrière votre épaule et voir vos identifiants.

Pour pallier à tout ça, il a été inventé le principe d'authentification forte^[1] que j'ai déjà introduit dans ce blog.

Pour mémoire, le concept de l'authentification forte repose sur l'utilisation d'au moins deux facteurs parmi les suivants :
- Ce que l'utilisateur connaît (login, un mot de passe, un code PIN),
- Ce que l'utilisateur détient (une carte magnétique, une carte à puce, un « authentifieur »),
- Ce que l'utilisateur est (empreinte digitale, empreinte rétinienne, structure de la main, structure osseuse du visage ou tout autre élément biométrique)

On voit donc des solutions arriver, que ce soit en biométrie ou des secureID à mettre autour du cou, etc.
Le hic, c'est que toutes ces technologies coûtent de l'argent (et pas qu'un peu pour certaines d'entre elles), et moi de l'argent, je vous avoue que je n'en ai pas beaucoup...
Pourtant, pour certaines applications (quelles qu'elles soient) j'aimerais bien leur proposer une authentification forte quand même. Comment faire ?

Et bien je vais vous donner une méthode simplissime qui ne vous coûtera pas un rond !

Le principe général

Bon déjà on oublie la biométrie, donc ce que l'utilisateur est on met de côté.
On se concentre donc sur ce que l'utilisateur connaît et ce que l'utilisateur détient.

L'idée est de fournir à votre utilisateur (en plus d'un nom d'utilisateur et d'un mot de passe) une carte du style bataille navale de n colonnes sur n lignes (tout dépend de ce que vous voulez faire).

Votre utilisateur entre donc son login (CyberSDF) et son password (12345678), l'application le reconnaît (elle peut même lui dire bonjour) et, pour confirmer que c'est bien CyberSDF himself qui veut se connecter, lui demande la valeur de la case D7 de SA carte. Il cherche partout sa carte, la trouve, cherche la case D7, entre la valeur 2e68 et envoie.
Si la réponse est correcte, le serveur lui donne l'accès, sinon l'envoie bouler.

La réalisation (en php)

Créer la carte

Là vous me dites, t'es bien gentil mais comment je fais pour lui créer ta carte de bataille navale ?
Rien de plus simple ! Tout ce dont vous avez besoin c'est de son login (normalement ça devrait être bon) et d'un grain de sel^[2], qui est associé à l'utilisateur qui sera stocké quelque part.

Aller, le bout de code et on explique après :

[php]
<?php
function gencard($login='CyberSDF',$salt18 = 'voilàmongraindesel') {  

 $temp = md5($login.$salt18);
 $alphabet = 'ABCDE';

 for($i=1; $i<=5; $i++) {
  for($j=0; $j<5; $j++) { 
   $foo[$i][$alphabet[$j]] = dechex( (ord($temp[$i])*ord($temp[$j])) );
  }
 }
 return $foo;
}
?>

Voilà une fonction qui nous génère notre carte de 5 colonnes sur 5 lignes dans un tableau à deux dimensions.

1. Je fais un MD5 du login et du grain de sel histoire d'avoir quelque chose sur 32 caractères ;
2. Mon tableau aura 10 colonnes, donc 10 lettres de l'alphabet ;
3. Je commence une boucle de 1 à 5 inclus ;
4. Je met une seconde boucle de 0 à 5 exclu ;
5. Je crée mon tableau multidimensionnel déjà indexé avec les bons chiffres et lettres ;
6. Je renvoie le tableau.

Pour le remplissage du tableau, je me suis inventé un petit truc où je multiple les valeurs ASCCI de deux lettres et je transforme le résultat en hexadécimal. Pourquoi de l'hexa ? Tout simplement pour avoir de temps en temps des lettres, je trouve juste que c'est plus sympathique

Deux mises en garde tout de même ^[3] :
- Mon modèle mathématique est horrible !!! En effet, si vous comptez bien, je ne peux créer qu'une carte de 32 cases (mon MD5) donc pour une carte d'au-delà de 5*5 il y a forcement des répétitions. Le but ici n'est pas de vous donner le meilleur modèle mathématique mais de vous présenter le principe, charge à vous de faire votre propre machin.
- Le grain de sel ne doit pas être transmis en clair (pour le login on s'en fiche)

Afficher la carte

Là, rien de plus simple, c'est un simple parcours de tableau :

[php]
<?php $bar = gencard(); ?>
<table border="1" cellpadding="5">
 <tr>
  <th>&nbsp;</th>
  <?php
  $alpha = 'ABCDE';
  for($j=0; $j<strlen($alpha); $j++) {
  echo "  <th>".$alpha[$j]."</th>\r\n";
  }
  ?>
 </tr>
  <?php
    for($i=1; $i<=10; $i++) {
       echo " <tr>\r\n  <th>".$i."</th>\r\n";
       for($j=1; $j<=strlen($alpha); $j++) {
          echo "  <td>".$bar[$i][$alpha[$j-1]]."</td>\r\n";
       }
       echo "</tr>\r\n";
     }
 ?>
</table>

Demander une case

On a généré la carte qui va bien, notre utilisateur l'a imprimée, il ne reste plus qu'à l'utiliser.

On lui demande une case au pif :

[php]
<?php
$ltr = 'ABCDE';
echo $case = $ltr[mt_rand(0,4)].mt_rand(1,5);
?>

Notre utilisateur envoie à l'application le contenu de la case, et pour vérifier le résultat il n'y a plus qu'à recréer la carte (sans l'afficher bien sûr) et de comparer la valeur trouvée avec la valeur envoyée.

[php]
<form method="post" id="monform" name="monform" action="<?php echo $_SERVER['PHP_SELF'] ?>">
 <input type="text" id="val" name="val" /> 
 <input type="hidden" id="case" name="case" value="<?php echo $case ?>" />
 <input type="submit" />
</form>

[php]
<?php
function verifcase() {
 if($_REQUEST['val']!='') {
  $plop = gencard();
  if($plop[substr($_REQUEST['case'],1,2)][substr($_REQUEST['case'],0,1)] == $_REQUEST['val'])
   return true;
  else
   return false
 }
}
?>

Et voilà ! Simple comme tout non ?

Si jamais vous voulez voir ça en action, j'ai fait une démo

Vous avez peut être entendu parlé de la faille de sécurité sur le module IDN et qui à pour conséquence de faire planter Mozilla Firefox toutes plate formes et toutes versions.

Cette faille a été découverte le 4 septembre 2005 par Tom Ferris, remontée à la Mozilla Fundation le 6 septembre et publiée le 8 septembre

Comme a son habitude, les développeurs de Mozilla ont réagi avec la rapidité de l'éclair et ont publié dès le lendemain un patch et une procédure manuelle pour s'en prémunir.

Cher gros boulet,

Tu as l'air de bien t'amuser avec mon plugin Web2Mail en essayant de trouver une faille de sécurité pour spamer à partir du formulaire du plugin et ainsi utiliser abusivement les serveurs SMTP des pauvres blogueurs qui utiliseraient mon plugin.

Que tu cherches une faille de sécurité de ce plugin, je veux bien, il y en a eu une et elle à été corrigée rapidement dès que me l'a reporté et il y en a peut être d'autres ; Qui sait ? Nul n'est infaillible... et je serais même heureux qu'on me les rapportes si quelqu'un en trouves.

Mais toi tu es vraiment le pire hacker que j'ai pus voir

• Tu as déjà essayé hier et ça n'a pas marché ;
• Vu la frequence de tes tentatives tu dois utiliser un logiciel tout fait de CrACkER's (belin) ;
• Tu n'es même pas capable de lire le source du plugin (qui est libre) pour y trouver une faille potentielle ;
• Tu n'a même pas pensé que tes manipulations pouvaient être journalisées et ainsi me donner ton @IP
• Tu met une adresse e-mail d'un grand FAI en clair pour tester les éventuels succès.
• Tu n'as même pas eu la présense d'esprit de tester en local

En tout cas, un gros boulet ça sert parfois car tu m'as donné plein d'idées d'améliorations et de sécurisation de ce plugin.

Bien cordialement

Il y a quelques mois, John Gallet avait lancé un fil de discussion dans les groupes <news:fr.comp.lang.php> et <news:fr.comp.securite> Pratiques de codage php et webapps. Il nous avait promis à l'époque de nous faire une petite synthèse des réponses et débats que ce fil engendrait.

Voila qui est fait ! Ca a mis presque 7 mois et il y en aura bien fallu 3 pour l'écrire, mais connaissant le bonhomme ils s'est documenté à foison, fouillé partout, fait des tests sur ses propres machines.
Il nous affuble donc de 24 pages passionantes au format PDF écrite avec sa verve habituelle qui nous détaille les choses à ne pas faire et comment mieux protéger.

Un document indispensable à lire et à garder dans un coin et ce quelque soit son niveau en développement web dynamique.

Pratiquement toutes les banque proposent désormais de se connecter sur le site pour voir l'état de ses compte et effectuer quelques opérations.
Personnellement je suis depuis de nombreuses années chez une banque ou tout ce qu'il peu être possible de faire avec son compte existe dans la version web et je dois avouer que cela me facilite grandement la vie.

Je suis convaincu du sérieux de ma banque quant à la sécurité de leur réseau et serveurs. Je sais qu'ils ont pris les mesures techniques qui s'imposent, a savoir cryptage des transactions HTTP, pas de pages existantes sur le serveur web mais créées à la volée via une transmission d'informations chiffrées, divers audits d'intrusions, etc. Et sans nul doute que toutes les autres font de même (plus ou moins bien en fonction du sérieux ; Non je ne donnerais pas de nom)

Toute cette panoplie de mesure à de quoi rassurer et je le suis, surtout qu'ils affirment qu'à ce jour ils ne déplorent aucun piratage ni alerte de sécurité majeure.
Seulement dans tout ça il y a une énorme faille et ce n'est rien d'autre que vous, d'ailleurs je vous en ai déjà parlé.
En effet la plupart des banques (du moins françaises) ne proposent pour se connecter qu'un simple couple login/mot de passe. Le login est souvent le numéro de compte et le mot de passe se résume à une série de chiffre et (en fonction de la banque) peu être personnalisé.

Que se passe-t-il si quelqu'un trouve vos identifiants et vide votre compte ? Que ce soit par phishing, comme ça a été déjà le cas, par un trojan qui récupère les frappes claviers, par récupération des mots de passe enregistré dans votre navigateur (a ne surtout pas faire) à cause d'une faille de celui ci, par analyse du flux réseau, etc. ou tout simplement arrive à le deviner ?
Eh bien je vais vous le dire, la banque se décharge de toute responsabilité sur vous. Ben oui, c'est vos identifiants, c'est donc à vous d'en prendre soin et donc à vous de tout mettre en oeuvre pour les protéger ; Exactement comme votre code confidentiel de votre carte banquaire.

Il serait temps que NOS banques se penchent un peu plus sur les diverses méthodes d'authentification forte (il en existe des peu contraignantes et peu coûteuses), je vous invite donc à faire comme moi : écrire à vos banques afin de les sensibiliser un peu plus au problème pour qu'elle proposent des solutions pour mieux nous protéger.

Note

Le concept de l'authentification forte repose sur l'utilisation d'au moins de deux facteurs parmi les suivants :

• Ce que l'utilisateur connaît (un mot de passe, un code PIN),
• Ce que l'utilisateur détient (une carte magnétique, une carte a puce, un « authentifieur »),
• Ce que l'utilisateur est (empreinte digitale, empreinte rétinienne, structure de la main, structure osseuse du visage ou tout autre élément biométrique)

Je l'ai trouvé marrante celle la alors j'ai hésité entre la catégorie sécurité informatique et humour.

Imaginez le topo :

• Vous surfez tranquillement sur des sites de warez avec votre Internet Explorer sous votre Windows préféré et pas à jour
• Au cours de vos pérégrinations vous ouvrez un site malveillant.
• On vous force à télécharger (à l'insu de votre plein grès) un petit bout de code
• Le petit bout de code s'exécute en tâche de fond et va télécharger et installer un petit programme
• Ce petit programme scanne vos disques (et clés USB connectées) pour en sortir la liste de vos fichiers texte et M$-Office (word, excel, BdD accèss) et les zip.
• Une fois la liste bien établie, le programme les chiffre
• Puis un petit message vous invite à payer une rançon de 200$ (USD) par virement pour obtenir la clé qui vous permettra de déchiffrer vos données.

Malheureusement ce n'est pas une blague.

Les accès en ligne aux banques est très loin d'être sécurisé, c'est un fait. Pour la plupart, un simple couple identifiant - mot de passe suffit et c'est très loin d'être sécure. En effet il suffit de se procurer ces identifiant pour pouvoir vider votre compte en quelques clics (et avec le jeu des transfert...)
Il existe pourtant des dizaines de méthodes (plus ou moins dures) pour authentifier de manière plus sures un client.

Les banques anglaises collaborent pour le choix d'un outil de sécurité commun qui pourrait être utilisé par tous leurs clients. Ils se tourneront vraisemblablement vers quelque chose d'hyper technologique faisant appel à du chiffrage ou des clés à révocation courtes.

Il existe d'autres méthodes, plus simple, moins techno, à pas cher pour augmenter l'authentification.
Je vous en livre une ici :
Donner à chaque client une carte contenant un tableau style bataille navale, dans ce tableaux on y met des lettres et des chiffres (en fonction d'un algo correspondant au client et d'autres paramètres).
Quand on se connecte sur le serveur, on y entre comme auparavant son identifiant et son mot de passe et la, le serveur demande : M6
Vous cherchez la case M6 sur votre carte et répondez au serveur ce qu'elle contient.

Voila. Maintenant on peu aussi donner une carte magnétique, une carte a puce, voir utiliser son empreinte digitale, empreinte rétinienne, structure de la main, structure osseuse du visage ou tout autre élément biométrique, ou, le plus courant un SecureID

Presence-pc nous informe que Internet Explorer se voit affublé d'une nouvelles failles permettent aisément et à n'importe qui d'installer des chevaux de Troie à l'insu de l'utilisateur.

Heureusement pour les utilisateurs de IE : La société [...] attendra que les correctifs soient en ligne avant de diffuser des détails sur les versions affectées par ce défaut. et aucune exploitation de ces failles n'a été constatée.

Une vulnérabilité bien génante, encore non patchée mais modérément critique, du moteur Javascript des navigateurs Netscape6+|7+ Mozilla1+ et Firefox1+ à été révélée par secunia. Celle vulnérabilité, grâce à du code malicieux permet de récupérer l'état mémoire ce qui peu permettre la fuite d'information sensible.

Solution :

• La plus simple, rapide et efficace : Désactiver JavaScript.
• La plus geek : patcher

Ressources :

• Mozilla bug repport
• Avis pour : Firefox
• Avis pour : Mozilla Suite
• Avis pour : Netscape
• Test de la faille chez bugzilla
• Test de la faille chez Secunia

Le partage de connexion internet privée, bien relayée par l'association Paris-SansFil est de plus en plus suivis et médiatisé. J'en veux pour preuve un article de 01net vantant le partage de sa connexion ADSL via wifi avec les voisins.

Personnellement, et bien que je sois assé d'accord avec l'idée qu'une connexion internet devrait être du service publique et gratuite, je me pose quelques questions.

Qui est responsable en cas de piratage du réseau ?

Pour moi c'est celui qui partage qui a la main sur le réseau, donc c'est lui qui est responsable en cas de plainte.

Qui est responsable si un utilisateur fait le con avec la connexion ?

Celui qui paye le FAI, donc le partageur, ira expliquer à Mr le Juge que ce n'est pas lui mais son voisin qui se connecte via son IP parce qu'il a créé un réseau local wifi. Maintenant pour savoir quel voisin incriminer, il va falloir regarder de plus près les logs.

Comment être sur que celui qui maintient le réseau ne va pas fouiller dans votre vie privée (lectures des mails, vérification des sites visités, récupération de mots de passes, etc.) ?

On ne peut tout simplement pas être sur ; Il faut faire confiance ou tout chiffrer sur le LAN.

Donc pour moi, si vous voulez partager votre connexion ou utiliser celle d'un autre, ok pourquoi pas, si vous voulez mais à vos risques et périls.