Je ne suis pas spécialiste en développement Web (ce n'est pas vraiment mon domaine) mais plutôt en développement embarqué.
Imaginons un produit dans la nature en IP dynamique (je ne vais pas dire IoT mais ça pourrait être une imprimante, routeur Wifi…) sur lequel il y a un serveur Web pour sa configuration et sur lequel on veut sécuriser son accès avec une authentification.
Comment sécuriser l'authentification lors de l'accès à cet équipement ?
De ce que j'ai pu voir, le seul vrai moyen d'avoir une authentification sure, c'est de passer par du HTTPS. Mais peut-on utiliser du HTTPS sur un serveur qui n'a pas de nom de domaine ? Cela revient à avoir un certificat auto-signé : cela crypte la connexion mais on ne peut être sur d'accéder au bon serveur, d'où le fameux message pas très rassurant affiché par Firefox. Et il est difficilement imaginable d'avoir un nom de domaine et un certificat pour des dizaines ou centaines d'objet (sachant que l'on est pas mal confiant sur l'IP de l'objet même s'il peut toujours y avoir un risque d'usurpation).
Faute de pouvoir mettre en place du HTTPS fiable entre le client et le serveur de l'équipement, c'est peut-être de passer par un service tiers d'authentification (le client s'y authentifie et le serveur s'y connecte pour s'assurer sur le client est bien autorisé). Mais cela oblige à passer par un tiers…
D'après vous, est-ce que ma compréhension est bonne ? Voyez-vous une solution à ce problème ?
# authent vs crypt
Posté par jemore . Évalué à 3.
Tu souhaites gérer de l'authentification (login / mot de passe) ou tu souhaites chiffrer les données entre le serveur et le client (https) ? les deux ?
[^] # Re: authent vs crypt
Posté par Frédéric COIFFIER . Évalué à 1.
En y réfléchissant, finalement, ça serait les 2… (car je me vois mal laisser passer les données en clair même si l'utilisateur s'est bien authentifié en crypté)… Donc, on revient au problème d'implémentation du HTTPS dans cette configuration…
[^] # Re: authent vs crypt
Posté par Anonyme . Évalué à 2. Dernière modification le 20 août 2015 à 12:03.
Si ce que tu veux c'est vérifier sur un réseau privé que la connexion se fait sur la bonne machine par la bonne personne, j'imagine qu'il faut mettre en place une Infrastructure à clés publiques: c'est le propriétaire du réseau privé qui aura la possibilité de décider comment chaque intervenant du réseau (machine, utilisateur ou administrateur) est identifié et par quel moyen.
[^] # Re: authent vs crypt
Posté par gouttegd . Évalué à 2. Dernière modification le 20 août 2015 à 12:47.
Petite réflexion rapide (et sûrement foireuse, mais merci pour l’exercice).
Première solution : un certificat auto-signé par périphérique, avec sur le périphérique lui-même une étiquette mentionnant l’empreinte du certificat. À charge pour l’utilisateur, lorsque son navigateur tente de lui faire peur en lui criant que la connexion n’est pas authentifiée et qu’il va mourir, de vérifier que l’empreinte affichée par la navigateur correspond à celle collée sur le périphérique.
Éventuellement faire en sorte que le serveur web serve un en-tête HPKP dans l’espoir que le navigateur se souvienne du certificat et n’affiche pas l’avertissement à chaque fois (aucune garantie que ça marche cela dit, la spécification HPKP est muette sur le cas des certificats auto-signés).
Avantage : assez simple à mettre en place, a priori très sûr.
Inconvénients : suppose que le périphérique soit à proximité de l’utilisateur, et surtout que ce dernier prendra la peine de réellement vérifier l’empreinte (je dirais que tu as de la chance si 0.01% des utilisateurs le font) — à défaut tu auras du chiffrement opportuniste sans authentification.
Deuxième solution, plus coûteuse, plus facile pour les utilisateurs mais pas plus sécurisée (plutôt moins en fait) : la société qui produit le périphérique obtient, de la part d’une autorité de certification reconnue, un certificat habilité à signer d’autres certificats (certificat intermédiaire) — attention, il faut payer cher pour ça. Ensuite, on utilise ce certificat pour signer les certificats de chaque périphérique.
Avantage : plus aucune alerte effrayante pour l’utilisateur, puisque le certificat du périphérique a une chaîne de confiance remontant jusqu’à une autorité connue.
Inconvénients :
[^] # Re: authent vs crypt
Posté par Frédéric COIFFIER . Évalué à 1.
Merci pour ce retour qui confirme déjà ma bonne compréhension du problème.
Et ta première solution me convient bien et correspond parfaitement à la problématique : elle n'est pas sure à 100% (même si finalement assez fiable) mais de toute façon, si l'utilisateur finit par mettre '123456' comme mot de passe, tout autre solution n'aura servi à rien.
# Solution
Posté par Zenitram (site web personnel) . Évalué à 7.
Lui mettre un nom de domaine (et le produit mettra à jour le nom de domaine avec la nouvelle IP, classique de chez classique).
Ca servira aussi pour s'y connecter.
Parce que bon, tu dis qu'il a une IP dynamique, donc faut bien trouver un moyen de le contacter, et le nom de domaine est la… pour ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.