Hoe serveer ik bestanden die zijn opgeslagen in de cloud

Ik beheer een webtoepassing die gebruikmaakt van Rackspace Cloud Hosting om gebruikersafbeeldingen en -bestanden op te slaan. Momenteel worden bij gebruik van gebruikerspagina's de echte koppelingen naar de bestanden in de cloud gebruikt. Mogelijk kan een gebruiker de bestanden van andere gebruikers bekijken door de bestandsnamen te raden. De bestandsnamen zijn versluierd met ongeveer 30 alfanumerieke cijfers, een beetje stil voelt dit niet goed.

Is mijn bezorgdheid geldig, en zo ja, hoe kan ik dit het beste oplossen?

1
Zou je je zorgen maken als iemand een 30 tekens alfanumeriek wachtwoord zou raden?
toegevoegd de auteur ceejayoz, de bron
Nee, dat zou ik niet doen. Maar ik ben er niet zeker van of het op deze manier doen een goed idee of een best practice is. Klinkt voor mij ontzettend veel als 'veiligheid door vergetelheid'. Wat op zichzelf niet slecht is; Ik weet alleen niet zeker of het genoeg is of dat het misschien op een betere manier kan worden gedaan.
toegevoegd de auteur Mauritz Hansen, de bron

1 antwoord

Ik denk dat het afhangt van de gevoeligheid van de informatie in de bestanden.

Om een ​​alfanumerieke bestandsnaam van 30 tekens te maken, uitgaande van 36 waarden per teken (alleen kleine letters plus 0-9), zijn mogelijke combinaties 36 ** 30:

48.873.677.980.689.257.489.322.752.273.774.603.865.660.850.176

4.887368e + 46 in wetenschappelijke notatie

Ervan uitgaande dat iemand je bestanden echt wil stelen en ze een botnet hebben met 200 computers, controleren ze gewoon de http-antwoordcodes voor elk bestand bij bijvoorbeeld 1.000 bestandsnamen een seconde per bot ... om te zeggen dat een tiende van de bestandsnamen zou duren:

(((36 ** 30)/10)/(1000 * 200)/60/60/24/365) = 774.887.081.124.576.000.274.650.435.593.838 jaar

(ongeveer)

Tenzij je aanvaller een echt vastberaden en goed uitgeruste regering is of zoiets, of echt heel erg ... geluk. Ik zou zeggen, maak je er geen zorgen over.


Aantal mogelijke combinaties in wetenschappelijke notatie:

  • kleine letters alleen voor alphn: (26 + 10) ** 30 = 4.887368e + 46
  • Hoofdlettergevoeligheid toevoegen, 26 + 26 + 10 verschillende tekens geven: 5.912221e + 53
  • 256-bits codering (ook de lengte van uw API-sleutel voor cloudbestanden): 1.157921e + 77
  • 128-bits codering: 3.402824e + 38
  • 56-bits (DES) -versleuteling: 7.205759e + 16

Ik weet dat in jouw geval je misschien 100.000 bestandsnamen hebt die je niet wilt dat mensen raden, terwijl met de codering er maar één antwoord is, dus zelfs als je 5 van de exponent afhaalt, ben je nog steeds daarboven boven de 128 bit-codering.


Als je je nog steeds zorgen maakt:

  • Maybe put the files in non-public cloud files containers, and serve them from the Cloud Server and force people to have > 30 character passwords :)
  • add more possibly character types (maybe uppercase+lowercase) .. and increase the length of the file names

Je zou '/' in de bestandsnamen kunnen gebruiken, zodat ze bij het downloaden nog steeds een mooie naam hebben. bv. /whgwg/4y345yh3hy/543hgwhb/nice_name.jpg

dus als je het downloadt, wordt het opgeslagen als nice_name.jpg en niet als een soort onleesbaar ding.


Let ook op de CDN-cache. Als u de public cloud-bestanden gebruikt, worden ze naar de CDN-knooppunten geduwd en daar in de cache opgeslagen. Dus stel dat Mary per ongeluk enkele landgeheimen uploadt, ze de CDN-knooppunten worden verwijderd, ze verwijdert haar upload, deze zal nog steeds beschikbaar zijn op de CDN voor wat je cachetijd voor de map ook is. Je kunt de CDN api gebruiken om het te wissen, maar daar zou ik niet op vertrouwen.

Eindelijk ... zorg ervoor dat uw cijfers niet te raden zijn, zoals niet oplopend .. zou totaal willekeurig moeten zijn.

4
toegevoegd
Wow matiu, bedankt voor het geweldige antwoord en veel nuttige informatie.
toegevoegd de auteur Mauritz Hansen, de bron
Goed punt, zal dit in gedachten houden.
toegevoegd de auteur Mauritz Hansen, de bron
Een ander ding dat ik bedacht ... zorg ervoor dat ze niet doorzoekbaar zijn op Google. Ik kan toch niet bedenken dat ze dat zouden zijn ... maar je weet maar nooit. Ze hebben misschien een stiekeme statecollector in chroom of zoiets. Ik heb mijn cloudbestanden bezocht en het kijkvenster in chrome uitgevoerd en geen externe verbindingen gevonden, dus waarschijnlijk wel goed, maar iets om in gedachten te houden.
toegevoegd de auteur matiu, de bron