Merci pour la dépêche. Pour l'instant je fais du LXC avec des scripts maison sur du Btrfs pour gérer les snapshots et je voulais essayer docker qui a l'air plus robuste. Il y a un truc que je n'arrive pas bien à comprendre avec docker, c'est le statut des containers vis à vis du système de snapshot.
Par exemple, le Dockerfile donné en exemple plante au milieu (à la ligne RUN mysql…). Résultat je me retrouve avec 11 nouveaux containers (docker ps -a). Ils correspondent donc à un snapshot après chaque commande du Dockerfile ? J'en fait quoi ? Ils vont m'être inutiles. Je sais qu'ils ne consomment presque pas de place mais si ils continuent à s'empiler, je vais avoir du mal à retrouver ceux qui me sont utiles.
L'autre truc c'est le Dockerfile donné ne contient aucun ENTRYPOINT. Cela veut-il dire que pour lancer le container crée, il faudra que j'indique à chaque fois le script start.sh ?
Les points de mon graphe sont la valeur médiane de 78 différences de temps de parcours. Si quelqu'un aime faire des stats, il peut rejouer mon script et voir si la tendance est significative.
J'ai regardé le code source et il est très facile de rajouter un backend. C'est ce que j'ai fait pour rajouter la gestion des serveurs CardDAV. Par contre, cet accès est assez long et il n'est pas envisageable de recharger un carnet d'adresse complet à chaque démarrage. Il faudrait donc que je rajoute un cache. As-tu une préférence sur la localisation et le format de ce cache ?
Quelque chose de bizarre: lorsque je lance gBirthday, la méthode parse() de mon nouveau backend est appelé 2 fois. Une idée de la raison ?
Comment s'est passé l'utilisation de Bootstrap avec Django ? Mon expérience est qu'il faut ré-écrire tous les formulaires car on ne peut plus utiliser la mise en forme automatique de Django.
1- Le serveur n'a pas vocation à être ouvert sur l'extérieur. Il écoute soit sur localhost soit sur une interface interne et filtrée.
2- Pour être honnête, je ne me rappelle plus exactement, mais je doute avoir utilisé quelque chose de très compliqué. Après vérification, c'est bien du REQ/REP. Je regarderai le guide pour améliorer ça.
3- Ça me dit quelque chose mais je ne l'ai pas implémenté. Je vais l'ajouter.
Le bémol de la solution RSA c'est que tu dois faire confiance à une société américaine pour garder ses secrets et l'histoire récente a prouvé qu'il est possible de leur voler les graines secrètes stockées dans toutes les clés qu'ils ont vendu. Si tu ne travailles pas dans un secteur sensible ça ne doit pas faire beaucoup de différence. Ce qui me plait dans les Yubikeys c'est que l'algorithme est ouvert et que c'est toi qui choisi le secret stocké dans la clé.
Voilà voilà la réponse : Dans la clé il y a un compteur (en fait 2) qui s'incrémente après chaque génération de de jeton. Si quelqu'un te pique ta clé pour stocker quelques jetons, il pourra les utiliser tant que tu ne t'es pas connecté avec. Le serveur n'accepte que des jetons avec un compteur supérieur au login précédant.
Tu pourrais aussi rajouter des protections pour bloquer la clé si tu détectes des sauts importants dans le compteur, ce qui serait une indication qu'une quantité importante de jetons ont été générés sans être utilisés.
La dernière parade vient du deuxième compteur qui est lié à une horloge. Cette horloge ne fonctionne que lorsque la clé est alimentée. Cela permet de demander régulièrement (ou avant une opération importante) des jetons et de s'assurer que le timing est correct. Si c'est bien implémenté, l'attaquant ne sachant pas à quel timing s'attendre, ne peut pas générer a priori les jetons correctement.
La différence avec une clé SSH est que celle-ci se retrouve à un moment ou un autre en clair dans ton PC. Tu serais donc plus que réticent à l'utiliser dans un cyber-café nigérien. Avec le Yubikey, on ne peut pas accéder à la clé secrète stockée et les jetons ne sont générés que lors d'une intervention physique (pas possible que l'ordinateur demande par lui-même un jeton). Tu dois donc pouvoir l'utiliser sur l'ordinateur d'une auberge de jeunesse en Russie sans craindre de voir tes codes d'accès dans la nature.
Tout cela pour dire que ces clés doivent être utilisées en plus d'un mot de passe traditionnel. Un vilain méchant aurait donc besoin de récupérer ton mot de passe (keylogger ou autre) et de t'emprunter physiquement ta clé.
Pour révoquer une Yubikey, il faut la désactiver dans la base sqlite du serveur. Ça se fait en une ligne de commande. Si tu retrouves ta clé par la suite, tu peux la réinitialiser et importer ses nouveaux paramètres dans la base.
L'intérêt des Yubikeys est que tu peux les réinitialiser en leur fournissant une nouvelle clé AES, ce qui remet tous les compteurs internes à 0. Par contre, une fois initialisée, tu ne peux pas lire la clé secrète AES ni les compteurs.
Avec la solution que je propose, c'est toi qui fait le choix de la façon dont tu authentifies les utilisateurs. C'est géré par la bibliothèque PAM. Tu peux décider de n'utiliser que la yubikey, que le mot de passe ou (l'un OU l'autre). C'est à toi de choisir ta politique, mon module ne fait que dire OK ou ERROR quand on lui présente un jeton associé à un user.
Comme je l'ai dit plus haut, je ne suis pas un spécialiste de sécurité informatique mais en général, on définit une authentification forte par le fait de fournir au moins 2 des éléments suivants:
Ce que tu sais (mot de passe)
Ce que tu as (jeton OTP)
Ce que tu es (biométrie)
Si tu n'utilises que la yubikey, tu ne t'authentifies qu'avec un seul facteur et cela n'a pas beaucoup plus d'intérêt qu'une authentification par mot de passe. En gros, ça ne te protège pas contre le vol de ta clé.
La clef n'utilise qu'un sous-ensemble de touches qui ne changent pas d'un clavier classique à un autre: fricenvgjdbuthkh. Cela marche bien pour les configurations latines occidentales mais pas du tout pour les configurations cyrilliques, asiatiques ou les variantes exotiques du style Dvorak ou Bepo. Par contre une ligne dans ton xorg.conf permet de lié une disposition classique à la clef.
C'est une bibliothèque permettant de faire passer des messages entre différents programmes. Il y a plein de façon de le faire (request-reply, publsih-subscribe…) au travers différent média (IPC, TCP…). Au final ça te permet de gérer simplement les communications entre différents programmes.
Non, ce que je nomme le client est un programme lié à un service qui nécessite une authentification. C'est par exemple le serveur web Apache ou la bibliothèque PAM. Sur la machine locale où la Yubikey est branchée, celle-ci est vue comme un clavier et fournit juste une chaîne de caractère : le jeton OTP.
En pratique quand tu fais ssh serveur, tu as une première demande de mot de passe. À ce moment tu effleure la Yubikey qui tape le jeton pour toi. Ensuite, ssh te demande un deuxième mot de passe et tu dois taper normalement ton mot de passe classique.
1/ C'est effectivement simple mais autant utiliser une bibliothèque qui fait les choses bien. En plus ZeroMQ est légère et rapide. Je réinvente déjà la roue en écrivant un serveur d'authentification Yubikey, je ne vais pas en plus m'ennuyer à écrire un nouveau protocole. Et puis ça facilite l'écriture des clients : ZeroMQ fournit des bindings pour plein de langages différents : http://www.zeromq.org/bindings:_start.
2/ Parce que ZeroMQ est bien plus simple et léger que AMQP.
# RGPD / CNIL
Posté par Antoine . En réponse au journal Rappel que les préfixes IPv6 d’Orange ne sont pas fixes. Évalué à 2.
A priori, l'IP non-fixe est une recommandation de la CNIL pour être en accord avec le RGPD.
Source: https://lafibre.info/orange-les-news/ip-fixe-orange-55180/
[^] # Re: Bug et interrogation
Posté par Antoine . En réponse à la dépêche Docker : Tutoriel pour manipuler les conteneurs. Évalué à 1.
Merci, ça j'arrive à le faire. Ce que je ne comprends pas c'est pourquoi je me retrouve avec 11 containers alors que j'essaye d'en créer 1.
Du coup je ne comprend pas la différence entre CMD et ENTRYPOINT.
# Bug et interrogation
Posté par Antoine . En réponse à la dépêche Docker : Tutoriel pour manipuler les conteneurs. Évalué à 3.
Merci pour la dépêche. Pour l'instant je fais du LXC avec des scripts maison sur du Btrfs pour gérer les snapshots et je voulais essayer docker qui a l'air plus robuste. Il y a un truc que je n'arrive pas bien à comprendre avec docker, c'est le statut des containers vis à vis du système de snapshot.
Par exemple, le Dockerfile donné en exemple plante au milieu (à la ligne RUN mysql…). Résultat je me retrouve avec 11 nouveaux containers (docker ps -a). Ils correspondent donc à un snapshot après chaque commande du Dockerfile ? J'en fait quoi ? Ils vont m'être inutiles. Je sais qu'ils ne consomment presque pas de place mais si ils continuent à s'empiler, je vais avoir du mal à retrouver ceux qui me sont utiles.
L'autre truc c'est le Dockerfile donné ne contient aucun ENTRYPOINT. Cela veut-il dire que pour lancer le container crée, il faudra que j'indique à chaque fois le script start.sh ?
# Les grands esprits se rencontrent
Posté par Antoine . En réponse au journal Le tourbillon mystérieux des mondiaux de natation. Évalué à 10.
J'ai fait la même analyse mais sur toutes les finales (sauf les 50 m, les 4 nages et les relais). On arrive à des résultats comparables :
Mon script python très moche est disponible ici : https://gist.github.com/anonymous/6152064
Pour le faire tourner il faut récupérer le fichier XML contenant tous les résultats, disponible là : http://www.omegatiming.com/Competition?id=00010D0201FFFFFFFFFFFFFFFFFFFFFF&sport=AQ&year=2013
Les points de mon graphe sont la valeur médiane de 78 différences de temps de parcours. Si quelqu'un aime faire des stats, il peut rejouer mon script et voir si la tendance est significative.
Bonne nuit.
# CardDAV
Posté par Antoine . En réponse au journal Sortie de gbirthday 0.6.6. Évalué à 4.
J'ai regardé le code source et il est très facile de rajouter un backend. C'est ce que j'ai fait pour rajouter la gestion des serveurs CardDAV. Par contre, cet accès est assez long et il n'est pas envisageable de recharger un carnet d'adresse complet à chaque démarrage. Il faudrait donc que je rajoute un cache. As-tu une préférence sur la localisation et le format de ce cache ?
Quelque chose de bizarre: lorsque je lance gBirthday, la méthode parse() de mon nouveau backend est appelé 2 fois. Une idée de la raison ?
# Django et Bootstrap
Posté par Antoine . En réponse à la dépêche Sortie de Modoboa 0.9. Évalué à 1.
Comment s'est passé l'utilisation de Bootstrap avec Django ? Mon expérience est qu'il faut ré-écrire tous les formulaires car on ne peut plus utiliser la mise en forme automatique de Django.
[^] # Re: Problèmes potentiels avec zmq
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 3.
1- Le serveur n'a pas vocation à être ouvert sur l'extérieur. Il écoute soit sur localhost soit sur une interface interne et filtrée.
2- Pour être honnête, je ne me rappelle plus exactement, mais je doute avoir utilisé quelque chose de très compliqué. Après vérification, c'est bien du REQ/REP. Je regarderai le guide pour améliorer ça.
3- Ça me dit quelque chose mais je ne l'ai pas implémenté. Je vais l'ajouter.
Merci pour ces commentaires constructifs.
[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 3.
Le bémol de la solution RSA c'est que tu dois faire confiance à une société américaine pour garder ses secrets et l'histoire récente a prouvé qu'il est possible de leur voler les graines secrètes stockées dans toutes les clés qu'ils ont vendu. Si tu ne travailles pas dans un secteur sensible ça ne doit pas faire beaucoup de différence. Ce qui me plait dans les Yubikeys c'est que l'algorithme est ouvert et que c'est toi qui choisi le secret stocké dans la clé.
[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 4.
Voilà voilà la réponse : Dans la clé il y a un compteur (en fait 2) qui s'incrémente après chaque génération de de jeton. Si quelqu'un te pique ta clé pour stocker quelques jetons, il pourra les utiliser tant que tu ne t'es pas connecté avec. Le serveur n'accepte que des jetons avec un compteur supérieur au login précédant.
Tu pourrais aussi rajouter des protections pour bloquer la clé si tu détectes des sauts importants dans le compteur, ce qui serait une indication qu'une quantité importante de jetons ont été générés sans être utilisés.
La dernière parade vient du deuxième compteur qui est lié à une horloge. Cette horloge ne fonctionne que lorsque la clé est alimentée. Cela permet de demander régulièrement (ou avant une opération importante) des jetons et de s'assurer que le timing est correct. Si c'est bien implémenté, l'attaquant ne sachant pas à quel timing s'attendre, ne peut pas générer a priori les jetons correctement.
La différence avec une clé SSH est que celle-ci se retrouve à un moment ou un autre en clair dans ton PC. Tu serais donc plus que réticent à l'utiliser dans un cyber-café nigérien. Avec le Yubikey, on ne peut pas accéder à la clé secrète stockée et les jetons ne sont générés que lors d'une intervention physique (pas possible que l'ordinateur demande par lui-même un jeton). Tu dois donc pouvoir l'utiliser sur l'ordinateur d'une auberge de jeunesse en Russie sans craindre de voir tes codes d'accès dans la nature.
Tout cela pour dire que ces clés doivent être utilisées en plus d'un mot de passe traditionnel. Un vilain méchant aurait donc besoin de récupérer ton mot de passe (keylogger ou autre) et de t'emprunter physiquement ta clé.
[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 2.
Pour révoquer une Yubikey, il faut la désactiver dans la base sqlite du serveur. Ça se fait en une ligne de commande. Si tu retrouves ta clé par la suite, tu peux la réinitialiser et importer ses nouveaux paramètres dans la base.
L'intérêt des Yubikeys est que tu peux les réinitialiser en leur fournissant une nouvelle clé AES, ce qui remet tous les compteurs internes à 0. Par contre, une fois initialisée, tu ne peux pas lire la clé secrète AES ni les compteurs.
[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 3.
Avec la solution que je propose, c'est toi qui fait le choix de la façon dont tu authentifies les utilisateurs. C'est géré par la bibliothèque PAM. Tu peux décider de n'utiliser que la yubikey, que le mot de passe ou (l'un OU l'autre). C'est à toi de choisir ta politique, mon module ne fait que dire OK ou ERROR quand on lui présente un jeton associé à un user.
[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 2.
Comme je l'ai dit plus haut, je ne suis pas un spécialiste de sécurité informatique mais en général, on définit une authentification forte par le fait de fournir au moins 2 des éléments suivants:
Si tu n'utilises que la yubikey, tu ne t'authentifies qu'avec un seul facteur et cela n'a pas beaucoup plus d'intérêt qu'une authentification par mot de passe. En gros, ça ne te protège pas contre le vol de ta clé.
[^] # Re: Question de quelqu'un qui ne connait pas le truc
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 3.
La clef n'utilise qu'un sous-ensemble de touches qui ne changent pas d'un clavier classique à un autre:
fricenvgjdbuthkh. Cela marche bien pour les configurations latines occidentales mais pas du tout pour les configurations cyrilliques, asiatiques ou les variantes exotiques du style Dvorak ou Bepo. Par contre une ligne dans tonxorg.confpermet de lié une disposition classique à la clef.[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 6.
C'est une bibliothèque permettant de faire passer des messages entre différents programmes. Il y a plein de façon de le faire (request-reply, publsih-subscribe…) au travers différent média (IPC, TCP…). Au final ça te permet de gérer simplement les communications entre différents programmes.
Deux liens:
* http://en.wikipedia.org/wiki/ØMQ
* http://nichol.as/zeromq-an-introduction
[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 2.
Non, ce que je nomme le client est un programme lié à un service qui nécessite une authentification. C'est par exemple le serveur web Apache ou la bibliothèque PAM. Sur la machine locale où la Yubikey est branchée, celle-ci est vue comme un clavier et fournit juste une chaîne de caractère : le jeton OTP.
En pratique quand tu fais
ssh serveur, tu as une première demande de mot de passe. À ce moment tu effleure la Yubikey qui tape le jeton pour toi. Ensuite, ssh te demande un deuxième mot de passe et tu dois taper normalement ton mot de passe classique.[^] # Re: ZeroMQ
Posté par Antoine . En réponse au journal Solution d'authentification par mot de passe unique. Évalué à 3.
1/ C'est effectivement simple mais autant utiliser une bibliothèque qui fait les choses bien. En plus ZeroMQ est légère et rapide. Je réinvente déjà la roue en écrivant un serveur d'authentification Yubikey, je ne vais pas en plus m'ennuyer à écrire un nouveau protocole. Et puis ça facilite l'écriture des clients : ZeroMQ fournit des bindings pour plein de langages différents : http://www.zeromq.org/bindings:_start.
2/ Parce que ZeroMQ est bien plus simple et léger que AMQP.