En cas d'application Web, je peux comprendre qu'il n'y a aucune différence entre l'authentification du client et l'authentification de l'utilisateur; En ignorant XSS et d'autres exploits, le client Web est généré par le serveur/servlet. Mais supposons que vous ayez une application cliente Java parlant à l'application Java Server; Le serveur est associé à un certificat afin que le client puisse valider et vérifier si le serveur est approuvé. Maintenant, le client a aussi un certificat (client cert) pour que le serveur puisse vérifier s'il s'agit d'un client de confiance; Une fois cette authentification mutuelle effectuée, au lieu de présenter une boîte de dialogue de nom d'utilisateur/mot de passe à l'utilisateur, le certificat d'utilisateur (cert utilisateur) peut être transmis au serveur.Différence entre l'authentification de l'application client (client autonome java) et l'authentification de l'utilisateur
La question est de savoir s'il y a un avantage/une utilisation dans ce cas d'avoir un (client cert); Ou le certificat d'utilisateur suffira-t-il à lui seul à faire confiance au client?
Je sais que c'est une question évidente/mais ne peux pas créer une application client rouge? Ainsi, le client cert protègera contre ce scénario.
"même un client non fiable ne peut pas faire plus d'un client de confiance avec les mêmes informations d'authentification" Je suppose qu'il n'y a pas actuellement de mécanisme permettant au serveur de savoir si l'application cliente est compromise: Supposons que le client non fiable reçoive des données sensibles du serveur une session d'utilisateur de confiance. Puisque la signature de la méthode est la même et que les paramètres sont propres, le serveur enverra les données demandées. Rien n'empêche l'application de rouge d'utiliser ces données de manière incorrecte. Une chose que je peux penser est d'avoir un outil de vérification de l'intégrité. voir si l'application est compromise ?? –
A fait quelques recherches dans le filet et a constaté que c'est une attaque commune - Excrept de - http://www.ucl.ac.uk/cert/nix_intrusion.pdf L'exemple le plus simple et classique de ceci est de remplacer/bin/login. 1. Obtenez une copie du code source dans/bin/login pour la version d'Unix 2. Modifiez le code source à/bin/login pour inclure un mot de passe «secret» qui vous permettra toujours de vous connecter en tant que root si vous entrez le mot de passe "backdoor". Cette porte dérobée ne créera pas non plus une entrée dans les fichiers journaux du système. Compilez le code source. ..... –
Le fait est que vous pouvez faire confiance à un utilisateur en fonction des informations d'identification qu'il fournit, mais vous ne pouvez pas faire confiance à une application client, sauf si vous êtes dans un environnement fermé (environnement d'entreprise vraiment verrouillé). Le problème avec un vérificateur d'intégrité du côté client est qu'une application compromise pourrait fausser la vérification d'intégrité. Peu importe la complexité de la vérification de l'intégrité, si on lui donne assez de temps, une personne pourrait la contourner. – rancidfishbreath