Sur le coup « la clé API est un mot de passe » je ne peu pas te suivre.
La clé est en claire et diffusée dans des communications en clair (url par exemple).
Le principe d’une clé API est de remplacer un login/password. Donc si, je suis d’accord avec @Mips une clé API est un mot de passe.
et ton mot de passe n’est pas envoyé en clair p-e? oui, il l’est aussi!
dans les 2 cas, le tout sera encrypté via TLS si https mais rien de plus, ca passe en clair.
A un moment si on contre-dit sans savoir, je ne vais plus intervenir parce que ca va m’énerver 
ce qui aiderait par contre c’est qu’on puisse, en option, envoyer la clé api dans un header, car si dans l’url, alors elle peut apparaitre plus facilement dans un log de serveur web ou d’un proxy.
mais bien souvent l’utilisateur n’aura pas d’autre choix que de la mettre dans l’url car le client ne supportera rien d’autre
Dans Jeedom la clé est accessible en clair par les plug-in, dès lors ce n’est pas une protection
Un mot de passe est cripté.
A mon sens tout accès à l’API doit être
Explicitement autorisé par une demande ou un user/mot de pass.
Je vais m’arrêter là car j’ai l’impression que mes propos sont interprétes comme une critique que Jeedom (et donc des dev). Mes propos sont portés par une proposition d’évolution suite à mon expérience décrite dans le post de mon premier message.
Bonne journée à tous
Le souci c’est que tu n’as pas les connaissances pour cerner le sujet (et je ne suis pas expert non plus).
c’est comme si tu installe une porte blindé à coté d’une baie vitré.
Au regard de l’architecture actuelle de jeedom, un plugin peut tout faire notamment décrypter ton mdp, créer une session, ouvrir un accées invisible à jeedom,…
Si ça peut te rassurer un peu, Jeedom est relativement bien sécurisé déjà. Comme j’ai dis plus haut le risque 0 n’existe pas, les failles de sécurités existent partout (OS, debian, PHP, les lib des daemons, ton navigateur, les extension de ton navigateur, tes équipements connéctés…). Même des serveurs suivis par des professionnelles de la sécurité se font piraté et parfois par un gamin de 15 ans.
le fait de passer une clé Api dans une url, n’est franchement pas le top, faut il encore que quelqu’un puisse surveiller ton trafic ! (donc n’invite jamais personne chez toi 
), la passer en header c’est mieux mais tout les clients ne savent pas le gérer et serait plus complexe à mettre en œuvre.
Pour conclure, il ne faut pas tomber dans le paranoïa, les dev (au moins ceux qui ont des plugins payants) ont fourni leur identité à jeedom.
sur jeedom tu peu consulter et analyser chaque fichier, ce n’est pas le cas d’autres interfaces (alexa, nestHub, équipements connectés…) dont ont peu pas consulter le firmware.
c’est pas interprété comme une critique mais tu te trompes à 200% c’est tout: tu as tord sur toute la ligne.
- non le mot de passe n’est pas encrypté, il est hashé; et la différence est fondamentale (un dev qui encrypte un mot de passe sur son app, faut le virer sur le champ)
- les clés api sont encryptées en DB, et ca n’empêche pas le plugin de la lire…
- on s’en contre-fiche ici, un plugin c’est du code que tu installes sur ton jeedom; avec du code tu fais TOUT ce que tu veux, même si on voulait empêcher un plugin de lire la clé, ce serait impossible.
- même s’il n’y pas de clé api, même si tu refuses l’accès à la clé api, le plugin peut faire ce qu’il veut! et si c’est du code malveillant, il n’en a rien à faire de ta clé api, il ouvre une backdoor s’il veut avec les accès qu’il veut.
il faut détourner le traffic pour le voir ! juste surveiller de l’extérieur ne permet pas de voir la clé api, url ou pas!
l’url est chiffrée par https comme le reste !
le problème n’est absolument pas le réseau sur ce point, c’est une fausse impression.
oui mais pourquoi??
=> le serveur web de destination (jeedom donc ici), c’est pas génial mais c’est pas le pire
l’histoire de proxy… qui ici utilise un proxy pour un flux api vers son jeedom? personne. (on ne parle pas de reverse proxy qui dans 99% des cas est le point de terminaison http de toute façon)
(on parle d’api donc volontairement je ne parle pas de referrer, code client dans une page web, historique navigateur etc puisque c’est hors sujet)
Je ne remets personne en cause, plug-in payant ou pas, je ne pense pas que la sécurité doive reposer sur la confiance mais sur des mécanismes qui protègent.
Beaucoup ouvrent leur Jeedom sur l’extérieur, c’est à prendre en compte et beaucoup sans même https.
Débat stérile et qui part en sucette.
Jeedom n’est pas moins fiable qu’une autre solution domotiue au niveau sécurité.
Ce n’est pas seulement lié à Jeedom. Que ce soit Home Assistant, Domoticz et j’en passe, c’est pareil.
Si tu veux être vraiment secure, reste en local et n’utilise plus de plugins qui s’appuient sur des API tierces pour accéder à des objets connectés.
On expose une API key via un plugin, c’est la misère ? En plus de 10 ans, je n’ai pas vu un seul utilisateur se plaindre qu’on lui avait allumé sa lumière.
Par contre, le jour où tu te fais sniffer du DNS ou récupérer un accès distant, là c’est bien pire : derrière, tu récupères directement un accès admin au système.
Sympa ensuite l’accès SSH (réseau), DB, etc.
La sécurité t’appartient , tu dois savoir ce que tu fais . T’as un doute , ben reagis en consequence. Passe en local ou change de plateforme et va débattre sur le forum dédié de cette question
À l’origine je fais juste une proposition mais j’ai l’impression que c’est de plus en plus dur de rester sur la communauté. La moindre proposition et c’est la guerre pour expliquer que ça sert à rien. J’adore Jeedom mais je pose sérieusement la question de rester ici.
Et je comprends qu’il y ait de moins en moins de posts ici.
Bonne soirée à tous
Tu as posé des questions légitimes parce que tu n’avais pas toutes les infos sur le sujet, et c’est normal de vouloir comprendre.
De mon côté, j’ai simplement apporté des réponses argumentées pour clarifier les points techniques.
Il n’y a aucune guerre ici, juste un échange de questions et de réponses, rien de plus.
1 « J'aime »
Bonjour
Ta demande est légitime et sûrement dû à un manque de documentation de notre côté. Pour répondre rapidement :
- un plugin une fois installé peut tout faire il a un accès full à tout la base de données et à tout le code. Aucun rapport avec une clef api ici et aucun moyen de sécuriser ça. Si c’est un point gênant alors il ne faut prendre que les plugin officiel.
- La clef api sert pour deux truc globalement : la discussion entre les démons et jeedom et la communication entre l’extérieur vers jeedom (cas assez rare en vrai qui concerne surtout des applications externe qui veulent discuter avec jeedom)
Ce que tu demande de mettre api + user/mot de passe ne se fait pas )j’ai encore jamais vu un logiciel faire ça). Pourquoi ? Car tu n’améliore absolument pas la sécurité (mettre plus de mot de passe ne sert que si le mot de passe de base n’est pas fort, ce n’est pas le cas des clef api qui sont plus complexe que les mots de passe que les utilisateurs mettent) mais surtout tu diminue la sécurité de ton jeedom.
Pourquoi ? Car si la communication avec le service externe est corrompu tu as donné la clef api ton user et ton mot de passe (qui peut probablement être utilisé pour d’autre service c’est donc une catastrophe).
Je comprends ton besoin de sécurité mais si une faille arrive ça sera pas la clef api la première responsable mais plutôt une faille dans le code. Après tu peux améliorer la sécurité en ne donnant pas la clef api du core de jeedom mais en faisant un user dédié en en donnant cette clef api (elle est faite pour et tourne tous les 3 mois pour forcer justement une reconfiguration lors de l’utilisation d’applications externe comme c’est le cas)
Pour résumer on comprend bien ta demande et ton envi de sécurité mais on a déjà réfléchis à toi ça et tout est prévu dans jeedom pour rendre cette partie api le plus sûr possible. La sécurité n’est pas quelque chose qu’on prend à la légère c’est même plus important pour moi que la stabilité ou les fonctionnalités
2 « J'aime »
Je ne vois pas bien pour les photos. Mais nous sommes d’accord. C’est le principal. Le lecteur sera à l’extérieur, d’où le modèle wiegand IP66+ et la carte à l’abri dans la maison. Ce type de lecteur, justement, n’a pas d’autre fonction que d’envoyer la lecture du badge. Il n’a pas de sortie gâche par exemple. Impossible donc de le « pirater » de façon hard. On peut faire ce que l’on veut avec les fils, aucune info n’arrivera sur la carte. Merci des conseils, ça pourra servir à d’autres.
1 « J'aime »
Merci beaucoup Loic
C’est plus clair pour moi et j’ai des interrogations du coup.
-
Quelle conséquence possible si je renouvelle à la main ma clé core de façon régulière ?
-
Je comprends que je peux répondre à mon besoin initial de ne pas utiliser la clé API du core en créant un utilisateur dédié et utiliser sa clé API qui donnera les accès correspondant au profile de cet utilisateur à l’appli tiers. Si c’est le cas, ça correspond parfaitement au besoin. Tu confirmes ?
Ce qui m’a fait m’interroger c’est l’application https://easydash.fr/ qui permet d’utiliser notre Jeedom juste en rentrant la clé API du Core. Rentrer sa clé API sur un site du web me parait dangereux.
Merci de tes retours et belle journée
Salut,
Moi aussi et c’est la raison pour laquelle je ne donnerai pas ma clé API à un tiers.
Mais la problématique ne vient pas de jeedom ici. Une clé API est quelque chose de privé, si tu ne pense pas pouvoir faire confiance à celui à qui tu la donne alors il vaut mieux s’abstenir.
Mais je le redis ce n’est pas une problématique qui concerne jeedom, n’importe quelle solution aurait la même problématique à partir du moment où une clé API permet de se connecter au système. Dans Home Assistant pour ne citer qu’eux c’est pareil …
Ca va bloquer l’accès à tout programme qui utilise cette clé. Soit normalement aucun si tu ne l’a communiqué à personne jusque la. Donc ça n’aura pas de conséquence.
1 « J'aime »
Bonjour
La conséquence de changer la clef api c’est que tout ceux qui l’utilisent n’auront plus accès à jeedom.
Pour la clef api utilisateur elle est bien sûr limité aux droit de l’utilisateur.
Pour le site que tu donnes c’est pas un site officiel jeedom donc oui y’a toujours un risque de donner une clef api a des sites non officiel.
1 « J'aime »
Très clair, merci.
Je n’avais jamais regardé du côté des plug-in aussi je suis très surpris que par défaut (je n’ai rien touché) ils s’attribuent les droits les plus larges.
Je comprends qu’à part ceux qui appellent des fonctionnalités cloud ou système peut être, ils n’ont pas besoin de ces accès.
L’accès existe mais si personne a la clef alors aucun risque surtout qu’il y a un fail2ban interne donc 3 essai et c’est fini.
Après les plugins comme dit on déjà tous les droits y’a aucune restriction possible donc leur clef api n’est pas le risque ils ont déjà accès à tout
1 « J'aime »
Il faut que tu donnes des exemples parce que factuellement c’est faux, beaucoup des plugins que j’utilise ont leur clé API de plugin de désactivée car inutile.
Comme l’a dit Loic, pas nécessairement, si un plugin utilise un daemon (en gros un process système autonome pour communiquer avec d’autres équipements de façon cyclique) il peut avoir besoin d’utiliser l’API pour envoyer et recevoir des données à jeedom.
Factuellement, un beau score d’activé 34/48 !
Je veux bien savoir ce qui est justifié et ce qui l’est moins
API activé :34
Agenda
Air Quality
AirSend
Boite à lettreS
Broadlink
Brother
Caméra
Data Export
Deconz
DomoGeek
Dyndns
Enedis
Icônes
Infos du Jour
JeeLog
KLF 200
Livebox
Localisation et Trajet
Mode
Météo France
Netatmo Energie
Network
NUT Free
Pimp my Jeedom
Scan Script.Ip
Script
Shelly
Telegram
thermoAlternateView
Thermostat
Virtuel
Weather
Wes Control
Localhost : 1
RFXcom
API désactivé : 13
Atmo France Pollens et AQI
Click link
HistoLisse
Jardin & Potager
jeeHistoGraph
MeteoFull
Monitoring
MSunPV
Pense-bête
Pilotage cameras ONVIF
SSH Manager
Watchdog
Widget Onduleur
J’avais déjà répondu dès le premier post et l’info a été répétée de multiple fois, qu’as-tu encore besoin comme info pour agir par rapport au clé api de plugin?
Il est vrai qu’il y a un certain temps (je ne me souviens pas de quelle version du core), les clés api étaient activées par défaut, ce n’est plus le cas.
Donc si quelqu’un avait cette version du core, les clés sont restées activées.
Avec les infos déjà fournies:
- un démon? => clé localhost (ou désactivée)
- un accès depuis le réseau local => jeedom? => liste blanche devrait fonctionner en principe
- un accès depuis internet => jeedom? => clé activée (donc si c’est uniquement le plugin qui appel une api cloud, pas besoin de la clé api);
- rien de tout ça => clé désactivée
Adaptes la config et vérifies le bon fonctionnement et si tu as un doute , comme déjà dit, créé un post par plugin concerné pour poser la question.
Ca ne sert à rien de continuer à débattre et répéter en boucle toute ce qui a déjà été dit
1 « J'aime »