Chiffrement

Le contexte

Voici quelques temps, j'ai reçu un courriel (dans mes spams) me réclamant une rançon. L'auteur ayant craqué mon mot de passe prétendait "troller" mes comptes (Google, Facebook, ...) si je ne lui versais pas plusieurs milliers de dollars en bitcoin. Mon mot de passe en clair figurait dans le courriel. Hmmm, inquiétant...

Bon, après quelques instants, je me suis rassuré:

  1. Je l'utilise ce mot de passe très simple que sur des sites sans importance
  2. Mes mots de passes Facebook, Gmail, banques, ... sont plus complexes et tous différents entre eux

Mais, comme les récentes affaires de Facebook l'ont démontré, le risque existe néanmoins de se faire craquer un mot de passe important, avec des conséquences fâcheuses. Que faire pour s'en prémunir ?

Certains proposent l'utilisation d'une voûte de mots de passe (password vault); celle-ci étant elle même protégée par un mot de passe, le risque, bien qu'atténué, est toujours présent.

Existe-t-il une meilleure option?

Pour être efficace, un mot de passe doit être:

  • Suffisamment complexe
  • Différents pour chaque site
  • Facile à retrouver en cas d'oubli

Il existe des solutions logicielles pour ça: les Single Sign-On (SSO). J'ai eu l'occasion d'implanter des solutions similaires en entreprise, entre autre Oracle Enterprise Single Sign-On (Oracle ESSO), qui a été vendu également sous le nom Passlogix, puis IBM Tivoli Password Manager. En "modélisant" le comportement du logiciel client (page web, logiciel "lourd", écran de connexion), on instruit ESSO à reconnaître différents objets Windows et à réagir aux demandes d'authentification, erreurs de connexion, expiration de mots de passe, etc... L'ensemble est protégé idéalement par 2 facteurs d'authentification, par exemple un mot de passe général + une carte sans contact. On définit pour chaque logiciel des politiques de complexité (durée de vie, longueur, pourcentage de majuscules, minuscules, chiffres et caractères spéciaux), puis ESSO générera et changera seul les nouveaux mots de passe dans les applications modélisées; plus personne ne connaîtra alors le mot de passe "en clair". L'ensemble requiert un ou plusieurs dépôts centralisés et encryptés (annuaire, base de donnée,...), un dépôt local sur chaque poste succeptible d'être utilisés par un utilisateur donné, et un mécanisme de synchronisation entre tous les dépôts. C'est performant, efficace, puissant, mais ce sont des solutions d'entreprise complexes, onéreuses et peu adaptées aux particuliers.

Et ça ne fonctionne que sous Windows!

La solution

Notons que certains sites utilisent le principe de délégation d'authentification: on voit ça souvent quand un site donné (ex: Soundcloud) demande d'utiliser un compte Google ou Facebook pour se connecter. J'ai une confiance limitée dans ce principe...

J'ai alors pensé à une approche différente: générer des mots de passe complexe en mélangeant deux chaînes de caractères, une "clef" secrète et le nom du site. J'utilise une clef identique pour tous les sites similaires (réseaux sociaux, sites musicaux, sites banquaires,...). La clef est mélangée avec le nom du site par des opérations logiques, le tout formant une graine unique (seed) pour un générateur pseudo-aléatoire de mot de passe complexe, impossible à deviner, mais simple à regénérer grâce à une petite application javascript figurant sur ma page perso.

Cette approche a plusieurs avantages:

  1. Simple.
  2. Aucun dépôt centralisé succeptible d'être corrompu.
  3. Utilisable de n'importe où.
  4. Mots de passe complexes impossible à deviner.
  5. Aucune vérification du résultat: quelqu'un utilisant mon site en "brute force" n'obtiendrait que des chaînes, sans pouvoir déterminer si celles-ci sont exactes ou non.
  6. Exécution locale; aucun transfert de la clef sur le réseau.

Version 1

Ma première version était un simple intercalage des lettres; facile à faire manuellement, mais peu sécuritaire.

Version 2

Ma seconde version consistait à parcourir chaque chaîne lettre par lettre, prendre le code ASCII de chaque lettre et les ajouter entre eux, en faire le modulo 93 puis ajouter 33 pour générer un résultat compris entre 33 (code ASCII du "!") et 126 (code ASCII du "~"). Mécanisme certe plus évolué et non linéaire (à cause du modulo), mais j'ai trouvé des cas où le mot de passe créé était refusé: caractères spéciaux interdis, ou deux caractères consécutifs identiques. De plus, en utilisant deux chaînes identiques (par exemple "aaaaa"), on pouvait relativement facilement déduire le mécanisme sous jacent.

Version 3

J'ai finalement abouti à la version actuelle qui utilise un générateur de nombres pseudo-aléatoire (PRNG) dont la graine est formée par le mécanisme expliqué précédemment. Cette version permet de spécifier la longueur et des options (caractères interdits et autorisés, répétition). Grâce au PRNG, les mêmes chaînes de départ créront un résultat identique.

Enfin, j'ai également créé une version API qui me permet d'appeler l'algorithme à partir d'une autre application, par exemple Excel.

http://(...)/chiffrement-api.html?c1?c2?ln?uc?lc?dg?sp?rp

Les paramètres sont les suivants:

  • c1: chaîne 1 (obligatoire)
  • c2: chaîne 2 (obligatoire)
  • ln: longueur du mot de passe à générer (22 par défaut)
  • uc: nombre de majuscules (0, 1, >1=autant que nécessaire - valeur par défaut)
  • lc: nombre de minuscules ( idem )
  • dg: nombre de chiffres ( idem )
  • sc: nombre de caractères spéciaux ( idem )
  • rp: autoriser les répétitions (0=non, >0=oui)

Pour appeller cette API à partir d'Excel, si A1 et B1 contiennent ma clef et le nom du site, je mets la formule suivante dans I1

 =WEBSERVICE("http://(...)/chiffrement-api.html?"&A1&"?"&B1"?"&C1&"?"&D1&"?"&E1&"?"&F1&"?"&G1&"?"&H1&"") 

Version 4

Les versions précédentes avaient 2 soucis majeurs: les permutations de caractères dans les chaînes n'étaient pas gérées (autrement dit "abc" et "bac" donnaient le même résultat), et toute la saisie se faisant au clavier, l'ensemble est sensible au keylogger ou au sniffage du Bluetooth (que je n'utilise pas pour cette raison précise, l'encryption de Bluetooth étant notoirement faible).

J'ai donc abouti à une version plus évoluée, qui ajoute un clavier virtuel (comme les banques) et une signature MD5 des chaînes avant la génération de la graine.

Comments

Tony Keys said…
Hi Francios

You sent me a message regarding the DMT8 and Eproms if you remember. I managed to get a copy of the ROMS from FOSTEX in the end and replaced the originals with the updated versions.
I also tried to upgrade to Flash drive and all sorts of other SSD's using adapters and even hard wiring but also had no sucess and was receiving same messages as you. I ended up putting a 2.5 inch IDE 40gb Hard drive which works perfectly. (but would have preferred Flash or SSD)
It's nice to know that others are still using this great recorder. Maybe we'll speak again in the future.

Take care
Kind Regards
Tony
Hi Tony,
thanks for your update, really appreciated.
I'll probably manage to get a 2.5" HD as well, as they are usually less noisy than 3.5".
What does the new ROM update bring to the unit?

Best Regards,
François

Popular Posts