URL https avec paramètre token : quelle est la sécurité ?

Question

Sur notre site, nous fournissons aux utilisateurs une simulation basée sur leurs informations privées (données via un formulaire). Nous aimerions leur permettre de revenir ultérieurement sur les résultats de leur simulation, mais sans les obliger à créer un compte avec login/mot de passe.

Nous avons pensé à leur envoyer un email avec un lien, à partir duquel ils pourraient récupérer leurs résultats. Mais, naturellement, nous devons sécuriser cette URL, car des données privées sont en jeu.

Nous avons donc l'intention de passer un jeton (comme une combinaison de 40 caractères de lettres et de chiffres, ou un hachage MD5) dans l'URL et d'utiliser SSL.

Enfin, ils recevaient un courriel comme celui-ci :

Salut,
Récupérez vos résultats sur https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Qu'est-ce que vous en pensez ? Est-il suffisamment sécurisé ? Que me conseillez-vous pour la génération de jetons ? Qu'en est-il du passage de paramètres d'URL dans une requête https ?

Answer 1

Le protocole SSL protège les paramètres de la requête en transit. Toutefois, le courrier électronique lui-même n'est pas sécurisé et il peut rebondir sur un grand nombre de serveurs avant d'arriver à destination.

En outre, selon votre serveur web, l'URL complète peut être enregistrée dans ses fichiers journaux. En fonction de la sensibilité des données, vous ne souhaiterez peut-être pas que votre personnel informatique ait accès à tous les jetons.

De plus, l'URL avec la chaîne de requête sera enregistrée dans l'historique de l'utilisateur, ce qui permettra à d'autres utilisateurs de la même machine d'accéder à l'URL.

Enfin, et c'est ce qui rend ce système très peu sûr, l'URL est envoyée dans l'en-tête Referer de toutes les demandes de ressources, même de ressources tierces. Ainsi, si vous utilisez Google Analytics par exemple, vous enverrez à Google le jeton d'URL dans toutes les requêtes.

À mon avis, c'est une mauvaise idée.

Answer 2

J'utiliserais un cookie pour cela. Le flux de travail devrait être comme ceci :

1. L'utilisateur vient sur votre site pour la première fois.
2. Le site crée un cookie
3. L'utilisateur saisit les données. Les données sont stockées dans la base de données à l'aide d'une clé stockée dans le cookie.
4. Lorsque l'utilisateur part, vous lui envoyez un e-mail avec un lien https :.
5. Lorsque l'utilisateur revient, le site découvre le cookie et peut présenter à l'utilisateur les anciennes données.

Maintenant, l'utilisateur veut utiliser un autre navigateur sur une autre machine. Dans ce cas, proposez un bouton "transfert". Lorsque l'utilisateur clique sur ce bouton, il obtient un "jeton". Il peut utiliser ce jeton sur un autre ordinateur pour réinitialiser le cookie. De cette façon, l'utilisateur peut décider du degré de sécurité avec lequel il souhaite transférer le jeton.

Answer 3

SSL sécurise le contenu des données en transit, mais je ne suis pas sûr de l'URL.

Quoi qu'il en soit, une façon d'empêcher un attaquant de réutiliser ce jeton d'URL est de s'assurer que chaque jeton ne peut être utilisé qu'une seule fois. Vous pourriez même définir un cookie pour que l'utilisateur légitime puisse continuer à utiliser le lien, mais après le premier accès, il ne fonctionnera que pour une personne possédant le cookie.

Si l'e-mail de l'utilisateur est compromis et qu'un attaquant obtient le lien en premier, vous êtes fichu. Mais l'utilisateur a aussi de plus gros problèmes.

Answer 4

Le courrier électronique est intrinsèquement peu sûr. Si n'importe qui peut cliquer sur ce lien et accéder aux données, vous ne les protégez pas vraiment.

Answer 5

Le jeton est sécurisé lorsqu'il passe par SSL. Le problème que vous allez rencontrer est qu'il est accessible aux personnes (celles à qui il n'est pas destiné) en étant capable de voir l'URL.

S'il s'agit d'informations privées comme le SSN, je ne pense pas que j'enverrais une URL par e-mail. Je préférerais qu'ils créent un nom d'utilisateur et un mot de passe pour le site. Il est trop facile de compromettre un e-mail avec ce type d'informations en jeu pour vous et pour eux. Si le compte de quelqu'un est compromis, on peut se demander à qui la faute. Plus la sécurité est grande, mieux c'est d'un point de vue strictement CYA.