Je développe une application intranet et je souhaite faire une authentification sécurisée.
Une approche peut être utilisée "HTTPS". Le problème est que le serveur n'a pas de certificat de confiance, est donc un peu ennuyeux pour le client, car le navigateur ne fait pas confiance au certificat et aux plaintes avec un message effrayant.
L'utilisation de HTTP compromettra le mot de passe de l'utilisateur, mais il peut être combiné avec " Digest Authentification d'accès "
Que pensez-vous?
5 Réponses :
Achetez un domaine et un certificat de confiance? Ils ne sont vraiment pas si coûteux si vous magasinez.
Cela dit, l'authentification d'accès Digest est raisonnablement sûre pour l'authentification. En utilisant HTTP plutôt que HTTPS, toutes les informations que vous envoyez sur le fil seront un texte brut même si le mot de passe n'est pas. Toute personne qui peut brancher un ordinateur portable à votre intranet exécutant une application telle que Wireshark peut afficher toutes les informations envoyées. Si vous vous souciez de cette information non compromise, HTTP ne répondra pas à vos besoins.
"Toute personne qui peut brancher un ordinateur portable dans votre intranet à exécuter une application telle que WireShark peut afficher toutes les informations envoyées" alors que cela est vrai de sans fil, ce qui n'est pas vrai dans un réseau commuté (ce que vous avez probablement avec la fiche Ethernet dans le mur). Vous ne pourrez voir que le trafic de diffusion. Http n'est pas diffusé.
Le problème est que vous ne pouvez pas acheter de certificats pour des domaines internes. Seulement pour les domaines mondiaux comme .com, .NET, etc.
Si vous en avez besoin pour être complètement sécurisé, vous devez acheter le certificat SSL.
du lien WIKI que vous avez fourni:
L'authentification d'accès Digest est conçue comme un compromis de sécurité; Il est destiné à remplacer l'authentification d'accès HTTP non cryptée HTTP qui est extrêmement faible. Cependant, il n'est pas destiné à remplacer les protocoles d'authentification puissants, tels que la clé publique ou l'authentification Kerberos.
Je pense qu'il y a votre réponse :)
L'achat d'un certificat n'est pas possible si le domaine est hostname.internal.domain , ce qui est le cas lors du déploiement d'applications internes "intranet" à la plupart / à tous les environnements d'entreprise.
Vous avez ces options:
Achetez un certificat de confiance.
ou, générez votre propre certificat racine, installez-le dans des navigateurs sur tous les ordinateurs intranet (vous devriez pouvoir le faire car il est intranet), générer votre propre certificat de serveur signé avec votre propre certificat racine. C'est en fait quelles entreprises font souvent.
Remarque: l'authentification d'accès à la digère n'est pas utile si vous souhaitez avoir une authentification de formulaire (un formulaire HTML avec l'utilisateur, le mot de passe, la page de connexion à l'aide du style visuel de votre application, plus de signification des erreurs de mot de passe plus agréable, éventuellement des fonctionnalités supplémentaires telles que " souviens-toi de moi "ou" mot de passe oublié ").
à partir de novembre 2015, vous Impossible d'acheter des certificats pour les domaines internes afin que je sache la seule option consiste à pré-installer les certificats sur les clients. Pas une excellente solution.
Une autre possibilité de protéger si vous voulez garder vos domaines internes privés, c'est créer un domaine public: myCompany.com, puis exécutez votre propre serveur DNS en interne qui résout vos domaines internes: comptable.internal.mycompany.com < / Code>, hr.internal.mycompany.com et ainsi de suite. Ensuite, je pense que vous pouvez utiliser un certificat de carte générique pour myCompany.com . Je n'ai pas testé cette solution.
Ce sont (y) nos options:
Si vous avez surtout des hôtes Windows, vous pouvez distribuer des certificats aux ordinateurs clients à l'aide de la stratégie de groupe | Microsoft Docs et utilisez votre propre certificat auto-signé de cette manière.
Vous utilisez un nom de domaine approprié, un vrai certificat et un DNS désordonné configuration où www.mycompany.com se résout à un site externe, mais wiki.mycompany.com est un site interne (mais s'il vous plaît, s'il vous plaît ne pas mettre l'interne Adresse pour wiki.mycompany.com dans un enregistrement DNS visible externe!)
Vous n'utilisez pas du tout HTTPS et utilisez http. Éventuellement en inventant votre Sécurité propre pour les pages de connexion (Yikes!)
Ils sucent tous.
Surtout si vous souhaitez distribuer une application sur site Prêt d'entreprise et que vous ne connaissez pas à l'avance le réseau et la configuration DNS du client.