Firefox a besoin des mots de passe stockés dans son fichier de conf pour le log auto dans les sites qui vont bien. Et il est légitime d'aller sur amazone acheter des livres. Donc l'utilisateur lambda consciencieux se dit : "C'est bon j'accepte pour tout les cas de figure". S'il y a une faille exploitable sur firefox, y'a moyen que les informations soient envoyés sur le service S3 d'amazon. Ton système fait comment dans ce cas de figure ?
Là c'est un problème d'architecture du browser, si c'est un processus monolithique qui gère à la fois des informations sensibles (mots de passe) et la communication avec des sites potentiellement hostiles il y a un problème.
On pourrait imaginer réorganiser le système de la façon suivante : le navigateur ne stocke aucun mot de passe, il communique avec un "démon d'authentification internet" qui le gère. Plus précisément quand le navigateur reçoit un formulaire qui demande des données sensibles, il le donne au démon avec l'adresse de validation. Le démon s'occupe de regarder s'il a les données dans sa base (le mot de passe du site mais pourquoi pas le numéro de téléphone de l'utilisateur si le site fait partie de ceux pour lequel l'utilisateur a dit qu'il faisait confiance pour accéder au numéro), interagit avec l'utilisateur pour les données qui lui manquent, envoie la requête au site web et redirige vers le browser la réponse du site web.
Avec cette organisation la partie de code à auditer/analyser/faire tourner à un niveau de privilège supérieur est beaucoup plus réduite, c'est ce démon plus simple à coder et ayant moins de fonctionnalités, peu d'interaction avec l'extérieur (en particulier aucun parsing de formats sophistiqués, grosse cause de failles), pas de plug-ins etc., et le navigateur n'a plus besoin du droit de gestion du mot de passe. Du côté de l'utilisateur l'ergonomie est toujours la même, on ne lui demande pas plus souvent son avis qu'avant.
(Il reste un soucis potentiel: le navigateur peut envoyer des requêtes au démon qui ne correspondent pas à une action réelle de l'utilisateur. C'est un problème non-critique puisque, comme c'est le démon qui décide d'envoyer les infos sensibles au site, il a son adresse, il peut vérifier qu'il n'envoie pas l'information à n'importe qui (pas besoin de faire confiance au navigateur sur l'identité du destinataire). Mais il peut toujours envoyer des informations qui n'ont pas été demandées. On pourrait imaginer que les sites webs qui demandent des informations sensibles signent leurs formulaires avec leur clé publique pour que le démon puisse vérifier que ça correspond à une demande réelle, mais c'est un raffinement plus coûteux à mettre en place puisqu'il demande des efforts de la part des autre aussi.)
[^] # Re: La politique de sécurité est bonne
Posté par gasche . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 2.
Là c'est un problème d'architecture du browser, si c'est un processus monolithique qui gère à la fois des informations sensibles (mots de passe) et la communication avec des sites potentiellement hostiles il y a un problème.
On pourrait imaginer réorganiser le système de la façon suivante : le navigateur ne stocke aucun mot de passe, il communique avec un "démon d'authentification internet" qui le gère. Plus précisément quand le navigateur reçoit un formulaire qui demande des données sensibles, il le donne au démon avec l'adresse de validation. Le démon s'occupe de regarder s'il a les données dans sa base (le mot de passe du site mais pourquoi pas le numéro de téléphone de l'utilisateur si le site fait partie de ceux pour lequel l'utilisateur a dit qu'il faisait confiance pour accéder au numéro), interagit avec l'utilisateur pour les données qui lui manquent, envoie la requête au site web et redirige vers le browser la réponse du site web.
Avec cette organisation la partie de code à auditer/analyser/faire tourner à un niveau de privilège supérieur est beaucoup plus réduite, c'est ce démon plus simple à coder et ayant moins de fonctionnalités, peu d'interaction avec l'extérieur (en particulier aucun parsing de formats sophistiqués, grosse cause de failles), pas de plug-ins etc., et le navigateur n'a plus besoin du droit de gestion du mot de passe. Du côté de l'utilisateur l'ergonomie est toujours la même, on ne lui demande pas plus souvent son avis qu'avant.
(Il reste un soucis potentiel: le navigateur peut envoyer des requêtes au démon qui ne correspondent pas à une action réelle de l'utilisateur. C'est un problème non-critique puisque, comme c'est le démon qui décide d'envoyer les infos sensibles au site, il a son adresse, il peut vérifier qu'il n'envoie pas l'information à n'importe qui (pas besoin de faire confiance au navigateur sur l'identité du destinataire). Mais il peut toujours envoyer des informations qui n'ont pas été demandées. On pourrait imaginer que les sites webs qui demandent des informations sensibles signent leurs formulaires avec leur clé publique pour que le démon puisse vérifier que ça correspond à une demande réelle, mais c'est un raffinement plus coûteux à mettre en place puisqu'il demande des efforts de la part des autre aussi.)