Bonjour à tous!
 
J'ai vu une fois un outil qui me semblait génial -encore me faudrait-il plus d'infos dessus: Il s'agissait d'un porte clé générateur de mots de passes.
 
Je m'explique: ces portes clés doivent intégrer un algo, et de quoi se baser sur la date. Avec un peu de chance, de quoi les mettre à jour mais ça...? Enfin bon.
De l'autre côté, on met sur le serveur un programme avec les mêmes algos.
 
Le password change selon une certaine fréquence, en même temps sur le serveur et sur le porte clé. Très sympa niveau sécurité, surtout pour les gens comme moi qui ont la manie de se logger partout, et pas forcément sur des machines dont ils peuvent être surs!
 
Connaissez vous ces systemes ou des alternatives qui permettraient d'arriver au même résultat, et qui soient implémentables sour linux?
 
Je vous remercie
 
Nicolas

Bon alors deja, generer un mot de passe avec comme graine la date c'est une tres mauvaise idee, car ca permet beaucoup plus facilement de remonter au mdp genere, netscape avait fait cette erreur pour le codage des transactions https et ils avaient change ca vite fait.
Comme graine de mdp mieux vaut utiliser /dev/urandom ou autre, il existe un RFC la dessus.
Apres tu peux utiliser ta date avec un algo de hachage ca ne sera pas de l'authentification forte mais bon, en supposant que tu aie un serveur de temps aui synchronise tes deux pc ou aue tu genere un mdp toutes les minutes, comme ca c'est plus coulant.
Il suffit d'utiliser ta cle dans des pcs qui disposent d'udev et que ta cle declenche automatiquent un script quand elle est branchee.
I faudrait que ta cle genere le pass de maniere autonome, or tes mots de passe reviennent uniquement a comparer les algorithmes de chiffrage dans le script contenu dans ta cle et dans ton pc en plus de tester l'identite de la cle. Il existe par ailleurs, pam-usb :
http://www.lea-linux.org/cached/in [...] 9_USB.html
Ton dispositif est pas mal, puisqu'il se base sur un systeme de jeton [token] perimable. Cependant l'algo de chiffrage doit etre dans un script en clair dans la cle, donc si quelqu'un trouve la cle, tout le systeme est perime, et au lieu de revoquer une cle tu bouzille toute l'authentification. Ton systeme est donc fort mais attention aux fichiers en clair.

Ok merci entre temps je me suis renseigné, les fameux SecurID de RSA etc...  J'ai fini par trouver !
 
Mais le prix est... O_o >_< '_' enfin voilà quoi.
 
Je pense donc qu'il doit y'avoir moyen de se faire son securID, avec son petit programme sur le serveur. Ca ne me parait pas à premiere vue bien insurmontable!
 
Je lance donc le projet OpenToken (faut bien commencer un jour par en faire un de projet libre nan?).
 
- Du côté serveur donc, un programme qui change le mot de passe toute les minutes.
- Du côté utilisateur, un porte clé NON USB, muni d'un écran petit écran LCD de quelques chiffres et d'un bouton
- Un algo qui génerera donc un jeton toutes les minutes
 
Pour le côté serveur, un petit peu de C, je sais pas faire de programmation PC xD mais ça doit pouvoir se faire de manière assez basique, avec l'algo dans un petit programme, et un script pour en récuperer le mot de passe et le foutre dans le systeme de login.
 
Pour le côté clé, il va falloir trouver
- Un microcontroleur, directement programmable avec peu d'électronique autour
- Possédant un contrôleur d'affichage sur un petit LCD genre alphanumérique ou numérique 8 caractères
- Horloge interne très précise ou, le pied, une capacité de se synchroniser sur l'émetteur de brunswick (radio piloté). Voir mettre un composant externe pouvant gérer ça, ça doit pouvoir se trouver pour un prix honnête; avantage, plus jamais à s'emmerder de la synchro du serveur (via un serveur de temps) et du générateur nomade!
- Alimentation pile de montre.  
- Un petit connecteur pour reprogrammer de temps en temps l'algo, par exemple changer l'initialiseur de la graine.
 
l faudrait regarder chez Atmel pour un petit AVR (ils me semblent une bonne référence dans le genre j'intègre tout plein de fonctions et c'est hyper simple à programmer), ou je crois que Linear a pondu  récemment une série très basse conso aussi . Par contre ça sent le CMS, pas drôle à monter :S mais en traversant j'ai un peu peur de la place du porte clé...
 
Le fait de ne pas être USB empêche une lecture "facile" des algos. Bon bien sur, un pti coup de Codewarrior sur le µC résoud le probleme, les SecurID et autres SafeWord sont "tamper proof" cad qu'ils se suicident si on essaye de les ouvrir...
 
Existerait-il déjà des solutions integrées chez les constructeurs qui permettraient de gagner de la place et du temps? Pour ma part je viens de commander un "free sample" chez SafeWord, je vais recevoir le soft évaluation 30 jours et un porte clé, je pense que ça peut m'aider.
 
Enfin au niveau de l'algo, c'est un peu épineux comme choix:  
- Génération du clé à partir du temps, et d'un code initial (hachage du temps, et un algo qui ponds un nouveau code utilisant le temps et le code initial, voir quel systeme serait adapté)
 
- Génération de chaque clé à partir de la ou les précédentes, ainsi le temps n'est pas utilisé en lui même mais n'est utilisé que pour savoir combien de clés ont été générées depuis la derniere demande de génération de jeton, souci: ça pompe plus de ressources et ça peut même en pomper séverement si par exemple je passe deux jours sans me connecter, à un jeton toutes les minutes la geule que va tirer le pauvre microcontroleur de ma clé quand je vais lui demander 3*24*60= 4320 générations de clés d'un coup... Aille!
 
- Autre solution? Je n'y connais absolument rien en crypto!
 
 
Voilà sujet à débattre ^^

Bah jvoulais choisir le titre "Projet OpenToken" mais pas de bol, ce nom est déjà pris xD
 
Je cherche à me renseigner comment les montres radiopilotées se mettent à jour. Car le DCF c'est joli mais à 77kHz, tu t'affranchis pas d'une certaine taille d'antenne, donc ils n'utilisent pas le DCF (à moins que....?). L'emetteur d'Allouis France Inter, c'est 162kHz mais la reception est vraiment pête b* (bon ok un composant tout integré doit exister). La solution la plus précise: recepteur GPS, ça se trouve de cher à moins cher, y'en a un à 7€ sur radiospares, mais ça prends de la place et pompe 90mA, moi j'ai juste besoin d'un signal horaire, pas de recevoir 12 canaux pour savoir ou je suis...

Très bon projet, je n'ai pas forcément de connaissances qui pourraient aider directement ton projet mais je suis prêt à tester et participer aux idées (sa peut venir) !

A Air France les employés avaient cela pour l'accès à distance.
 
Enfin presque, ils avaient un petit bidule sur lequel ils devaient tapper leur mot de passe, et le bidule générait un mot de passe de connection valable dans la minute après plus bon (tout ca sans jamais être connecté au serveur bien sûr).

Checkpoint ont une technique similaire pour un type d'authentification pour des VPNs. il me semble. Une sorte de mini-calculette qui nécessite un mot de passe pour générer un One Time Password. De mémoire je crois qu'il reste valide 15 minutes. Il reste valable une minute. Et expire donc si aucun connexion n'est faite.

Une minute je trouve ca particulièrement court, il faut que le serveur en face et ton petit générateur soit particulièrement synchrone pour que cela marche. Si tu gardes plusieurs mois/années ce système, il y a de forte chance que les deux équipements dérivent temporellement. En particulier le truc standalone (le serveur a la rigueur via NTP)...

C'est ca le truc de checkpoint
http://www.neurotechafrica.com/activcard_tokens.php

ah bah voilà, c'est exactement cela.

Ok c'est cool des réponses ^^
 
Voui y'a de l'idée sur ces tokens mais ceci dit le fait de rajouter un clavier peut être miniaturisé dans le cas d'une production industrielle, autant au stade de DIY, c'est impossible. Du CMS c'est encore faisable (je vais m'acheter une buse à air chaud pour mon fer) mais tous ces genres de microtrucs directement sur une feuille de plastique imprimée... Faut avouer que c'est tendu :S
 
Pour la synchro j'avais l'idée justement d'intégrer une horloge DCF, une horloge radio quoi. Comme les réveils radiopilotés. On l'utilise mettons une fois par jour (ou sur demande) et hop on se resynchro, comme via un serveur NTP. Résultat, niveau dérive, on est au pire aux quelques secondes de différence, et comme cette dérive est statique doit y'avoir moyen de pouvoir la corriger (expliquer au serveur qu'il doit récuperer l'horloge du NTP et y ajouter par exemple 3 secondes).
 
Pour l'instant je potasse justement cette idée de DCF: les montres y arrivent dans un petit volume, tous les kits le font avec une grosse antenne; il faut trouver quel composant est utilisé dans ces montres, et quelle est la structure de l'antenne. Pour l'instant j'ai pas trouvé; on m'a dit de m'en procurer une et de la dépioter, j'attends d'en voir une à genre 5€ pour lui faire la peau.

Petite réflexion :
 
Si tu fais un projet opentoken, le protocole de génération de la clé sera ouvert. Ton système est alors faillible dans la mesure où n'importe quelle clé opentoken permet d'accéder à n'importe quel système protégé par opentoken.
Il faut donc trouver un algorithme qui prend 2 paramètres. Un paramètre en dur, type clé, qui est fourni en hard sur ton generateur de token et est différente pour chaque système déployé. L'accès à ce paramètre périme en effet ton système.
C'est pour ca que les clés commerciales font un autodestruct si elles sont démontées. Et d'où le prix extrèmement élevé des solutions puisqu'il faut un matos programmé différemment pour chaque déploiement.
 
2e solution : Recourir à une authentification à 2 facteurs type clé+login, rendant la détection des tentatives d'intrusion aisée, puisque on verra un renouvellement de clé abusif toutes les minutes.
 
my 0.15€

C'est effectivement un problème, ceci dit mon idée était de mettre en place l'architecture, avec un algo quelconque en exemple d'intégration. Après, chacun mets l'algo et la seed qu'il veut dans le schmilblick
 
Et oui c'est de toute façon une authentification login+password fixe+token.

Tu va donc avoir pas mal de soucis d'électronique plus que de prog.
Je suis un noob total en électro, mais tu dois pouvoir démerder le truc avec un aficheur lcd + un pic interfacé avec ta source radio de temps + un bouton pour générer ton code. Si tu utilise un simple hachage, il devrait te fournir assez de puissance de calcul.
Dans la catégorie parano, pense à éviter les attaques par source radio pirate + ton boitier qui permettent de remonter (certe avec beaucoup de patience) à l'algo de hachage utilisé.

Voui, mais l'électronique n'est pas le problème pour moi sur un projet comme celui ci (DUT electronique inside). Enfin si, la soudure xD mais bon.
 
Je cherches actuelleemnt:
- Un pic/atmel avec contrôleur de LCD inclus.
- Comment on miniaturise ce recepteur DCF
 
Après, un bouton, les pins pour la programmation, on dessine le schéma, on sort le typon (chiant), on le grave, on le soude (re chiant) et....
 
Et on envoie le programme dedans qui ne devrait pas faire plus de quelques pages (sans compter les libs).

Tiens moi au courant ca m'intéresse beaucoup ton projet, c'est vraiment TRES interessant.

Merci
 
Pour l'instant voilà où j'en suis:
 
- Chips avec LCD Driver integré:  
 
* Chez Atmel on n'aura que du 8 bits, mais du 8 bits sacrément costaud... Beaucoup trop même! Mais on se retrouve du coup avec un LCD Driver de 4*40 xD, 8 canaux de conversion A/D 10 bits, etc etc etc... Et un joli package 64 pins insoudable (ou presque). Par contre on a jusqu'à 64ko de flash.
 
* Chez MicroChip, c'est plus soudable si on descends à 14ko de mémoire. Ca me semble peu :S et pas de programmation in situ... :S

J'ai parcouru rapidement ton message et je me demande pourquoi est ce que tu n'utilise pas le projet "Mobile OTP" (OTP pour One Time Password).
 
Couplé à un serveur Radius comme xTradius c'est pas mal.. Je suis entrain de mettre cela en place pour une société financière de Geneve : utiliser cette technique pour se connecter au m0n0wall, qui lui, s'occupe par la suite d'ouvrir ou non l'acces aux resources distantes..  
 
Cela fonctionne avec ton téléphone portable et un petit soft en java, lequel te génère des OTP à la volée après que tu ai saisi un "code pin" sélectionner par avance. Le script serveur Mobile OTP fonctionne lui aussi parfaitement.  
 
Tu peux trouver un peux plus de doc ici : http://motp.sourceforge.net/
 
Après en effet je ne sais pas si c'est cela que tu recherche mais c'est toujours une piste  
 
 

merci beaucoup du lien Bl@cK !
je cherchais un truc similaire, donc je suivais de pres ce topic