Larry Cow a écrit 5011 commentaires

Masochiste!

En fait, je me suis posé la question. Dois-je spécifier que c'est un fork, ou pas ?

Je pense vraiment que oui. Ce n'est pas forcément facile, mais il vaut mieux être honnête que de risquer de susciter à chaque news un "mais c'est un fork, en fait, non?". C'est effectivement une caractéristique importante de Tryton, même si elle est à double tranchant, et la passer sous silence risque AMHA de vous desservir.

Boh, ça dépend. Je pourrais boire des verres avec tout le monde chez tiny je pense. Il y a des divergences sur le business-model et sur le plan technique, mais pas de rancunes/rancœurs je pense.

Ok. Il m'avait semblé lire des choses assez dures de part et d'autre, à l'époque. Si ça va mieux, tant mieux :)

Le problème, c'est qu'il faut aussi forker Théo, pour que ça soit efficace. Et quelque-chose me dit qu'il ne se laissera pas faire si facilement ;)

Le problème, c'est qu'il faut aussi forker Théo, pour que ça soit efficace. Et quelque-chose me dit qu'il ne se laissera pas faire si facilement ;)

C'est un fork, et l'ambiance n'est pas au beau fixe entre les deux équipes, manifestement.

Ceci dit, même si je conçois que la situation est tendue, les news sur Tryton pourraient gagner en clarté si elles indiquaient explicitement la parenté du soft.

Toute cette histoire m'a redonné envie de voir ce qui se passe chez Yubico. Et effectivement, ils ont un peu amélioré la donne.

Leurs dernières clés (Firmware 2.2) conservent l'actuel mécanisme d'OTP (One-Time Password), avec l'inconvénient que j'ai cité plus haut, par défaut. Sachant toutefois que, pour être tout à fait honnête, il existe des moyens limiter l'impact du vol d'une liste d'OTP "neufs" - en échange d'une procédure un peu plus lourde pour l'utilisateur - en prenant en compte le temps écoulé entre deux OTP. Chercher l'implémentation de "timedelta" pour Yubikey pour plus de détails.

Mais surtout, ils ont ajouté un nouveau mécanisme, optionnel, à base de challenge/response. Avantage : ça coupe complètement l'herbe sous le pied de l'attaque précédemment citée (puisque l'on ne peut plus générer de codes à l'avance). Inconvénient : ce n'est plus transparent pour la plateforme, il faut un bout de soft pour dialoguer avec la clé.

Leurs clés restent capables de stocker deux méthodes d'authentification (la seconde étant obtenue en pressant le bouton plus longtemps qu'avec la première), ce qui permet de mixer les deux.

Au final, même s'ils ne jouent pas forcément dans la cour des grands, ils ont une approche séduisante quand même.

Lequel, d'état?

Sérieusement, c'est un peu décourageant de se voir toujours proposer des canaux IRC pour ce genre de choses. C'est mieux que rien (ou qu'un forum moisi), mais on est au 21è siècle. Les MUC Jabber, c'est pas fait pour les chients.

Et pour ceux qui veulent retrouver la même simplicité d'utilisation qu'avec irssi, il y a poezio.

Alors oui, et non. Yubikey c'est très joli, mais c'est tellement facile à "piquer" que ça n'est prévu que pour être utilisé en "complément" dans une authentification multifacteur.

La Yubikey - sauf si leur procédé a radicalement changé depuis la dernière fois que j'ai regardé - est assez astucieuse : elle se fait effectivement passer pour un clavier afin d'éviter toutes les problématiques liées à la plateforme. Tout le monde sait gérer un clavier USB. Elle génère des numéros uniques, vérifiables par un tiers (on pouvait même installer son propre serveur de vérification, à l'époque) et à usage unique.

Pour ce faire, elle stocke dedans de elle :

• une clé (crypto) de base qui, liée au serveur de vérification, saura affirmer que tel code vient de telle clé (physique)
• un numéro de séquence, incrémenté à chaque génération.

A chaque authentification réussie, le serveur met son numéro de séquence en phase avec celui de la clé. Et ainsi, il peut refuser toutes les clés générées avec un numéro antérieur. Ce qui évite la réutilisation.

Le GROS hic de Yubikey (ils en sont conscient, c'est pour ça qu'elle est généralement recommandée en complément), c'est que rien n'oblige mes numéros de séquence à être contiguës - sinon la moindre génération de code "pour rien" foutrait le souk. Donc rien n'empêche un attaquant de me subtiliser ma clé quelques secondes, de générer une flopée de codes sur son poste (genre dans un fichier texte), et tant que je n'aurais pas généré ET validé un nouveau code les siens seront parfaitement valides.

Alors oui, pour sécuriser un accès peu critique sans avoir à taper son mot de passe, c'est assez cool. Pour renforcer une authentification à plusieurs facteurs, c'est très bien aussi. Mais j'aurais pas envie que ça suffise à accéder à ma banque...

Si tu veux savoir s'il est possible de porter Meego là-dessus, je dirais "probablement", vu que tu as les plein pouvoirs et que Meego est libre.

Par contre, je n'ai pas eu vent d'un tel portage, et je serais très surpris (agréablement, hein) de son existence.

Si j'en crois les specs, il supporte clairement la 3G (le contraire serait suicidaire) :

    Quad-band GSM / GPRS / EDGE (850/900/1800/1900MHz)
    Dual-band UMTS/HSPA (850/2100Mhz)

Par contre, il ne gère pas la 3G dans la bande de 900MHz, qui est parfois utilisé en France (au moins par Orange dans ma cambrousse).

Ou passer à SNI, qui permet du VirtualHosting basé sur les noms même en SSL.

Et, d'après GP, ils sont le seul concepteur d'androphones européens.

Où tu as vu que c'était une initiative gouvernementale?

on pourrait trouver un mode d'authentification plus sécurisé quand même

Oh oui, je vois ça d'ici. On nous fournirait un "token" physique, bouffant un port USB et dépendant de pilotes uniquement disponibles pour Windows 7. Les pilotes installeraient aussi 350Mo d'une runtime maison, et d'interfaces graphiques diversement liées à l'application.

Il existerait bien entendu une version Mac alternative, coutant une quarantaine d'euro.

Une version beta Linux serait disponible, en cherchant bien. Elle ne tournerait que sur les systèmes Ubuntu 8.04 32 bits, et à condition de désinstaller les locales UTF8.

Finalement, j'aime autant les mots de passe...

Testé vite fait hier soir. Plusieurs remarques :

• l'interface est très sympa, et marche bien
• le concept est intéressant, mais si ça n'intègre pas de fonctions de partage entre utilisateurs ça manque d'intérêt par rapport à un Zeya (si c'est pour écouter juste ma musique, je peux lancer le service directement sur la machine où elle se trouve, ça va plus vite). Et si ça intègre des fonctions de partage, ça va en faire tousser quelques-uns en haut lieu.
• l'installation est relativement simple (pour du Node.js), mais un peu aléatoire. Sur deux Debian Squeeze, j'en ai eu une qui a très bien marché, et l'autre qui n'a rien voulu entendre (même procédure que sur l'autre, mais il m'annonce qu'il ne trouve pas le module 'connect' quand je lance server.js).
• lors de l'upload de fichiers, ce serait plus logique d'afficher la liste d'attente par ordre antéchronologique (les plus récents en premier). Ca éviterait de devoir descendre tout en bas de la fenêtre pour vérifier que tout y est, puis de remonter sur la cible du glisser-déposer pour continuer.
• ce peut être lié à ma version de TagLib, mais il me refuse systématiquement les fichiers qui ont des caractères accentués dans leur ID3.

C'est précisément ce à quoi HSTS répond, si j'ai tout suivi. Avec ta technique, le navigateur se connecte en non-sécurisé, et se voit répondre - par ce biais non-sécurisé - que la vraie ressource est à l'adresse suivante et sécurisée.

Le problème, c'est que - ton flux initial étant non-sécurisé - quelqu'un peut faire du MITM dessus. Et, au lieu de balancer le 301 vers la version sécurisée, faire un 301 vers un serveur tiers en HTTP (ou avec un certificat valide) qui se chargera de se faire passer pour le serveur HTTPS originel.

HSTS permet d'éviter cette étape (sauf pour la première connexion), et de faire en sorte que le navigateur aille de lui-même taper sur la ressource HTTPS sans prendre le risque de demander les coordonnées de ce dernier à chaque fois sur un canal non-fiable.

On l'a tous faite, celle-là, de rêver en code. Généralement après une période de développement intense, lorsque la pression retombe (et qu'on peut enfin re-dormir, aussi).

J'ai déjà eu ça avec la musique/solfège aussi, alors que je suis loin d'en être un acharné.

Ceci dit je ne comprends pas comment ça peut être implémenté via matlab et être disponible sous trois OS.

D'après le Wiki, ça dépend de Matlab pour l'instant (Matlab tourne sous Linux), mais c'est en cours de portage sur Octave.

C'est triste, ton avis sur le comique de répétition.

Il y a plein de fournisseurs à installer, oui. L'ennui c'est que c'est un peu la jungle pour s'y retrouver : entre ceux qui gèrent correctement OpenID 2.0 et ceux qui pas, ceux qui gèrent les AX, ceux qui gèrent SReg, etc...

C'est "openidenabled" qui avait l'air de faire autorité sur les implémentations de référence, mais ils ont l'air d'avoir arrêté (pour se recentrer sur leur offre payante?)

Stackoverflow permet d'ailleurs une double authentification, enfin je crois. A moins que je ne confonde avec Bitbucket.

Identi.ca le proposait aussi je crois. Mais c'est un peu le souci : il a manqué une charte des bonnes conduites pour les trois "parties" de l'OpenID (le fournisseur d'identité, le consommateur d'identité et l'utilisateur).

Pour la faute, je plaide coupable, je la fais régulièrement celle-là.

Oui et non. OpenID, ça ne lave pas plus blanc. On n'a jamais vendu ça comme une techno empêchant les fournisseurs de fermer/changer d'avis. Au contraire, on l'a même présentée comme étant une techno qui permettait de choisir un fournisseur plus proche de soi, qui corresponde mieux à ses besoins, etc.

Donc ça implique deux choses :

• un mauvais choix de fournisseur reste un mauvais choix, c'est comme choisir un mauvais fournisseur d'email. Le jour où il dégage ta boîte tu restes le bec dans l'eau.
• les consommateurs d'OpenID (par opposition aux fournisseurs) auraient du (et certains l'ont fait) proposer aux utilisateurs de déclarer plusieurs moyens d'authentification (OpenID ou autre) pour pallier à la défection de l'un d'entre eux.

Ceci étant, c'est clair qu'il y a de quoi être déçu : la sauce OpenID n'a pas vraiment pris. Trop de gens n'ont pas joué le jeu (notamment du côté des fournisseurs). Maintenant, on peut soit le déplorer et déployer FacebookConnect, soit s'appuyer sur ce qui existe déjà pour faire avancer le schmillblick.

Comme je l'écrivais récemment (et ailleurs) le couple OpenID/WebFinger est séduisant. Il permet de faire mieux passer la pilule auprès du grand public que la traditionnelle "URL" que trop de gens n'ont pas comprise.

Enfin, si la possibilité de s'authentifier via WebFinger voyait le jour, j'adorerais pouvoir lier ça avec un compte IMAP. Il ne faudrait pas forcément grand chose, un rien de PHP (ou autre) à proposer aux fournisseurs de messagerie et qui t'authentifie avec ton mot de passe email. Comme ça, la marche serait moins haute.

Sauf qu'à la différence de cette dernière, la Transnistrie n'est pas reconnue par grand monde.

Le commentaire en question a l'air assez aigri, et franchement typique du "je râle mais refuse de m'impliquer".