Il faut partir d’un principe simple : tout code JS executé sur un domaine peut être « vérolé » par le webmaster du dit site. Dans le cadre de gPass et si j’ai bien suivi, c’est simple, il faut faire confiance au site web.
Maintenant les browsers intègrent en standard des politiques qui ne permettent les communications inter-domaines très codifiées, et il est possible d’utiliser ces mécanismes pour sécuriser le processus. Une solution possible est par exemple d’insérer une iframe via javascript et de communiquer via postMessage. Grosso-modo, si je veux m’identifier sur http://consumer.example, je clique sur un bookmarklet qui va charger un script qui lui-même va :
- ajouter une iframe pointant vers https://provider.example/getCredentials?url=http://consumer.example (qui est un serveur hébergé chez moi). getCredentials() me demandera mon mot de passe maître, téléchargera le keyring chiffré et s’occupera du déchiffrement.
- ajouter un handler pour l’event "message" sur la page http://consumer.example, qui recevra les données (utilisateur/mot de passe) de la frame et s’occupera de remplir le formulaire d’authentification du site et de le soumettre.
La seule faille de ce schéma à ma connaissance est dans le fait qu’un site malintentionné peut parfaitement intercepter la création de la frame, remplacer par sa propre page et faire un classique phishing.
[^] # Re: Excellente initiative !
Posté par Moonz . En réponse au journal gPass : un concurrent libre de lastPass. Évalué à 3. Dernière modification le 04 novembre 2013 à 19:06.
Il faut partir d’un principe simple : tout code JS executé sur un domaine peut être « vérolé » par le webmaster du dit site. Dans le cadre de gPass et si j’ai bien suivi, c’est simple, il faut faire confiance au site web.
Maintenant les browsers intègrent en standard des politiques qui ne permettent les communications inter-domaines très codifiées, et il est possible d’utiliser ces mécanismes pour sécuriser le processus. Une solution possible est par exemple d’insérer une iframe via javascript et de communiquer via postMessage. Grosso-modo, si je veux m’identifier sur http://consumer.example, je clique sur un bookmarklet qui va charger un script qui lui-même va :
- ajouter une iframe pointant vers https://provider.example/getCredentials?url=http://consumer.example (qui est un serveur hébergé chez moi). getCredentials() me demandera mon mot de passe maître, téléchargera le keyring chiffré et s’occupera du déchiffrement.
- ajouter un handler pour l’event "message" sur la page http://consumer.example, qui recevra les données (utilisateur/mot de passe) de la frame et s’occupera de remplir le formulaire d’authentification du site et de le soumettre.
Avec cette séparation la clé secrète et le mot de passe maître restent sur le domaine de confiance https://provider.example et ne filtrent jamais sur http://consumer.example.
À partir de là l’essentiel de la sécurité repose sur le navigateur, c’est à dire :
- que le navigateur ne permette pas à un script sur http://consumer.example d’accéder ou interagir de quelque manière que ce soit avec le DOM (ou les scripts) de https://provider.example
- que le script https://provider.example/getCredentials?url=http://consumer.example puisse s’assurer que les données qu’il envoie arrivent bien sur une page contrôlée par http://consumer.example, afin qu’un site mal-intentionné ne puisse pas tout bêtement intercepter l’ajout de la frame et la remplacer par https://provider.example/getCredentials?url=http://paypal.example
La seule faille de ce schéma à ma connaissance est dans le fait qu’un site malintentionné peut parfaitement intercepter la création de la frame, remplacer par sa propre page et faire un classique phishing.