Articles précédents : Articles
- [182] Les députés ratifient les traités OMPI, mais les débats ne font que commencer
- [72] Vente liée : Luc Chatel ne fera rien
- [0] Sortie de Pxxo 5.1
- [96] Les systèmes de fichiers pour disques SSD
- [8] Aidez le Libregraphicsmeeting 2008
- [222] La guerre des formats de bureautique normalisés ISO commence
- [20] La France voterait non à la normalisation d'OOXML
- [42] Suites de l'aventure de la normalisation du format OOXML
- [23] Zend Framework 1.5 : consolidation et disponibilité
- [18] Rôle des états et positions dominantes dans le secteur informatique
Liens connexes
- Liste de diffusion opentoken-devel (218 hits)
- [OATH] Time-based One-time Password Algorithm (211 hits)
- [OATH] OATH Challenge-Response Algorithms (140 hits)
- [OATH] Différentes specs publiées par OATH (161 hits)
Dépêche modérée par
Dépêche éditée par
Articles : OpenToken : un projet de token d'authentification matérielle ouvert
Posté par Amaury (). Modéré le 21 avril 2008.
Tout d'abord, le consortium OATH a publié les spécifications de deux algorithmes permettant de concevoir des tokens matériels :
- Une première spécification publiée courant 2004 concerne les générateurs de mots de passe en mode asynchrone : à chaque appui sur un bouton du token, un nouveau mot de passe est généré ;
- Une deuxième spécification, publiée il y a quelques jours à peine (d'où cette dépêche) traite d'un mode de génération de mots de passe à usage unique dépendant du temps, où chaque mot de passe possède une durée de vie de quelques secondes.
Et justement, le projet OpenToken vise à concevoir des tokens ouverts, ainsi que les outils logiciels associés, en se basant sur la dernière spécification OATH afin de garantir un fonctionnement transparent. Pour l'instant le projet est en cours de lancement et les objectifs sont ambitieux, n'hésitez donc pas à vous abonner à la liste de diffusion opentoken-devel pour contribuer.
Si le concept vous intéresse, ces informations sont présentées plus en détails dans la suite de la dépêche...
![[en]](../../../images/en.png)
Liste de diffusion opentoken-devel (218 hits)-
[OATH] Time-based One-time Password Algorithm (211 hits)
-
[OATH] OATH Challenge-Response Algorithms (140 hits)
-
[OATH] Différentes specs publiées par OATH (161 hits)
> Lire la dépêche (30 commentaires, moyenne: 2,6).
L'accès à un système d'information se déroule traditionnellement en deux temps : on commence par s'identifier ("Je suis Pierre Tramo") et l'on s'authentifie ("Je prouve que je suis bien Pierre Tramo"). Cette authentification peut revêtir plusieurs formes, en fonction du niveau de confiance souhaité, que ce soit pour laché T Koms sur 1 SkyBl0g ou déclarer ses impôts en ligne.
Tout le monde connaît le couple "identifiant + mot de passe". Il est également possible d'imposer la présence d'un certificat (comme pour la télédéclaration des impôts en France), de prélever des données biométriques (empreinte digitale, intonation de la voix), voire de posséder une liste de mots de passe à usage unique sur un support physique.
Comme les exemples ci-dessus l'illustrent, l'authentification peut reposer sur 3 facteurs :
- Quelque-chose que l'on connaît (ex. : un mot de passe) ;
- Quelque-chose que l'on est (ex. : une donnée biométrique) ;
- Ou encore quelque-chose que l'on possède (ex. : un "token").
Le secteur de l'authentification forte par token est traditionnellement occupé par des éditeurs propriétaires qui verrouillent le marché grâce à des secrets de fabrication bien conservés, même si les concepts utilisés sont triviaux. Pour prendre un exemple, les tokens RSA (les plus utilisés au monde) imposent la présence d'un serveur commercialisé par RSA pour être utilisables. Le problème est qu'il n'y a aucune raison technique sérieuse derrière cette dépendance : le fonctionnement interne des tokens est largement connu [PDF] et développer un serveur d'authentification compatible serait aisé. Ce sont principalement des contraintes légales et contractuelles qui empêchent de proposer des alternatives libres.
Forts de ce constat, de nombreux acteurs ont décidé de travailler ensemble pour mettre en place un standard dans ce domaine, à l'exception notable de RSA qui, conscient de sa position de leader, préfère favoriser sa propre technologie propriétaire. Le consortium OATH (initiative for Open AuTHentication) a donc été créé afin de proposer un framework ouvert de référence pour l'authentification et notamment le Single Sign On. Les travaux publiés par OATH peuvent paraître bien abstraits. Ils présentent néanmoins un réel potentiel et contribuent à poser les bases d'un système de gestion d'identité ouvert et indépendant des éditeurs. Après des débuts poussifs courant 2004, l'initiative OATH commence à prendre du poids. Il a quelques jours de cela, un document rédigé par l'OATH a été remis à l'IETF. Ce document décrit une méthode de génération de mots de passe à usage unique, permettant de concevoir des tokens présentant des fonctionnalités identiques aux tokens les plus utilisés (suite de nombres en apparence aléatoires, changeants au fil du temps).
Ce standard pourrait donner naissance à une famille de tokens "ouverts" qui n'auraient pas besoin d'être adossés à un serveur propriétaire pour pouvoir fonctionner.
Beaucoup de chemin reste néanmoins à parcourir : en 2004, un premier draft publié par OATH portant sur une autre méthode de génération de mots de passe à usage unique (indépendante du temps cette fois) avait permis la création de tokens en théorie librement utilisables (puisque l'algorithme de fonctionnement du token est connu), mais liés dans la pratique aux serveurs de l'éditeur, notamment à cause du chiffrement de la clef secrète (seed) stockée dans les tokens, qui empêche de connaître cette clef pour alimenter le serveur d'authentification.
Et c'est dans cette optique qu'un petit groupe de personnes, dont votre serviteur, ont l'intention de monter un projet dont le but serait de concevoir un token complètement ouvert permettant à n'importe qui de disposer d'une solution d'authentification forte qui ne coûterait que le prix des tokens (de quelques euros à quelques dizaines d'euros selon le procédé de fabrication). Il existe aujourd'hui de nombreuses solutions d'authentification forte logicielles open-source (principalement des infrastructures de gestion de clefs, également connues sous le nom de PKI), mais aucune mettant en oeuvre des tokens physiques. Les deux systèmes (PKI et tokens) présentent leurs avantages et inconvénients qui sortent du cadre de cet article. Il n'existe à ce jour et à notre connaissance aucune solution d'authentification matérielle libre. D'autres initiatives liés à l'authentification par token ont été lancées (MyPW loue des tokens à l'unité, Verisign Labs permet d'ajouter une couche d'authentification forte sur OpenID, Paypal commercialise des tokens à bas prix), mais nulle initiative lancée par la communauté, pour la communauté.
Ce projet peut paraître simple en apparence, mais les contraintes sont multiples. Les tokens ne forment que la partie émergée de l'iceberg. En effet, la partie logicielle d'authentification mène très vite aux problématiques, complexes, d'échange sécurisé des clefs secrètes, de "provisionning" et autres domaines touchant à la gestion d'identités, sans compter les contraintes de re-synchronisation des tokens, la coordination avec l'initiative OpenID etc. L'objectif est sans doute ambitieux : produire industriellement des tokens demande une mise de fonds importante. Peut-être serait-il possible de produire des tokens artisanaux dans un premier temps pour valider le concept. Autant le dire tout de suite, le projet est assez casse gueule...
Bref, nous cherchons des gens pour discuter de la faisabilité du projet. Dans un délire d'originalité et après 7 secondes de brainstorming intense, le projet a été (temporairement) nommé OpenToken et une liste de diffusion sur Sourceforge est d'ores et déja disponible : opentoken-devel (chez) lists.sourceforge.net. Si vous y connaissez quelque-chose en authentification forte, en électronique ou si plus généralement le sujet vous intéresse, n'hésitez pas à vous inscrire pour nous faire part de vos idées, forcément géniales (anglais ou français accepté), voire trol^wajoutez un commentaire à cette dépêche, nous sommes preneurs aussi.
Si tout va bien dans quelques années il sera possible d'utiliser une solution entièrement libre pour s'authentifier avec des tokens. Ouais, on peut rêver ! :-)
Comment nous aider
Désolé pour ce long article, j'insiste juste sur un point :
Si vous connaissez des projets similaires, actifs ou morts, si vous connaissez le secteur de l'auth forte, si vous avez un retour d'expérience sur le sujet, si vous pouvez nous mettre en contact avec des fabricants, des éditeurs etc, on est preneur, soit dans les commentaires de la news, soit sur la liste...
-
[^]Re: Comment nous aider
Posté par Nicolas Boulay () le 21/04/2008 à 15:19. (lien). Évalué à 3.Si tu veux lancer une discussion sur linuxfr, il faut l'ouvrir !
Je connais un peu la sécurité et un peu plus l'électronique, mais difficile de commenter quand il n'y a pas de problématique posée.
Qu'elles sont vos difficultés ? Qu'elle forme électronique ont les tokens ? Est-ce des cartes a puce, des clefs usb ou rien a voir ?-
[^]Re: Comment nous aider
Posté par ashram4 () le 22/04/2008 à 12:26. (lien). Évalué à 1.J'ai utilisé à de multiples reprises les Token RSA. Soit c'est un petit boitier (~ 3x5x1 cm) sans connecteurs, ni bouton. Soit une sorte de clef USB ou l'USB ne sert à rien. Sur le Token il y a un écran LCD avec 6 digits qui change toute les 30 secondes. Ce sont ces chiffres qui sont utilisés pour se connecter au VPN de la société. ça ne se recharge pas et il y a une date d'expiration sur le token.
-
[^]Re: Comment nous aider
Posté par Amaury () le 22/04/2008 à 13:06. (lien). Évalué à 1.> Si tu veux lancer une discussion sur linuxfr, il faut l'ouvrir !
J'avais justement l'impression d'ouvrir la discussion.
Nos questions sont super ouvertes : "comment on avance ?" plutôt que "on colle le composant XZR86 ou le 2865NF ?".
Les personnes ayant envie de contribuer au projet sont donc invitées à s'inscrire à la ml...-
[^]Re: Comment nous aider
Posté par Nicolas Boulay () le 22/04/2008 à 14:24. (lien). Évalué à 2.disons que si le sujet est le token, on ne sait pas quel doivent être ses propriétés. Je vois bien le genre de calculette RSA mais est-ce qu'une clef usb avec un seul bouton ne suffirait pas ?
-
[^]Re: Comment nous aider
Posté par Amaury () le 22/04/2008 à 17:26. (lien). Évalué à 1.La dernière spec OATH est "time based", donc on ne parle pas du token calculette mais du token sans bouton, avec juste un écran et une horloge interne.
-
[^]Re: Comment nous aider
Posté par Nicolas Boulay () le 22/04/2008 à 18:11. (lien). Évalué à 3.Et niveau sécurité de l'engin ? Il faut protéger sa source de temps ? Il faut empêcher a tout prix l'accès a la clef prive ?
Par ce que réaliser ce genre de compteur avec un écran, cela représente rien en électronique. (en gros, je sais faire)
Par contre, faire la même chose en protégeant toutes les IOs, c'est une autre paire de manche. (protection de la RTC, utilisation de puce de carte a puce pour planquer la clef, utiliser sans doute un autre uP pour gérer l'affichage, etc...)
J'imagine qu'un truc le moins chére possible mais non sécurisé pourrait amorcer le projet. Déjà si la clef prive dépend du porteur et non du systèmes, il y a moins besoin de sécuriser la calculette contre les attaques hardware (en gros que chaque carte contient une clef différente, cela complique les attaques sur la clef).
-
[^]Re: Comment nous aider
Posté par François BOTTIN () le 22/04/2008 à 23:17. (lien). Évalué à 3.Je ne connais pas trop le domaine, mais je me suis toujours demandé pourquoi ce genre de token n'utilisait qu'un écran pour communiquer ? Je trouve ça plutôt galère de devoir systématiquement recopier un code sur le clavier, d'autant que les utilisateurs de ce genre de token sont souvent sur un portable sans pavé numérique...
N'est-il pas possible de penser à un truc qu'on pourrait brancher par USB sur l'ordinateur ? Bien sûr, copier un code dans une zone de texte fonctionne partout... mais pourquoi ne pas faire passer le token pour un clavier qui balancerait le code suite à l'appui sur un bouton ? Il suffirait juste de mettre le focus sur le bon champ avant d'appuyer sur ledit bouton. Je pense que même Windows est capable de gérer le branchement à chaud d'un clavier USB.-
[^]Re: Comment nous aider
Posté par jcs (page perso, ) le 23/04/2008 à 07:48. (lien). Évalué à 2.mais pourquoi ne pas faire passer le token pour un clavier qui balancerait le code suite à l'appui sur un bouton ?
Outre le fait que techniquement c'est beaucoup plus compliqué (pilotes...), brancher le token sur une machine c'est également s'exposer à un risque si la machine a été compromise : on peut par exemple imaginer un logiciel qui en toute discrétion récupère plusieurs OTP valides, ou qui tout bêtement récupère un OTP valide mais en envoie un invalide faisant croire que le service d'authentification ne fonctionne pas. Et tout ça dans le dos de l'utilisateur.-
[^]Re: Comment nous aider
Posté par François BOTTIN () le 23/04/2008 à 09:05. (lien). Évalué à 4.C'est en effet plus compliqué à développer, mais uniquement du côté matériel. Il n'y a pas besoin de pilote pour un clavier USB générique, enfin je pense. Faire un pseudo clavier qui crache un code lors de l'appui sur un bouton n'implique aucun changement logiciel, à mon avis.
Sinon, concernant le détournement d'un code, il est tout à fait possible de faire la même chose avec un token à écran : si la machine a un cheval de Troie qui prend ce que l'utilisateur a saisi puis fait croire que la saisie n'est pas valide on arrive au même point. Et du point de vue du code malicieux, je pense qu'il est plus intéressant de laisser passer l'étape d'autentification de l'utilisateur puis accéder au ressources protégées ensuite : les codes ont une valeur limitée dans le temps, ça ne sert à rien d'en conserver pour plus tard.
-
[^]Re: Comment nous aider
Posté par Sébastien Koechlin () le 23/04/2008 à 11:37. (lien). Évalué à 3.Je ne vois pas trop la différence avec la saisie avec le clavier d'origine.
On peut imaginer même de supprimer le bouton. Comme l'USB est hotplug; on peut programmer le contrôleur de la clef pour se déclarer comme Clavier HID, et envoyer la séquence 2 secondes après avoir été branché. Ça évite d'avoir une pièce mécanique qui tombe en panne et qui augmente les coûts.-
[^]Re: Comment nous aider
Posté par Nicolas Boulay () le 23/04/2008 à 15:32. (lien). Évalué à 2.L'idée principal est de ne pas pouvoir demander un nouveau mot de passe de façon logiciel.
Il existe des cartes à puces ayant une interface USB, il doit être possible de les utiliser, sauf si elle implémente une norme spécial.
-
-
-
-
-
-
-
-
[^]Re: Comment nous aider
Posté par IsNotGood () le 21/04/2008 à 15:34. (lien). Évalué à 1.> si vous pouvez nous mettre en contact avec des fabricants, des éditeurs etc
Je ne peux pas vous mettre en contact avec des personnes intéressées. Désolé.
Mais, avez-vous regardé du côté des gouvernements, de l'UE, des militaires, etc ?-
[^]Re: Comment nous aider
Posté par Earered () le 21/04/2008 à 19:34. (lien). Évalué à 3.La sphère publique semble plutôt s'orienter vers les certificats (logiciel, carte à puce, clé usb).
Entre autre sur des aspects de chaîne de confiance (vérification de respects des règles de sécurité de l'émetteur de certificats, signature par une autorité de certification).
Mais aussi de signature de fichier, et de chiffrement/confidentialité des données (les aspects que l'auteur de la dépêche n'a pas voulu approfondir à raison pour ne pas alourdir son propos).
Les tokens ont d'autres avantages et inconvénient.
Personnellement, je vois l'aspect consultant nomade utilisant des terminaux chez le client qui doit s'assurer que même si le mot de passe est logger, au moins il ne pourra pas être réutiliser. Ou en cas de vol de portable, que les accès à l'intranet ne soit pas compromis (donc certificat logiciel mort, puce et usb ça réclame du matos particulier sur le portable matériel ou driver, et ne permet pas l'usage de tous les terminaux).
La défense ayant tendance à isoler son intranet (pas d'extranet), les personnes intéressés sont plutôt, enfin je pense, du secteur privé manipulant des données confidentiels, en réseau (gros), avec une pointe d'externalisation (j'ai des noms de 2 clients des safeword de Secure Computing Corporation mais je ne dénoncerais pas :p ).
Mais pour construire une entreprise la dessus (c'est p'tet pas le projet), trouver 3 clients, et leur proposer d'investir pour créer le service ça peut être une bonne idée. (pour la pépinière, je recommande Grenoble, c'est par là qu'on trouve les gens qui conçoivent les circuits et micro-processeur... quoi, comment ça on y est pas encore? allez, hop hop yaplukafaucon! ^_^).-
[^]Re: Comment nous aider
-
-
-
[^]Re: Comment nous aider
Posté par Earered () le 21/04/2008 à 18:59. (lien). Évalué à 4.Réflexion de l'état sur l'authentification forte, et liste de fournisseurs de certificats:
http://www.synergies-publiques.fr/rubrique.php?id_rubrique=1(...)
http://www.telecom.gouv.fr/rubriques-menu/entreprises-econom(...)
C'est orienté carte à puce (France oblige?), donc c'est un peu la "concurrence" mais certaines des réflexions s'appliquent (niveau de confiance, remise de l'objet de la main à la main, etc...).
Coté serveur, il y a peut être déjà tout ce qu'il faut
http://directory.apache.org/
Triplesec en particulier, le module pour générer les tokens proposé sur le site est un logiciel pour PDA/blackberry mais le bébé semble conçu pour fonctionner avec des tokens matériels.
A vu de nez pas de gros problèmes pour que tout ce petit monde s'entende "Programmable mobile device can use any 2-factor auth algorithm to leverage existing investments in FOB hardware" sauf que "Single use HOTP passcodes do not require time synch or phone service", à creuser.
et préparer le business plan (service de configuration, mise en place, intégration de apache directory et vente de tokens, niveau 1 d'identification, et pour plus tard organisation et vérification des papiers d'identité remise en main propre et référence PRISv2?) ^_^
Le problème semble plus s'orienter vers la construction de matériel/électronique non?-
[^]Re: Comment nous aider
Posté par Earered () le 21/04/2008 à 19:11. (lien). Évalué à 2.P.S. pas de fichier à télécharger sur apache, car la migration est récente pour triplesec: l'origine sur safehaus: http://docs.safehaus.org/display/HAUS/Home
N.B. vi, je sais pour le PRIS gros crackage, c'est plus destiné aux certificats, toussa, mais bon, dans l'idée, s'inspirer des recommandations des certificats pour fournir du conseil aux entreprises qui utilise les tokens, ça peut être une idée
-
-
[^]Re: Comment nous aider
Posté par prunille () le 21/04/2008 à 23:57. (lien). Évalué à 2.Salut,
concernant les projets similaires, j'avais regardé triplesec passé de Safehaus à Apache. Il semble cependant être mort. L'idée que je pense la plus intéressante de mon point de vue est de produire un soft et de réutiliser le téléphone mobile : l'authent forte pourrait être libre et gratuite...
concernant le nom, OpenToken est déjà plus que largement utilisé si j'en crois Google. De plus, il l'est pour une spécification déposée (encore en draft) à l'IETF par la société PingIdentity. Ils ont autre chose à faire qu'à vous poursuivre mais personnellement, je verrai bien autre chose comme nom : ToPen par exemple.
pour ce qui est des éditeurs, il en est un auquel je pense : OpenTrust. Ils ont une vraie expertise sur la PKI et les token matériels.
Bon courage.
-
[^]Re: Comment nous aider
Posté par octane () le 22/04/2008 à 14:24. (lien). Évalué à 4.J'ai l'impression qu'il y a un flottement dans le texte entre le one time password et l'authentification forte. Je connais mal les one time password. Je connais mieux les PKI.
Voici mes deux euro-cents sur l'authentification forte et les tokens matériels:
Question: comment garantir de la crypto forte?
-> première sous question: que veut on protéger?
Réponse: 3 grandes familles existent: le chiffrement, la signature, et l'authentification.
Ces trois familles reposent sur le mécanisme de clé privée / clé publique. Ce concept de clé privée /publiques est celui qui nous intéresse ici. Associé aux clés publiques, un certificat qui ajoute des informations comme l'adresse mail du possesseur de la clé publique, des dates de validité, etc..
La clé privée est privée et ne doit être connue que du possesseur de la clé. Le certificat (et la clé publique associée) sont publics, (ie diffusables partout)
Cette crypto est communément appelée PKI, et la PKI correspond à une mise en oeuvre de ces mécanismes. De très nombreuses RFC définissent ce qu'il faut faire pour construire une PKI. Dans le logiciel libre openssl a tout ce qu'il faut pour batir une PKI.
En gros:
-on génére une autorité (un couple de clé et certificat).
-On génére des couples clés privés/publics pour chacun de nos utilisateurs.
-Les certificats sont signés par l'autorité (comprendre authentifiés par l'autorité)
Puis, toute personne qui souhaite utiliser notre PKI doit agréer l'autorité, en gros faire confiance a cette autorité, et par la, faire confiance aux certificats signés par celle ci.
Donc un user peut récuperer un certificat quelquepart, vérifier son authenticité, puis l'utiliser.
Ca, c'est pour la théorie. Je passe les mécanismes de révocation de certificats, de mécanisme permettant l'authent, la signature et le chiffrement.
Bref.
Venons en au point qui nous intéresse, les cartes à puce (ou token USB).
Un point crucial concernant ces PKI concerne la clé privée. Si elle est diffusée, forcément, elle ne sert à rien.
Et survient un paradoxe: comment être persuadé que la clé privée ne fuite jamais dans aucun cas alors qu'il faut l'utiliser?
La solution réside dans l'utilisation d'une carte à puce. Une carte à puce est un ordinateur complet, et donc, la clé privée ne sort jamais de la carte à puce. Toutes les opérations crypto sont réalisées par la carte à puce, depuis le tirage des clés, jusqu'aux opérations de chiffrement/déchiffrement. La clé privée est donc parfaitement protégée, et la carte à puce elle même peut protéger des brute force en détruisant la clé au bout de trois tentatives de code PIN.
C'est donc génial (du point de vue crypto). Mais.
Mais tout n'est pas si évident. Et entre autre vient le point noir de la communication entre un programme local au PC et la carte à puce. Une norme de communication existe et s'appelle la norme PKCS#11. Les constructeurs de carte à puce fournissent donc un middleware (un driver, quoi) permettant de présenter une interface PKCS#11 à un programme du PC. Et ces middleware existent uniquement sous windows. Certains middleware ont existé sous linux (je pense au clés token USB rainbow ikey1000) mais sous la forme de blobs binaires, attachés à une certaine version de noyau.
Bref:
la solution serait effectivement d'implémenter:
-premièrement d'une couche PKCS#11
-deuxièmement du pilote spécifique pour une carte particulière
-troisièmement une couche applicative (un add-on pour openssl ? )
OTP
J'avais regardé à une époque une solution d'OTP, et j'étais tombé sur une applet java http://fatsquirrel.org/software/vejotp/ que j'ai réussi à faire fonctionner sur mon mobile LG8210 à 20€. Ça peut être une solution, utiliser nos mobiles surpuissants pour implémenter l'OATH.
-
[^]Re: OTP
Posté par Amaury () le 21/04/2008 à 15:35. (lien). Évalué à 2.> Ça peut être une solution, utiliser nos mobiles surpuissants pour
> implémenter l'OATH.
Oui et non.
Oui car en effet c'est possible techniquement, comme d'ailleurs on peut le faire sur un PC, un PDA ou tout autre matériel avec suffisamment de puissance de calcul...
Non car tout le principe du token matériel repose sur la nécessité de posséder le bidule : le token doit être suffisamment sécurisé pour qu'on ne puisse pas récupérer la clef secrète de manière triviale (perturbations, démontage...).
Si tu peux installer le logiciel de génération de mot de passes dessus, tu peux très probablement installer un keylogger qui enregistrera les mots de passe, voire te choper un virus ou un trojan qui récupérera la clef secrète et l'enverra ailleurs (clef secrète compromise = n'importe qui peut prévoir les mots de passe à venir). Une solution logicielle sur un outil communiquant ne présente pas du tout le même niveau de sécurité qu'un token physique dédié, machine "autiste" sans possibilité de communication autre que le fait d'afficher les mots de passe générés.
Un PC / PDA / téléphone avec un soft qui tourne dessus s'apparente donc plus à du "quelque-chose que je connais" que "quelque-chose que je possède". Et ce n'est pas vraiment de l'authentification forte, quoi qu'en disent les vendeurs.
La solution serait éventuellement d'avoir une carte matérielle dans le téléphone ou le PC, chargée d'effectuer les calculs, mais même là les possibiltés d'interception sont importantes.
Au final, rien ne vaut le bon vieux token (ou la feuille de papier avec 50 mots de passe à usage unique).-
[^]Re: OTP
Posté par briaeros007 () le 21/04/2008 à 17:17. (lien). Évalué à 2.La solution serait éventuellement d'avoir une carte matérielle dans le téléphone ou le PC, chargée d'effectuer les calculs, mais même là les possibiltés d'interception sont importantes.
Ca s'apelle la carte SIM, et normalement, une partie doit être protégé des agressions physiques (ie essayer de récupérer physiquement la valeur d'un registre).--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: OTP
Posté par Earered () le 21/04/2008 à 19:40. (lien). Évalué à 3.>sans possibilité de communication autre que le fait d'afficher les mots de passe générés
Ou les prononcer? (je pense aux aveugles qui seraient excluent des procédures / accès sécurisé de l'entreprise si une version avec casque audio n'est pas inventé.).
P.S. une idée pour les sourds et aveugles?-
[^]Re: OTP
Posté par Jeff_ (Jabber id, ) le 21/04/2008 à 21:36. (lien). Évalué à 2.le sourd et aveugle en général il communique pas vraiment autrement qu'en direct...ou, au mieux, en braille... braille qui serait d'ailleurs beaucoup plus pertinent qu'un casque audio amha
--
"L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]-
[^]Re: OTP
Posté par Earered () le 22/04/2008 à 02:09. (lien). Évalué à 4.Pour le braille, je mettrais un bémol quant à sa pertinence.
Pour les aveugles de naissance, je suppose que c'est plus pratique (et n'est pas exclusif, l'audio est un plus: prix d'un PC + gutemberg project vs livres en braille. J'ai plusieurs fois vu des aveugles avec PC dans le TGV donc je pense qu'il y a un intérêt).
Mais on ne nait pas forcément aveugle, et l'apprentissage d'un nouvel alphabet/méthode de lecture à 80 ans n'est pas forcément ce qu'il y a de plus évident (ma grand mère avait essayé). D'ou bémol.-
[^]Re: OTP
Posté par Jeff_ (Jabber id, ) le 22/04/2008 à 13:11. (lien). Évalué à 2.je parlais du braille car la parole est souvent problématique certaines lettres ressemblent phonétiquement à d'autres ou, dans certaines langues, n'ont pas de nom du tout (je sais plus lesquelles ni en quelles langues mais je sais qu'il y en a... j'ai un trou là), problème de traduction, de prononciation d'une variante à l'autre etc... le braille permettrait de s'affranchir de tout cela ... d'où, pour moi, une meilleure pertinence...
--
"L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]-
[^]Re: OTP
Posté par palm123 (page perso, ) le 22/04/2008 à 13:44. (lien). Évalué à 3.>>>la parole est souvent problématique certaines lettres ressemblent phonétiquement à d'autres ou, dans certaines langues
Oui, le F et le S, par téléphone, c'est une catastrophe. J'ai travaillé dans un centre de support et vite pris l'habitude de dire F comme France, S comme Sierra...
En japonais, le R et le L sont proches.
Il y a un petit livre sur le japonais avec un joli dessin sur la couverture, 2 personnes se téléphonent
- avec un L comme dans Roma ?
- non, avec un R comme dans London--
Les logiciels libres ne sont pas à la portée des non-spécialistes, dit Microsoft. Si même un gendarme ou un député est capable de se servir d'un PC sous Gnu/Linux...-
[^]Re: OTP
Posté par Pierre Jarillon (page perso, ) le 22/04/2008 à 14:35. (lien). Évalué à 2.En japonais, le R et le L sont proches.
Ce n'est pas la peine d'aller chercher très loin, le basque a deux sons R :
- le R doux quand il est entre 2 voyelles (ex: hari = fil), c'est presque un L.
- le R dur dans les autres cas (ex: harri = pierre).
Un peu plus loin, il y a les antillais qui ne p'ononcent pas les è'. Un jour, j'ai demandé à un copain antillais qui avait ce type d'élocution de me prononcer "J'ai vu trois gros rats gris dans trois gros trous creux". Aussitôt il m'a répété la phrase aussi parfaitement que le ferait Audrey Pulvar au journal télévisé. Très étonné, je lui dis "Tu sais donc prononcer les R ?" et il m'a répondu "Oui je sais pa'ler en p'ononçant les è', mais ça me fatigue".
Il n'y donc pas une façon unique de présenter un mot de passe, l'écran LCD, la voix et la planchette braille sont forcément complémentaires.
-
-
-
-
-
-
-
[^]Re: OTP
Posté par jcs (page perso, ) le 21/04/2008 à 15:41. (lien). Évalué à 2.Il y a 2 ans environ j'ai écrit une implémentation de OATH sur mon téléphone portable ainsi qu'un module PAM utilisant une authentification OATH pour me connecter en SSH chez moi.
Cela fonctionnait pas trop mal sauf que la clé (le secret partagé) étaient stocké en clair dans mon téléphone. Une solution consiterait à le stocker dans la SIM mais je doute qu'on puisse y avoir facilement accès depuis les API disponibles au niveau du téléphone. Une autre possibilité serait de stocker une version chiffrée du secret puis de demander à l'utilisateur un mot de passe. Toutefois sur un clavier de téléphone portable c'est pas très ergonomique.-
[^]Re: OTP
Posté par Nicolas Boulay () le 21/04/2008 à 15:50. (lien). Évalué à 3.Il n'y a pas toujours besoin d'avoir une implémentation super forte. Et c'est toujours utile d'avoir des implémentations de références.
De plus, certain téléphone ont des fonctionnalités proche de celle des cartes a puces.
-
Cette page a été générée par Templeet en 0.1289s (dont 0.0148 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.