est-il acceptable d'utiliser des URL aléatoires au lieu de mots de passe? [fermé]

12

Est-il considéré comme "sûr" d'utiliser une URL construite à partir de caractères aléatoires comme celui-ci?

http://example.com/EU3uc654/Photos

Je voudrais mettre des fichiers / galeries d'images sur un serveur Web qui ne sont accessibles qu'à un petit groupe d'utilisateurs. Ma principale préoccupation est que les fichiers ne soient pas récupérés par les moteurs de recherche ou les utilisateurs expérimentés curieux qui fouinent mon site.

J'ai mis en place un fichier .htaccess, juste pour remarquer que cliquer sur des http://user:pass@url/liens ne fonctionne pas bien avec certains navigateurs / clients de messagerie, invitant des dialogues et des messages d'avertissement qui déroutent mes utilisateurs pas trop avertis par ordinateur.

web-server authentication password password-protected Ragoût
la source
Non. Vous pouvez l'utiliser, mais pas comme mécanisme d'authentification unique ou principal.
Andrew Smith
1
J'ai essayé cela à plusieurs reprises comme expérience, et chaque fois que les liens se retrouvent dans les moteurs de recherche. Je ne sais pas comment, mais je sais que cela arrive.
David Schwartz
Vous voudrez peut-être configurer SSL pour arrêter les avertissements, vous pouvez obtenir des certificats gratuits sur startssl.com et SSL n'est plus gourmand en calcul (tant qu'il est correctement configuré).
Hubert Kario
Cette question est un exemple classique "non constructif". Nous ne savons pas à quel point vous appréciez la sécurité de vos photos. La seule façon de communiquer l'importance de la sécurité est la méthodologie d'autorisation que vous mettez en œuvre pour protéger l'accès à ces images. Vous obtenez des "arguments de débat" sous forme de "réponses". Mais aucun d'entre eux n'est un aperçu complet de la sécurité moderne et des implications techniques. Vous devez lire les méthodes de sécurité fournies par votre plate-forme et évaluer la valeur de chacune pour votre situation; si vous avez d'autres questions une fois que vous avez fait cela, posez-les à nouveau.
Chris S

Réponses:

17

Que ce soit "correct" ou non dépend de la sensibilité des images.

Si vous n'utilisez pas SSL, les URL, HTML et les images elles-mêmes seront mis en cache sur les ordinateurs de votre utilisateur. Cela pourrait fuir, mais je le considérerais peu probable.

Les barres d'outils du navigateur, en particulier celles créées par des sociétés qui exécutent des robots d'indexation, telles que Alexa et Netcraft, peuvent signaler les URL visitées à leurs sites parents, prêtes pour que le bot vienne explorer ultérieurement.

Une authentification appropriée telle que l'authentification HTTP ou une variable POST ne doit pas pouvoir être mise en cache de cette façon ni renvoyée à un site Web parent.

Une autre technique consiste à utiliser des URL uniques et de courte durée. De cette façon, même s'ils fuient, peu importe. Bien sûr, vous devez continuer à mettre à jour vos utilisateurs légitimes des nouvelles URL.

Ladadadada
la source
+1 pour mentionner les barres d'outils du navigateur.
Hubert Kario
23

Non, pas vraiment, c'est juste une sécurité par l'obscurité qui n'est pas du tout une sécurité. Tout ce qui est directement accessible depuis Internet sans une certaine forme de protection réelle sera trouvé, indexé et mis en cache.

user9517
la source
10
Tous les mots de passe ne sont-ils pas de toute façon une sécurité à travers l'obscurité?
Winston Ewert
4
@WinstonEwert: Les mots de passe eux-mêmes n'ont rien à voir avec la sécurité à travers l'obscurité qui se rapporte au secret de conception / mise en œuvre. Dans le cas, par exemple, de l'authentification de base Apache, sa conception / implémentation est entièrement ouverte à tous.
user9517
10
non-sens - tout est sécurité à travers l'obscurité. Le fait est que pour y arriver, vous avez besoin d'une information suffisamment improbable pour être devinable. L'expression "la sécurité par l'obscurité" est massivement abusée. Un morceau aléatoire d'URL équivaut exactement à mettre un "mot de passe" dans l'URL. La seule question est - qui peut voir cela, et la réponse que j'ai mise dans mon commentaire est "des mandataires intermédiaires, plus c'est http pour que quiconque puisse espionner"
Bron Gondwana
1
Une erreur (ou retour à la configuration par défaut) dans la configuration d'apache et vos répertoires affichent les index avec tous les fichiers et répertoires sur la paume de votre main, pas tellement avec les mots de passe.
Hubert Kario
4
Vous dites que la sécurité par l'obscurité "concerne le secret de la conception / mise en œuvre". Mais clairement, les URL aléatoires ne relient pas le secret de la conception / mise en œuvre. Ainsi, les URL aléatoires, quels que soient leurs défauts, ne peuvent pas être classées comme sécurité par l'obscurité.
Winston Ewert
6

Ils seront enregistrés dans chaque proxy en cours de route. Vous serez à l'abri des utilisateurs et des moteurs de recherche curieux, à moins que quelqu'un ne publie le lien.

Et attention au caractère aléatoire de votre générateur bien sûr.

Je suppose que vous ne recherchez pas une sécurité ultra-élevée ici.

Bron Gondwana
la source
Si quelqu'un publiait l'URL, rien ne l'empêcherait de publier un mot de passe. L'authentification par la connaissance en tant que facteur peut toujours être "trompée" comme ceci.
Manuel Faux
@ManuelFaux: Bien sûr, si c'est intentionnel. Mais cela peut aussi être accidentel. Par exemple, il peut utiliser un outil qui vérifie les URL qu'il visite pour voir si elles ont été signalées comme malveillantes. Les outils savent que les mots de passe sont censés être gardés secrets. Ils savent que les paramètres des URL peuvent être sensibles. Mais ils ne savent pas que les chemins dans les URL le font. (Par exemple, http httper .)
David Schwartz
5

Une URL cryptée est pratique pour les téléchargements à usage unique mais n'offre aucune protection réelle. Vous devez être conscient que tous les robots n'honorent pas le fichier robots.txt, donc s'il y a un lien n'importe où dans votre site menant au dossier déguisé, il sera indexé par certains moteurs de recherche et une fois que cela commencera, il n'y aura plus de retour en arrière.

Je suggérerais d'utiliser un système d'authentification simple basé sur .htaccess à la place, ou en plus de ce que vous proposez.

John Gardeniers
la source
5

Je voudrais ajouter une autre perspective, peut-être plus effrayante, sur les URL obscurcies comme cet exemple. Même si votre URL n'est pas partagée accidentellement, elle peut être soumise aux moteurs de recherche par:

  • FAI d'un visiteur. Les visites HTTP sont collectées, dataminées et parfois même carrément vendues à des tiers par des FAI.
  • Stockage cloud d'un visiteur. Il existe un certain nombre de services stockant gratuitement les signets et l'historique à synchroniser entre les installations de navigateur. À moins qu'ils ne précryptent les données comme le fait Mozilla, les mêmes pratiques d'exploration de données peuvent être impliquées.

YMMV.

korkman
la source
oh oui - ou simplement par un plugin de navigateur qui recherche des sites connexes ou permet aux utilisateurs de partager des notes sur une page
Bron Gondwana
2

Dans le passé, j'utilisais une méthode similaire pour permettre aux utilisateurs de créer des espaces de partage sur un système de gestion de documents. Le contenu partagé n'était pas top secret, le système ne devait donc pas être ultra sécurisé.

Je viens de faire en sorte que l'URL de chaque utilisateur contienne un horodatage d'expiration et un MD5 de son e-mail.

L'URL ressemblait donc à:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

avec ce qui précède, si l'utilisateur a entré l'e-mail [email protected] avant le 30 juillet, il serait bon d'y aller.

Pas exactement une sécurité de niveau militaire mais a fait le travail.

dave e
la source
0

Cela partage la même vulnérabilité que le stockage de sessionID dans l'URL. Quelqu'un peut accidentellement copier-coller le lien vers d'autres personnes, oublier de le censurer dans une capture d'écran ou laisser quelqu'un le rechercher, car il n'est pas marqué d'un astérisque comme les mots de passe.

De plus, si certains contenus sont protégés par mot de passe, en vous connectant, vous savez que c'est un secret. Si vous obtenez un lien, vous pouvez facilement l'oublier.

Une autre chose consiste à supprimer les privilèges des utilisateurs. Vous pouvez supprimer un utilisateur afin qu'il ne puisse plus se connecter, mais avec des liens, vous devrez tous les changer et envoyer à tous (sauf l'utilisateur supprimé) de nouvelles URL.

Je pense que ce n'est pas mal si ce ne sont que des images. Mais si ce sont des images que vous n'aimeriez vraiment, vraiment pas partager;) alors je vous suggère d'utiliser un mot aléatoire plus long, plus comme celui dave e présenté.

EDIT: Ajoutez? DO_NOT_SHARE_THIS_LINK à l'URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

C'est ce que fait par exemple Kongregate lors de l'intégration de jeux hébergés ailleurs (il met les informations d'identification d'authentification dans l'URL du cadre). BTW, Kongregate utilise également des liens d'accès invité pour les jeux non publiés, exactement comme vous le souhaitez.

Markus von Broady
la source
En fait, c'est bien pire que les ID de session, car les sessions expirent après un certain temps. Les moteurs de recherche récupérant un ID de session connecté finissent généralement par présenter un lien mort / session non connectée dans les résultats. Ou, si le serveur s'en fiche, il peut synchroniser la session de nombreux utilisateurs et lorsque l'un d'eux se connecte, ils le font tous. Quoi qu'il en soit, pas aussi mauvais qu'une URL connectée en permanence :-)
korkman
Bien sûr, c'est pire, et vous pouvez également vous souvenir de l'IP en session car vous devez d'abord vous connecter pour obtenir le sessid dans l'URL, puis vous pouvez détruire la session si l'IP a changé.
Markus von Broady