Question:
Les URL aléatoires sont-elles un moyen sûr de protéger les photos de profil?
owenfi
2014-05-19 01:24:18 UTC
view on stackexchange narkive permalink

Je voudrais passer des identifiants utilisateur séquentiels aux identifiants aléatoires, afin de pouvoir héberger des photos de profil publiquement, c'est-à-dire example.com/profilepics/asdf-1234-zxcv-7890.jpg .

Combien de temps les ID utilisateur doivent-ils durer pour empêcher quiconque de trouver des photos d'utilisateurs pour lesquelles le lien ne lui a pas été fourni?

16 lettres minuscules et de zéro à neuf offrent-ils une complexité raisonnable? Je me base sur 36 16 = 8x10 24 , une estimation prudente de 10 milliards de comptes d'utilisateurs réduit l'espace à 8x10 14 . À 1000 suppositions / seconde, il faudrait 25 000 ans pour trouver un compte. Sauf si je néglige quelque chose.

Eh bien, AWS fait ce genre de chose avec les fichiers utilisateur (nom aléatoire de 128 bits si je me souviens bien), vous pouvez donc supposer que c'est "suffisamment sûr", comme indiqué dans la pratique.
@owenfi Générez des valeurs de 128 bits et plus et tout va bien. Pour votre cas et votre application spécifiques, c'est plus que suffisant.
De toute façon, cela n'a aucun sens. Mots de passe, jetons, certificats, quelle sécurité n'est pas exactement par l'obscurité? Le dicton utilisé correctement s'applique à la méthode et non au secret.
Cette question équivaut à "Comment choisir un mot de passe sécurisé?". Je ne vois aucune différence.
C'est la même chose que la vulnérabilité de dropbox de la semaine dernière (https://security.stackexchange.com/questions/57436/what-was-the-security-vulnerability-behind-box-and-dropbox-and-whats-different / 57437 # 57437) - ce sont des URL publiques, elles peuvent être explorées et seront indexées, l'utilisateur peut partager / publier ses propres liens, etc.
Vous interprétez mal l'expression «la sécurité par l'obscurité». L'expression est utilisée pour décrire quand les _algorithmes_ utilisés pour sécuriser une ressource ne sont pas divulgués publiquement, donnant la fausse impression qu'ils sont sécurisés parce que personne à l'extérieur, par exemple, l'entreprise ne sait comment ces algorithmes fonctionnent. Avoir une clé secrète avec une origine et une application connues (par exemple, une URL aléatoire) dans l'algorithme n'est pas une sécurité par l'obscurité. Toute sécurité repose sur des secrets partagés; cependant, les URL peuvent être une mauvaise idée en raison du nombre de façons dont elles peuvent fuir.
@damon Je recherche une référence sur le site Web d'Amazon pour les URL de noms aléatoires de 128 bits, pourriez-vous s'il vous plaît fournir un lien?La vôtre est la seule référence que j'ai pu trouver jusqu'à présent après quelques recherches sur Google
Sept réponses:
Mark
2014-05-19 02:33:03 UTC
view on stackexchange narkive permalink

Cela dépend entièrement de ce que vous entendez par «sûr».

Si votre seul souci est qu'un attaquant devine des URL, alors 16 alphanumériques donnent environ 8 000 000 000 000 000 000 000 000 d'adresses possibles, ce qui est suffisant pour éviter de deviner au hasard - pour qu'un attaquant ait 50% de chances de trouver ne serait-ce qu'une seule image sur un site comptant un millier d'utilisateurs en un an, il aurait besoin de faire 100 billions d'essais par seconde, suffisamment de trafic pour faire tomber même quelque chose comme Amazon ou Google. .

Mais il existe d'autres moyens de fuite d'URL: des personnes les mettant dans des e-mails ou des articles de blog, des robots d'exploration trouvant des pages que vous n'avez pas sécurisées de manière adéquate, etc. Si vous avez vraiment besoin de protéger quelque chose, vous devez le placer derrière le même type de sécurité que le reste de votre site Web.

Personnellement, pour créer des URL difficiles à deviner, j'utiliserais des GUID / UUID. L'espace de recherche est absurdement énorme, vous n'avez pas besoin de coordonner la génération entre plusieurs serveurs, et la plupart des langues ont des routines standard pour les gérer.

La plupart des générateurs GUID ne garantissent pas des sorties imprévisibles. Vous devez donc générer 16 octets aléatoires à partir d'un CSPRNG au lieu d'utiliser des générateurs GUID standard.
Alors c'est un générateur de GUID / UUID bogué ...
@R .. pas nécessairement, cela dépend de votre [GUID] (https://en.wikipedia.org/wiki/Globally_unique_identifier#Sequential_algorithms) ou de [UUID implementation] (https://en.wikipedia.org/wiki/Universally_unique_identifier# Version_1_.28MAC_address.29). Cependant, je pense que * la plupart * de nos jours sont probablement aléatoires, mais peut-être pas * sécurisés * aléatoires (donc probablement prévisibles). La chose à retenir est que le but est "unique", pas "imprévisible", donc les bonnes implémentations satisfont "unique", et seulement peut-être sont aussi "imprévisibles".
Je dirais qu'il est impossible de satisfaire le critère "unique" sans satisfaire également "imprévisible" car un autre générateur "UUID", hors de votre contrôle, sur un autre système pourrait finir par générer un UUID identique (le rendant ainsi non unique) avec non -probabilité négligeable, s'il connaît votre algorithme de génération et choisit de tenter de le heurter de manière malveillante. Un UUID est seulement "UU" (et même encore, seulement statistiquement) s'il est imprévisible.
@R .. Les UUID ne sont pas des entités cryptographiques, ils ne sont uniques que dans la mesure où tout le monde accepte de les faire. La bonne chose est que pour toute application qui utilise les UUID comme prévu, peu importe si quelqu'un d'autre copie ou réutilise les UUID d'une autre manière, ce ne serait un problème que si les deux systèmes doivent ensuite partager des données. Si vous devez partager des données avec quelqu'un qui essaie intentionnellement de briser le système UUID, vous avez probablement de plus gros problèmes.
@R .. Vous vous trompez; Les GUID sont documentés comme une source * d'unicité *, et non de * caractère aléatoire *. Un GUID de type 4 est aléatoire, mais ce caractère aléatoire n'est pas garanti comme étant la force cryptographique et en pratique ce n'est pas le cas. Plus généralement: ** Les GUID n'ont pas été conçus pour faire partie d'un système de sécurité; leur utilisation dans un système de sécurité est une utilisation «hors étiquette» et est donc une très mauvaise idée **.
@R ..: Le système GUID n'est délibérément ** pas ** conçu pour résister à une utilisation malveillante. C'est comme un panneau d'arrêt; un panneau d'arrêt ne vous * oblige * pas à vous arrêter. Si quelqu'un veut l'ignorer et traverser une intersection parce qu'il est malveillant et aime causer des accidents, le panneau d'arrêt ne va pas l'arrêter. Les GUID sont un système * coopératif * pour garantir l'unicité; toutes les parties sont présumées non hostiles.
La meilleure solution consiste à utiliser un service de générateur de GUID _unique_ combiné à une chaîne _random_ de longueur fixe, puis de prendre la sortie d'une fonction de hachage forte et de l'utiliser comme référence d'objet unique à cet objet. c'est-à-dire: `sha256 (guid () + random_chars (32)). hexdigest ()`.
@NaftuliTzviKay Cela ne fait rien d'autre que de mélanger un peu les données, vous avez besoin que la chaîne aléatoire soit cryptographique aléatoire, et si c'est le cas, un algorithme de hachage ne l'améliore pas. Utilisez simplement le nombre aléatoire cryptographique au fur et à mesure que votre CSRNG le délivre, lancer un GUID dans le mélange ne sert à rien.
Le GUID fournit l'unicité, tandis que la chaîne aléatoire fournit le caractère aléatoire. Les deux sont essentiels pour la solution à la question d'OP.
@NaftuliTzviKay: Et puis le hachage élimine l'unicité. (La collision de hachage a une probabilité faible mais non nulle, tout comme les sorties PRNG de crypto-force)
Les UUID @BenVoigt: ne sont pas garantis comme étant uniques! Je ne pense pas que «l'unicité» de l'ID proposé par Naftuli Tzvi Kay serait (considérablement) pire que l'unicité des UUID. Certains types d'UUID contiennent MD5 ou SHA-1 a une adresse MAC ou un nom de domaine.
@basic, il existe de nombreux types d'uuids différents et non, il n'y a absolument aucune raison pour que l'attaquant doive connaître votre système pour que l'un d'entre eux soit vulnérable - en particulier pas pour les UUID de type 4 ...
@Basic Si le problème est "rendre les URL impossibles à deviner", alors non, il n'y a pas de problème beaucoup plus grave que "le système rend les URL devinables de manière triviale" (sinon, pourquoi ne pas affirmer que les nombres séquentiels sont bien aussi?). Et oui, certains UUID utilisent des parties d'une adresse MAC qui aident évidemment exactement jusqu'à ce que l'attaquant puisse obtenir un seul GUID (ce qui est à peu près garanti), après c'est un simple horodatage qu'il doit deviner. Votre affirmation selon laquelle il faudrait des années à un «attaquant sans connaissance de votre système» pour trouver une collision est tout simplement erronée.
@pabouk: Un générateur UUID est garanti de ne jamais renvoyer la même valeur deux fois, peu importe le nombre de fois qu'il est appelé ou par qui. Vous pouvez certainement faire une copie au niveau du bit d'un UUID et créer une collision de cette façon, ou modifier l'état interne d'un générateur pour briser la garantie, mais cela ne concerne pas cette discussion.
@BenVoigt: Non, vraiment, ils ne sont pas garantis d'être uniques. En principe, cela n'est pas possible si vous disposez de plusieurs générateurs UUID discrets qui ne partent pas d'un identifiant unique. Par exemple, les adresses MAC doivent être uniques, mais en fait elles ne le sont pas. Voir: http://stackoverflow.com/q/1155008/320437
@Basic Umn .. avez-vous réellement vérifié comment les GUID / UUID sont générés? Ce calcul suppose que tous les bits sont générés aléatoirement par un générateur aléatoire sécurisé, ce qui est complètement faux. Ce type calcule essentiellement les chances d'une collision en supposant un pirate non malveillant, ce qui est complètement différent. Par exemple, les UUID de type 4 sont générés généralement à l'aide d'un générateur aléatoire non sécurisé. Après avoir vu certains UUID générés, il est alors très, très simple de deviner la séquence. Les GUID basés sur un MAC sont générés à l'aide d'un * horodatage * - vous ne voyez vraiment pas à quel point il est facile de deviner les valeurs possibles?
@Voo J'ai l'impression d'être dans une conversation circulaire ici ... Regardons mon premier commentaire "En prenant un attaquant sans connaissance de votre système, il pourrait générer des GUID pendant des années et ne pas entrer en collision avec celui que vous avez créé". L'élément clé ici étant "Aucune connaissance". Comme je l'ai dit _au début_ S'ils savent quand et sur quoi il a été généré, c'est une autre question. Puisque vous pensez que je me trompe et que vous répétez le dogme sans comprendre, accepterons-nous de ne pas être d'accord et de supprimer tous ces commentaires qui n'ajoutent de valeur à personne?
@Basic La définition d'un cryptosystème sécurisé n'a pas changé depuis le 19ème siècle (principe de Kerckhoff). Il est sécurisé si tout sauf la clé est de notoriété publique. La clé dans notre cas est l'URL. Si je peux augmenter mes chances d'accéder énormément à un fichier simplement en ayant une bonne estimation du moment où il a été créé (ou en créant moi-même quelques fichiers et en observant le modèle pour déterminer la graine du PNRG non sécurisé, alors je peux itérer à travers tous les fichiers du système!), le système n'est pas sécurisé. Je ne vois tout simplement pas le point de discorde ici.
@Voo Et je ne vois pas que le fait de ressasser les mêmes phrases à plusieurs reprises ajoute en aucune façon de la valeur à cette réponse ... Si vous voulez en discuter, mon adresse e-mail est sur mon profil. [xkcd] (http://xkcd.com/386/)
iHaveacomputer
2014-05-19 06:02:43 UTC
view on stackexchange narkive permalink

Ce n'est peut-être pas la réponse à votre question, mais si vous souhaitez "masquer" l'emplacement de vos photos de profil sur un site Web, vous pouvez simplement intégrer l'image en tant qu'URI de données. Vous pouvez encoder en base64 l'image sur votre serveur et incorporez la chaîne sur votre site Web, au lieu d'exposer les chemins des images.

voir http://css-tricks.com/data-uris/ et http: / /css-tricks.com/examples/DataURIs/ pour une description et une démo.

Les URI de données @FaridNouriNeshat, ne sont pas limités à 2000 caractères comme le sont les URI http. Si vous devez prendre en charge Internet Explorer 8 ou une version antérieure, [la limite est de 32 Ko] (https://en.wikipedia.org/wiki/Data_URI#Web_browser_support); si vous pouvez exiger IE9 ou une version ultérieure, il n'y a pas de limite.
@Mark Vous avez raison. Désolé, je confondais cela avec une autre méthode.
Cela pose un problème: la bande passante. Les caches ne peuvent pas fonctionner ici, vous finissez donc par envoyer la même image de 30 Ko plus souvent, ce qui se traduit par de l'argent et des performances.
Holy fume, c'est cool quand on le demande!
Voo
2014-05-19 19:56:25 UTC
view on stackexchange narkive permalink

Puisque vous avez déjà parlé de Dropbox, je pense que nous pouvons donner au moins une raison pour laquelle cela est une mauvaise idée:

Dropbox désactive les anciens liens partagés une fois que les déclarations de revenus se retrouvent sur Google

La faille, qui serait également présente sur Box, affecte les fichiers partagés contenant des hyperliens. "Les utilisateurs de Dropbox peuvent partager des liens vers n'importe quel fichier ou dossier dans leur Dropbox", a noté la société hier en confirmant la vulnérabilité:

Les fichiers partagés via des liens ne sont accessibles qu'aux personnes qui ont le lien. Cependant, des liens partagés vers des documents peuvent être divulgués par inadvertance à des destinataires non désirés dans le scénario suivant:

  • Un utilisateur de Dropbox partage un lien vers un document contenant un lien hypertexte vers un site Web tiers.
  • L'utilisateur, ou un destinataire autorisé du lien, clique sur un lien hypertexte dans le document.
  • À ce stade, l'en-tête du référent révèle le lien partagé d'origine vers le site Web tiers.
  • Une personne ayant accès à cet en-tête, comme le webmaster du site Web tiers, pourrait alors accéder au lien vers le document partagé.

En gros, il est trop facile pour les URL de fuir par inadvertance compte tenu du nombre d'utilisateurs qui les utilisent. Si vos utilisateurs sont informés à ce sujet et évitent ces problèmes, je suppose que c'est raisonnablement sûr, mais c'est une hypothèse importante à faire.

Merci, c'est un très bon point à garder à l'esprit pour ce sujet. Dans mon cas, il ne devrait être utilisé que via une application de manière privée, il est donc très peu probable que l'utilisateur moyen obtienne l'URL pour la partager en premier lieu (à moins de procéder à une ingénierie inverse de l'API).
@owenfi Dans ce cas, je pense que nous pouvons considérer cela raisonnablement sûr en supposant que vous utilisez un espace d'adressage suffisamment grand et un algorithme aléatoire sécurisé pour créer l'URL.
L'article cité par Voo contenait un lien vers un autre article encore plus approprié à la question: http://www.theregister.co.uk/2011/05/08/file_hosting_sites_under_attack/ "En 2011, les chercheurs ont constaté qu'il était possible d'accéder au partage fichiers en devinant les URL. "
@WGroleau Il convient de souligner que dans ce lien, tous les exemples donnés sont des systèmes qui sont d'une manière ou d'une autre cassés. Aucun des systèmes défectueux n'utilisait un grand espace de recherche combiné à un générateur aléatoire sécurisé. Je veux dire vraiment .. URL séquentielles? Je trouve donc cela moins applicable que le lien donné qui montre une faille inhérente au système (pour certaines utilisations uniquement) et pas seulement des problèmes d'implémentations cassées. Bien que cela montre que les gens essaieront d'exploiter un tel système, alors mieux vaut s'assurer qu'il est sain!
R.. GitHub STOP HELPING ICE
2014-05-19 17:43:52 UTC
view on stackexchange narkive permalink

Les autres réponses sont généralement bonnes, mais une autre considération est le transport. Si vous utilisez du simple http ou tout autre protocole non chiffré (ou que vous envoyez les URL par e-mail), toutes les données que vous transmettez et recevez, y compris ces URL, doivent être considérées comme entièrement publiques du point de vue de la sécurité. Une grande partie (quelqu'un a des statistiques?) Des utilisateurs sont sur des points d'accès wifi publics sans cryptage et le scraping actif d'url / image de ces réseaux est courant.

Aha, j'avais oublié ça! Merci! Heureusement, dans le cas de mon service, SSL est appliqué.
Phil Perry
2014-05-19 22:27:27 UTC
view on stackexchange narkive permalink

Comme mentionné par d'autres, un URI pour une image spécifique fuira tôt ou tard, peu importe sa durée ou sa complexité. Si vous souhaitez restreindre l'affichage aux utilisateurs connectés, vous pouvez utiliser, par exemple, ... / image / profile.php? U = 12345 pour afficher l'image de l'utilisateur 12345 sans direct URI de la photo disponible pour être diffusée au grand public. On suppose que des personnes aléatoires (non connectées) ne récupéreraient rien de profile.php. Notez que rien n'empêche un utilisateur connecté d'enregistrer cette image (surtout si elle est mise en cache) et de la transmettre. Il y a des choses qui peuvent être faites avec les en-têtes de contrôle du cache, etc., ou mettre l'image dans Flash, ou autre chose, mais si une image est visible sur le navigateur de quelqu'un, avec suffisamment de travail, il sera possible de la récupérer et de la sauvegarder. p>

Vous ne pouvez rien faire pour empêcher l'utilisateur de prendre une capture d'écran, par exemple! :)
@nicodemus13, c'est pourquoi les entreprises de streaming essaient d'appliquer la DRM au niveau matériel.
pyramids
2014-05-20 20:11:47 UTC
view on stackexchange narkive permalink

Le problème avec votre schéma est que les nombreux utilisateurs de vos URL ne devineront probablement pas tous que celles-ci contiennent des informations sensibles. Et une partie de ce problème est que vous n'avez probablement aucune idée de la taille de la base d'utilisateurs; pour ces URL, les utilisateurs incluent

  1. Les personnes que vous considérez comme des utilisateurs.

  2. Leurs plugins / addons / extensions de navigateur.

  3. À peu près tout contenu tiers sur votre site (publicités, analyses, plugins sociaux, ...) est susceptible, d'une manière ou d'une autre, d'informer des tiers URL en question.

  4. Sites Web apparemment aléatoires qui voient l'URL comme URL de référence (savez-vous vraiment quels liens supplémentaires curieux vos utilisateurs évoquent dans votre site Web via des addons de navigateur?).

La preuve empirique est que les URL uniquement https annoncées comme équivalentes à un mot de passe sont indexées par Google à plusieurs reprises, par exemple dans le cas du portefeuille en ligne Bitcoin sans mot de passe Instawallet (notez qu'ils ont tellement failli à cela qu'ils ne se permettent même plus de se procurer un certificat SSL valide).

Merci, quelques très bons cas de bord soulignés ici. On dirait qu'avant de le déployer sur un site Web, je dois le mettre derrière auth. (Pour l'instant, c'est uniquement dans une application-api, donc les tiers seront limités quelque peu aux modules de mise en réseau, et peut-être aux outils tiers observant mon répertoire de documents.)
Les gens peuvent même entrer l'URL entière dans la barre de recherche Google, et donc divulguer l'URL à Google.
hax
2016-10-16 19:13:19 UTC
view on stackexchange narkive permalink

L'ajout de quelques points importants, comme tout le monde a répondu ci-dessus, semble avoir manqué certains d'entre eux.

  1. La probabilité d'exposer par inadvertance une URL est plus élevée que celle d'un mot de passe, car les gens savent que Le mot de passe est sensible.
  2. Les sites Web comme Facebook utilisent des URL CDN qui sont si complexes que personne ne peut deviner, mais pourtant du point de vue de la sécurité, elles semblent risquées car la révocation de l'accès est impossible lorsque l'utilisateur change le Paramètres de confidentialité. Certains sites Web, y compris ceux avec le stockage s3 d'Amazon Web Service dans le backend, utilisent une URL signée avec un horodatage qui sera validé périodiquement.
  3. Google Cache! Les moteurs de recherche sont susceptibles de parcourir les images prétendument privées. Faites une recherche avec dorks qui ne ramènerait que les résultats des CDN Facebook et vous serez étonné.
J'aime particulièrement le point 2. Il était utilisé dans le système «ami» maintenant disparu pour les images de profil.La perspective d'accès supprimé est une bonne chose à considérer (je suppose que ce n'est pas très différent de quelqu'un qui enregistre l'image).
@owenfi Je suis d'accord avec cela.Ce n'est pas très différent de l'enregistrement de l'image, mais la probabilité d'obtenir les détails de l'historique du navigateur, du cache, etc. est là.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...