Il y a quelque temps, j'ai écrit un système d'authentification utilisant les clés Yubikeys. Cela permet de s'authentifier par SSH ou sur un serveur web en utilisant un jeton, en plus de son mot de passe. Je l'utilise quotidiennement depuis plusieurs mois. Voici donc le code (GPL v2+).
Yubikeys
Ce sont des périphériques USB de la taille d'une clef fournissant des mots de passe uniques (One Time Password) ou jetons. Elles se comportent comme un clavier et émettent une séquence de touches différente à chaque appui sur son bouton. L'intérêt par rapport aux autres solutions OTP matérielles est son faible coût (25 $) associé à des spécifications publiques. Les logiciels pour configurer les clefs sont sous licence BSD et les algorithmes de génération des jetons sont publiques (s'appuyant sur AES-128).
Le fabricant, yubico, fournit des serveurs permettant au travers d'une API d'authentifier des jetons, mais libre à qui veut d'effectuer cette vérification localement.
Pourquoi réinventer la roue ?
Si les sources des serveurs sont aussi disponibles pourquoi vouloir tout recoder ? La raison principale est que l'implémentation officielle est un service web écrit en PHP, couplé à une base MySQL ou PostgreSQL. Je trouvais cela un peu lourd de devoir installer un serveur LAMP pour gérer l'authentification de sessions SSH. Et puis aussi je n'aime pas PHP…
L'autre raison est que le serveur officiel requiert les clefs de présenter un identifiant unique avant le jeton. Je n'aimais pas cette approche et je préfère que mes clés ne délivrent que le jeton.
Un serveur
Le serveur est écrit en C, stocke les données dans une base SQLite et communique avec les clients grâce à la bibliothèque ZeroMQ. Le client est très léger et tourne depuis de nombreux mois, sans plantage, ni fuite mémoire.
Un module PAM
Ce module en C permet d'ajouter une authentification par jetons pour tous les logiciels qui gèrent le système PAM. Par exemple, pour que sshd demande un jeton avant le mot de passe traditionnel, il suffit de rajouter une ligne dans /etc/pam.d/sshd.
Un module Apache
Grâce à ce module, Apache peut demander un jeton avant d'autoriser l'accès à une page. On peut choisir le temps durant lequel l'authentification est valide.
Et aussi…
De petits programmes en C et python permettent de gérer la base de données du serveur ou d'initialiser de nouvelles clefs.
Conclusions
Ce n'est pas mon métier d'écrire des programmes sûrs, je passe plutôt mes journées à compter des électrons. Vous êtes donc prévenus sur la qualité du code, mais je pense que cela peut toujours servir si quelqu'un a la même problématique que moi.
Le code est disponible là : yubikey_zmq
Il y a tout ce qu'il faut pour générer un paquet Debian. La TODO list est assez longue, donc si quelqu'un est intéressé pour utiliser ce code, qu'il n'hésite pas à m'envoyer des patchs.
# ZeroMQ
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
1/ À vue de nez, ça semble assez simple, donc je me demande pourquoi passer par une lib telle que ZeroMQ quand un simple protocole maison aurait sans doute pu faire la job sans demander plus de travail de ta part (même si je trouve ton choix en fait plus intéressant).
2/ Pourquoi avoir choisi ZeroMQ et pas AMQP ?
[^] # Re: ZeroMQ
Posté par Bapt (site web personnel) . Évalué à 3.
pour le 2/ parce que AMQP est une énorme usine a gaz, et que pour ça justement ZeroMQ semble 10 fois plus approrié (en ne s'occupant que de la com)?
[^] # Re: ZeroMQ
Posté par fredix . Évalué à 2.
Je confirme pour ZeroMQ c'est juste génial, elle devrait être plus connue cette lib. Sinon j'ai pas tout compris, le serveur est sur un serveur et le client sur la machine locale qui accède à la Yubikeys ?
[^] # Re: ZeroMQ
Posté par Antoine . É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 fredix . Évalué à 5.
Ok, et ca serait une grosse connerie de désactiver la saisie du password pour n'utiliser que la yubikey ?
[^] # Re: ZeroMQ
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu perds alors la double authentification, et donc tu te fies qu'à l'objet physique (tu te fais voler ta yubikey, et ton serveur est ouvert).
L’intérêt de la double authentification est de vérifier que c'est toi avec :
- Quelque chose que tu connais
- Quelque chose que tu as
Enlève la saisie du password, et tu te retrouves avec uniquement "Quelque chose que tu as". Je serai tenté de dire : ce n'est pas forcément une grosse connerie, il faut par contre que tu saches ses limites (le pirate n'a qu'à te piquer la yubikey et il a accès à ton serveur). C'est un choix. Bizarre (j'ai du mal à cerner l'utilité), mais c'est un choix de sécurité simple (unique authentification) comme un autre.
[^] # Re: ZeroMQ
Posté par fredix . Évalué à 4.
Oui bien sur c'est risqué mais ca faciliterait le quotidien je trouve. Par contre il faudrait en cas de perte ou de vol, pouvoir révoquer rapidement la yubikey en question.
[^] # Re: ZeroMQ
Posté par Antoine . É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 . É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: ZeroMQ
Posté par fredix . Évalué à 2.
Bin c'est plus simple et rapide que la saisie d'un mot de passe, par contre on peut révoquer une yubikey ?
[^] # Re: ZeroMQ
Posté par Antoine . É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Oups, j'ai vraiment dû manquer quelque chose. Mais cette explication évoque pour moi l'emploi d'une clef ssh (ce que j'ai) cryptée (ce que je sais). Une âme charitable pourrait-elle me ré-expliquer l'intérêt de la yubikey par rapport à une clef usb sur laquelle se trouve une clef ssh ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: ZeroMQ
Posté par fredix . Évalué à 1. Dernière modification le 21 mai 2012 à 13:41.
bin la biométrie ? quoique ce support doit dépendre de la clé.
[^] # Re: ZeroMQ
Posté par Juke (site web personnel) . Évalué à 3.
Les yubikeys ne sont pas biometriques.
[^] # Re: ZeroMQ
Posté par Zenitram (site web personnel) . Évalué à 5.
Presque : tu l'as, mais d'autres peuvent l'avoir aussi, elle n'est pas garantie unique.
La clé SSH, c'est un peu comme les vieilles clés physiques (les nouvelles étant plus difficilement copiables) : ça protège pas mal, mais si en soirée un mec te la pique, prend le moule, et te la remet dans ta poche, tu ne vois pas que tu as perdu une sécurité. Ici, j'ai l'impression (l'auteur du journal confirmera, ou pas) que la rubikey apporte la fonctionnalité "pas copiable".
[^] # Re: ZeroMQ
Posté par claudex . Évalué à 4.
Sauf que, si je ne me trompe pas, je peux voler la yubikey, lui faire générer quelque code pour avoir de la réserve et te la rendre. Si tu ne t'es pas rendu compte du vol, il y a moyen de faire du dégât.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZeroMQ
Posté par Juke (site web personnel) . Évalué à 4.
c'est pour ça qu'il vaut mieux rajouter un mot de passe en plus (ce que je connais). Chez nous le login est le token yubikey et le mot de passe reste.
[^] # Re: ZeroMQ
Posté par Zenitram (site web personnel) . Évalué à 3.
L’intérêt de ce genre de clé (du moins celles que je connais) est d'être dépendant du temps (non modifiable). Je ne connais pas yubikey, mais si la fonction de génération des clés n'est pas dépendante du temps, effectivement je ne vois pas l’intérêt d'une telle solution.
Bon, ben on va attendre que l'auteur du journal nous précise quel est l'avantage de yubikey face à une clé SSH…
[^] # Re: ZeroMQ
Posté par claudex . Évalué à 3.
La dépendance au temps est une contrainte en plus mais si tu vas une heure à la piscine et que je te vole la clef pendant ce temps, tu ne t'en rendra pas compte non plus et je serais quand même logué.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZeroMQ
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui, mais ça c'est le "ce que j'ai", c'est justement le sens de la double-authentification ("ce que je sais" en plus).
Ton exemple, on y peut rien du tout, c'est même l’intérêt de la chose d'avoir la possession de.
Le point intéressant du "ce que j'ai", c'est que du l'a au moment de l'authentification. Si tu laisses la clé à quelqu'un lors de ta piscine, c'est un autre problème (corrigé par le "ce que je sais", qui marche ici et aussi pour une clé SSH).
[^] # Re: ZeroMQ
Posté par Antoine . É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 Zenitram (site web personnel) . Évalué à 3.
Merci pour les détails.
J'en conclue que c'est pas trop mal sécurisé pour moins cher, mais moins sécurisé qu'une clé RSA qui a un compteur de temps. Car si j'ai bien compris, entre le moment où le méchant copie quelques jetons et le moment où tu te connectes, le méchant peut accéder (sous couvert de pass, certes) à ton compte (et pour moi, ça peut durer des jours).
Bref, c'est un bon rapport sécurité/prix, plus sécurisé qu'une clé SSH (qui est moins cher), mais moins sécurité d'une clé RSA (qui est plus cher).
En fait, je me balade avec ma propre machine, car c'est limite d'utiliser une autre machine. Mais effectivement, pour qui se connecte de n'importe quelle machine (donc de "vrais" utilisateurs), c'est sans doute mieux.
[^] # Re: ZeroMQ
Posté par Antoine . É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 Zenitram (site web personnel) . Évalué à 2.
Effectivement, c'est un gros bémol. Pour ma curiosité personnelle (je n'en suis pas encore à avoir besoin d'un tel niveau de sécurité chez moi, chez moi c'est "la rache" encore pour la sécurité…), quelqu'un connait-il une solution alliant les deux avantages (libre + sur son serveur avec son choix de clé, et avec gestion de la donnée temporelle)?
[^] # Re: ZeroMQ
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Oui et en plus tu auras un sav en français puisque l'entreprise est en RP : http://www.gooze.eu
[^] # Re: ZeroMQ
Posté par boarf . Évalué à 4. Dernière modification le 21 mai 2012 à 22:22.
Sinon, tu as aussi le standard TOTP (les token RSA ne sont pas standards, si j'ai bien suivi), dont l'implémentation made in google : google authenticator. Ton smartphone fait office de token et génère des OTP basés sur le temps. Un secret est partagé entre le serveur d'authentification et l'application, l'application peut contenir plusieurs secrets (comme une collection de jetons). L'implémentation est libre, un module PAM est aussi disponible. Il est assez facile de le réimplémenter, il y a par exemple un module wordpress pour utiliser ce système.
Exemple de mise en œuvre : http://blog.essembeh.org/post/2011/Google-auth-OpenSSH
[^] # Re: ZeroMQ
Posté par Jérôme Asseray . Évalué à 2.
si tu veux un protocole ouvert, pourquoi ne pas utiliser OATH??
Concernant RSA, comme d'autre société de ce type, toutes les solutions ne reposent pas uniquement sur des seeds générés par le constructeur. Les tokens software permettent ainsi de regénérer localement la seed en utilisant le protcole CTKIP lors du provisionning.
Je comprends la démarche pour le défi intellectuel et le coût, la critique sur RSA (ou toutes solutions propriétaires, un peu moins).
Avant de te lancer dans ce projet, as-tu regardé si d'autres solutions libres existaient?
[^] # Re: ZeroMQ
Posté par brendel . Évalué à 4.
C'est quoi la différence entre une clé RSA et une clé ssh? Une clé SSH c'est une clé RSA ou DSA si je ne me trompe pas.
[^] # Re: ZeroMQ
Posté par Raoul Volfoni (site web personnel) . Évalué à 3. Dernière modification le 21 mai 2012 à 19:24.
Je pense qu'il parlait de l'entreprise RSA qui fabrique le même genre de périphérique (rachetée par EMC) et non de l'algo.
[^] # Re: ZeroMQ
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 21 mai 2012 à 19:25.
SSH utilise un algorithme nommé d’après leurs auteurs : :RSA_(algorithm). "Clé" est utilisé de manière un peu abusive.
Et ce n'est pas la seule chose que RSA, l'entreprise, fait : RSA_(security_firm)
Un clé RSA, en tous cas ce dont je parle, c'est ça : RSA_SecurID.
[^] # Re: ZeroMQ
Posté par brendel . Évalué à 1.
Je connaissais pas l'entreprise :) merci
[^] # Re: ZeroMQ
Posté par Misc (site web personnel) . Évalué à 5.
C'est marrant de parler de RSA, car on utilise ça au taf, et on a un certain nombre de souci.
Deja, ça coute un peu de thunes. Genre, le double d'une yubikey. Ensuite, il te faut le soft proprio de la boite, qui a de temps en temps des problèmes ( genre, le serveur se bloque sans raison, faut le relancer, mais comme c'est ultra secure, y a que certains admins qui ont accès à la machine ). Il a aussi la fâcheuse tendance à ne pas se laisser modifier, ce qui fait que tu peux pas faire une interface plus simple ou traduite, ou rajouter de l'aide inline. par exemple, on a des liens "request a new token" qui ne servent à rien car on utilise pas la fonction, et on peut pas les virer.
Et de temps en temps, les tokens sont désynchronisés donc faut réussir à le remettre d'aplomb en te loguant sur un site spécial. Parfois, il tombe en panne et pour le moment, j'ai vu au moins 4 desynchros et 1 token en panne seche sur une flotte de 50 personnes en 9 mois, et je pense que tout le monde signale pas les desynchros.
Il y a aussi des trucs amusants :
http://danwalsh.livejournal.com/48571.html
entre "on active une stack executable" et "on utilise pas /dev/random", ça laisse songeur.
Et puis, on peut aussi facilement cloner ton token si tu prends pas la version hardware :
http://arstechnica.com/security/2012/05/rsa-securid-software-token-cloning-attack/
( partant du principe que la version soft sur un tel soit beaucoup mieux ).
[^] # Re: ZeroMQ
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne vois pas trop comment techniquement on peut faire : c'est tout l’intérêt du de la clé matérielle de ne pas pouvoir être copiée! Dès que c'est du soft, c'est mauvais, pas design.
[^] # Re: ZeroMQ
Posté par Misc (site web personnel) . Évalué à 2.
En fait, je voulais dire "soit pas beaucoup mieux", et oui, tu as raison.
[^] # Re: ZeroMQ
Posté par Juke (site web personnel) . Évalué à 2.
effectivement vu que le mot de passe n'est valable qu'une fois (OTP)
par contre tu peux generer des mots de passe d'avance dans un fichier texte par exemple. C'est cependant « évitable » https://www.yubico.com/challenge-response
[^] # Re: ZeroMQ
Posté par fredix . Évalué à 2.
Ok je viens de piger en matant le code que le client est juste un .so qui est inclus dans les services que l'on veut.
[^] # Re: ZeroMQ
Posté par Antoine . É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.
[^] # Re: ZeroMQ
Posté par claudex . Évalué à 3.
À quoi sert cette bibliothèque en fait (en gros) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ZeroMQ
Posté par Antoine . É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 fredix . Évalué à 2.
ZeroMQ c'est le sqlite des messages bus, il n'y a pas de serveur. Mais ça implique aucune persistance disque par défaut contrairement aux outils genre rabbitmq, qpid, redis, riak, etc.
[^] # Re: ZeroMQ
Posté par fredix . Évalué à 4. Dernière modification le 21 mai 2012 à 12:26.
Au fait il y a eu un fork de zeromq par 2 fondateurs : http://www.crossroads.io
# intéressant comme approche
Posté par Christophe Turbout . Évalué à 3.
oui très intéressant même car généralement les systèmes otp sont chers et super fermés !
donc en avoir des ouverts ça peut être vraiment intéressant d'autant plus que ton dev apporte des solutions assez pratiques notamment dans le cadre d'un accès restreint pour un tiers intervenant sur un système par exemple …
# Yubikey dans des logiciels de WebSSO
Posté par KPTN (site web personnel, Mastodon) . Évalué à 5.
Pour ceux qui sont intéressés par cette technologie, sachez que ce moyen d'authentification est implémenté dans différents logiciels libres de WebSSO comme LemonLDAP::NG et OpenAM.
# Question de quelqu'un qui ne connait pas le truc
Posté par oinkoink_daotter . Évalué à 4.
La clef émulant un clavier et donc envoyant des emplacement touche et non des lettres, sais-tu comment ça se débrouille avec les keymap (exemple : la clef envoie un keycode 24, interprété comme "a" en français ou "q" en anglais) ?
[^] # Re: Question de quelqu'un qui ne connait pas le truc
Posté par Antoine . É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: Question de quelqu'un qui ne connait pas le truc
Posté par Anonyme . Évalué à 5.
Dans le même genre, KeePassX a un bug de merde : il tape en QWERTY.
# Problèmes potentiels avec zmq
Posté par Pierre Carrier . Évalué à 6.
Quelques potentiels problèmes avec zeromq, sans avoir regardé le design exact autour de ton logiciel :
1 - zeromq ne peut communiquer qu'avec des pairs de confiance. Le code est rempli d'assertions et il est trivial de le faire crasher dans tous les sens.
2 - Tu sembles utiliser des sockets Req/Rep, qui sont fragiles et généralement une mauvaise idée. Chaque pair doit absolument alterner req et rep ou le socket "explose". Le modèle "je reçois des requêtes et renvoie une réponse par requête" est mieux implémenté avec des sockets utilisant des en-têtes (se référer à l'excellent zmq:guide pour des implémentations "solides").
3 - Il faut autant que possible définir une "low watermark" sur les sockets, si tu ne le fais pas déjà. Si les clients envoient des requêtes mais ne sont jamais là pour recevoir la réponse (client qui meurt prématurément ou est déconnecté, potentiellement un attaquant) les messages s'empilent au cas, où ils réapparaitraient plus tard. Sans "watermark", ils s'empilent indéfiniment et peuvent manger toute la mémoire.
Si tu as le temps, merci d'avance de m'indiquer l'état du code vis-à-vis de ces problèmes :)
[^] # Re: Problèmes potentiels avec zmq
Posté par Antoine . É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: Problèmes potentiels avec zmq
Posté par fredix . Évalué à 4.
Tu t'es sans doute trompé car le zguide ne parle que de high-water mark. Merci pour tes remarques ça me servira sur mon projet, même si j'utilise des sockets de type PUSH/PULL le problème de la memory overflow est là.
[^] # Re: Problèmes potentiels avec zmq
Posté par fredix . Évalué à 3.
http://api.zeromq.org/2-2:zmq-setsockopt
[^] # Re: Problèmes potentiels avec zmq
Posté par Pierre Carrier . Évalué à 2.
Oui pardon, je perds l'habitude du franglais. Il faut définir un "high watermark" bas (d'où le "low") pour jeter les messages rapidement.
# Autres modules
Posté par Aurélien Bompard (site web personnel) . Évalué à 3.
Ça a l'air très intéressant ! J'ai entendu parler d'une autre implémentation d'un module PAM pour les Yubikeys qui ne passait pas par leurs serveurs : http://www.securixlive.com/yubipam/index.php
Est-ce que tu y as jeté un coup d'oeil ? Un avis là-dessus ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.