Déconnecter l'utilisateur après un changement d'adresse IP?
Est-il judicieux de déconnecter un utilisateur d'un service Web après la modification de l'adresse IP de l'utilisateur?
Je comprends qu'un changement d'adresse IP pourrait indiquer une attaque d'homme au milieu. Là encore, les adresses IP des appareils des utilisateurs finaux (téléphones mobiles) peuvent changer fréquemment lors du passage du fournisseur de réseau au WLAN local.
Personnellement, je pense que l'ajout d'un mécanisme de déconnexion comme celui-ci n'augmenterait pas vraiment la sécurité d'un site Web.
Quels aspects dois-je prendre en compte pour prendre une décision solide quant à l'utilisation ou non d'un tel mécanisme de déconnexion?
Si vous souhaitez mettre en œuvre une mesure de sécurité, vous devez savoir contre quoi vous vous sécurisez. Dans ce cas, vous souhaitez vous protéger contre une attaque Man-in-the-Middle.
Comme vous l'avez dit vous-même, un changement d'adresse IP n'est pas un bon indicateur pour cela, pour deux raisons:
- Il existe de nombreuses raisons pour lesquelles une adresse IP changerait pour des raisons légitimes, telles que l'utilisateur gagnant ou perdant une connexion Wi-Fi, l'utilisateur se connectant à un VPN, etc. En tant que tel, cela seul est un très mauvais indicateur d'une attaque.
- Pour que la détection fonctionne, il suppose qu'un utilisateur commence d'abord une session par lui-même, puis est puis intercepté par l'homme au milieu . Si votre utilisateur est déjà intercepté, l'IP de Man-in-the-Middle est la seule IP que vous verrez jamais.
En tant que telle, cette mesure de sécurité est plutôt sujette aux faux positifs et aux faux négatifs, ce qui la rend plutôt peu fiable.
Mais il existe une mesure de sécurité utilisée par Google qui fonctionne de manière similaire. Il détecte les modèles de comportement habituels d'un utilisateur, tels que les emplacements habituels et les plages d'adresses IP à partir desquels il se connecte. Si une connexion s'écarte de ce modèle, une alerte de sécurité est déclenchée.
Cela est plus important lorsque les utilisateurs souhaitent consulter leurs e-mails en vacances ou similaire, mais cela peut vraiment être un indicateur de compromis possible si les modèles d'utilisation régulière de l'utilisateur sont clairement établis.
Cela devrait être un exemple de la façon dont les informations provenant des adresses IP (et d'autres sources) peuvent être utilisées pour analyser le comportement et ainsi détecter les anomalies. La détection d'anomalies est un domaine à part entière, alors ne vous attendez pas à une introduction complète dans un paragraphe. Cet exemple ne doit servir qu'à des fins d'illustration.
La contrepartie uniquement est celle du risque .
Des contrôles (comme ce contrôle) sont mis en place pour atténuer les risques . Quels risques essayez-vous d'atténuer? Vous dites que cela pourrait atténuer MitM. D'accord. Est-ce la responsabilité de votre service Web de le faire? Est-il logique que le service le fasse?
Considérons ensuite le scénario réel. Votre contrôle atténue MitM si l'attaque se produit après que l'utilisateur s'est déjà connecté. C'est assez spécifique et une menace vraiment limitée. Continuons à exécuter le scénario. L'attaque se produit et le service déconnecte l'utilisateur, puis l'utilisateur se reconnecte. Mais l'attaque se produit toujours. Ainsi, l'attaquant capture maintenant le processus de connexion et le mot de passe. Avez-vous atteint l'objectif du contrôle? Certaines de ces choses pourraient être atténuées par d'autres contrôles que vous pourriez avoir en place.
Tenez également compte des risques de mauvaise utilisation. Si vous installez un contrôle qui empêche les utilisateurs d'utiliser votre système, vous courez le risque de perdre des utilisateurs.
Quelle est la meilleure décision pour vous dépend de vous et de tous les facteurs que vous ne pouvez pas inclure dans une question sur un site de questions/réponses.
Les évaluations des risques sont vraiment simples. Il vous suffit de connecter lentement les points un par un et de résister à la tentation de sauter jusqu'au bout.
Pas du tout.
Les considérations de sécurité mises à part (ce que cette pratique n'aide pas vraiment), restreindre une session à une adresse IP interrompt complètement l'accès pour les utilisateurs de certains FAI, en particulier les mobiles, qui cyclent fréquemment les adresses IP. IPv6 a même des fonctionnalités pour le faire intentionnellement pour la confidentialité. À moins que vous ne connaissiez bien votre base d'utilisateurs et que vous ne sachiez qu'aucun d'entre eux ne sera affecté par de tels problèmes, il ne s'agit pas d'un démarrage complet.
Auparavant, c'était une chose avec par exemple PHP sessions il y a environ 20 ans. Peut-être avec tout le reste aussi car ils utilisaient des mécanismes similaires/identiques, mais je me souviens de la fonction d'atténuation de PHP. Vous devez simplement l'activer dans la configuration.
Le problème: vous vous connectez et obtenez un cookie de session (éventuellement intégré dans l'URL, même), et quelqu'un d'autre pourrait en théorie écouter ces informations et désormais faire des demandes en votre nom.
Maintenant, bien sûr, plus personne n'utilise HTTP, et HTTPS corrige ce problème. Vous ne pouvez plus envoyer trivialement des demandes au nom de quelqu'un d'autre (enfin, sauf si vous avez installé un faux certificat ou renversé la pile réseau, ou autre).
En outre, certains protocoles de haut niveau plus récents en cours de développement (pensez QUIC) séparent explicitement les connexions des adresses avec la possibilité que l'adresse IP change légitimement. Apparemment, s'il y a un risque pour la sécurité, ce n'est pas si grave qu'il dérange quelqu'un chez Google ou IETF.
Donc ... bref ... pas de soucis.