URL https avec paramètre de jeton: comment est-il sécurisé?
Sur notre site, nous proposons aux utilisateurs une simulation basée sur leurs informations privées (transmises via un formulaire). Nous aimerions leur permettre de revenir sur leurs résultats de simulation plus tard, mais sans les forcer à créer un compte de connexion/mot de passe.
Nous avons pensé à leur envoyer un email avec un lien, d'où 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 recevraient un e-mail comme celui-ci:
Salut,
Récupérez vos résultats sur https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn
Qu'est-ce que tu en penses? Est-il suffisamment sécurisé? Que me conseillez-vous pour la génération de jetons? Qu'en est-il de la transmission des paramètres d'URL dans une demande https?
SSL protégera les paramètres de requête en transit; cependant, le courrier électronique lui-même n'est pas sécurisé et le courrier électronique peut rebondir sur un certain nombre de serveurs avant d'arriver à destination.
En fonction de votre serveur Web, l'URL complète peut également être enregistrée dans ses fichiers journaux. Selon la sensibilité des données, vous ne souhaiterez peut-être pas que vos informaticiens aient accès à tous les jetons.
De plus, l'URL avec la chaîne de requête serait enregistrée dans l'historique de votre utilisateur, permettant aux autres utilisateurs de la même machine d'accéder à l'URL.
Enfin, et ce qui rend cela très peu sûr, l'URL est envoyée dans l'en-tête Referer de toutes les demandes pour n'importe quelle ressource, même des ressources tierces. Donc, si vous utilisez Google Analytics par exemple, vous enverrez à Google le jeton d'URL et tout cela pour eux.
À mon avis, c'est une mauvaise idée.
J'utiliserais un cookie pour ça. Le flux de travail devrait être comme ceci:
- L'utilisateur vient sur votre site pour la première fois.
- Le site installe un cookie
- L'utilisateur entre des données. Les données sont stockées dans la base de données à l'aide d'une clé qui est stockée dans le cookie.
- Lorsque l'utilisateur quitte, vous lui envoyez un e-mail avec un lien https:
- Lorsque l'utilisateur revient, le site découvre le cookie et peut présenter à l'utilisateur les anciennes données.
Désormais, l'utilisateur souhaite utiliser un navigateur différent sur une machine différente. Dans ce cas, offrez un bouton "transfert". Lorsque l'utilisateur clique sur ce bouton, il recevra un "jeton". Elle peut utiliser ce jeton sur un autre ordinateur pour réinitialiser le cookie. De cette façon, l'utilisateur décide dans quelle mesure il souhaite transférer le jeton.
Le courrier électronique est intrinsèquement non sécurisé. Si quelqu'un peut cliquer sur ce lien et accéder aux données, vous ne le protégez pas vraiment.
Eh bien, le jeton est sécurisé lors de son passage via SSL. Le problème que vous allez avoir, c'est qu'il est accessible aux personnes (à qui il n'est pas destiné) en pouvant afficher l'URL.
S'il s'agit d'informations privées comme 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 récit de quelqu'un est comprimé, il sera mis en doute de la faute de qui il s'agit. Plus vous êtes sûr, mieux vous êtes d'un point de vue strictement ACY.
Je ne pense vraiment pas que cela soit suffisamment sécurisé pour une situation où il y a de graves problèmes de confidentialité. Le fait que vous envoyez l'URL dans un e-mail (probablement en texte clair) est de loin le maillon le plus faible. Après cela, il y a le risque d'attaques par force brute sur les jetons, qui (sans la structure d'un véritable mécanisme d'authentification) sont probablement plus vulnérables qu'une configuration de nom d'utilisateur et de mot de passe bien conçue.
Incidemment, il n'y a aucun problème avec les paramètres d'une demande https.
En l'état, ce serait une mauvaise idée. Vous réduirez la sécurité avec une utilisation facile. Comme indiqué précédemment, SSL ne protégera que le transfert d'informations entre le serveur et le navigateur client et empêchera uniquement l'attaque de l'homme du milieu. Les e-mails sont très risqués et peu sûrs.
Le mieux serait un nom d'utilisateur et une authentification par mot de passe pour accéder aux informations.
J'aime plus ou moins l'idée des cookies. Vous devez également crypter les informations sur les cookies. Vous devez également générer le jeton avec du sel et la phrase clé plus le $ _SERVER ['HTTP_USER_AGENT'] pour limiter la probabilité d'une attaque. Stockez autant d'informations non sensibles sur le client dans le cookie à des fins de vérification.
La phrase clé pourrait être stockée dans le cookie pour une utilisation facile, mais gardez à l'esprit que le cookie peut également être volé = (.
Mieux vaut laisser le client taper la phrase clé qu'il a fournie, qui est également stockée dans la base de données avec ses données.
Ou, la clé peut être utilisée dans le cas où la personne utilise une autre machine qui diffère dans les paramètres $ _SERVER ['HTTP_USER_AGENT'] ou manque simplement le cookie. Ainsi, le cookie peut être transféré ou défini.
Assurez-vous également que les données sensibles sont chiffrées dans la base de données. On ne sait jamais ;)