Ich kenne es als Secure-Token URL, maby gibt es einen anderen Namen da draußen. Aber ich denke du weißt es alle.
Es ist ein Teqniuque, das meistens angewendet wird, wenn Sie die Zustellung von Inhalten auf einen bestimmten Client beschränken möchten, den Sie zuvor mit einer bestimmten URL versehen haben.
Sie nehmen ein geheimes Token, verketten es mit der Ressource, die Sie schützen wollen, und wenn der Client diese URL auf einem Ihrer Server anfordert, wird der Hash aus den Informationen, die er aus der Anfrage und dem Hash wird verglichen. Wenn es gleich ist, wird der Inhalt geliefert, sonst wird der Benutzer auf Ihre Webseite oder etwas anderes umgeleitet.
Sie können auch einen Zeitstempel in die URL einfügen, um eine Zeit für die URL einzuplanen oder die IP-Adresse des Benutzers einzuschließen, um die Zustellung auf seine Verbindung einzuschränken.
Diese Technologie wird von Amazon (S3 und Cloudfront), Level 3 CDN, Rapidshare und vielen anderen verwendet. Es ist auch ein grundlegender Teil der HTTP-Digest-Authentifizierung, obwohl es einen Schritt weiter geht mit der Ungültigmachung von Links und anderen Dingen.
Hier finden Sie einen Link zu den Amazon-Dokumenten , wenn Sie dies wissen möchten mehr.
Nun ist meine Sorge bei dieser Methode, dass wenn eine Person einen Token Ihrer Links knackt, der Angreifer Ihren Token-Klartext erhält und jede URL in Ihrem Namen selbst signieren kann.
Oder, im Falle von Amazon, greifen Sie auf Ihre Dienste in einem administrativen Bereich zu.
Zugegeben, der String ist hier ziemlich lang. Und Sie können eine Menge Daten einfügen oder die Daten auf eine Mindestlänge zwingen, indem Sie der Anfrage einige unnötige Daten hinzufügen. Maby einige Pseudovariable in der URL, die nicht verwendet wird, und füllen Sie es mit zufälligen Daten.
Deshalb sind Brute-Force-Angriffe, um das sha1 / md5 oder was auch immer Sie Hash verwenden, ziemlich hart zu knacken. Aber das Protokoll ist offen, Sie müssen also nur die Lücke füllen, in der sich das geheime Token befindet, und den Rest mit den Daten füllen, die aus dem Request bekannt sind. UND heute Hardware ist super und kann md5s mit einer Rate von mehreren zehn Megabyte pro Sekunde berechnen. Diese Art von Angriff kann auf eine Computing-Cloud verteilt werden und Sie sind nicht auf "10 Versuche pro Minute durch einen Login-Server oder so" beschränkt, was Hashing-Ansätze in der Regel ziemlich sicher macht. Und jetzt kannst du mit amazon EC2 sogar die Hardware für kurze Zeit mieten (besiege sie mit ihren eigenen Waffen, haha!)
Also, was denkst du? Haben meine Bedenken eine Grundlage oder bin ich paranoisch?
Allerdings
Ich entwerfe gerade eine Objektspeicher-Cloud für spezielle Bedürfnisse (integrierte Medientranscodierung und spezielle Liefermethoden wie Streaming usw.).
Jetzt hat level3 einen alternativen Ansatz zur Sicherung von Token-URLs eingeführt. Es ist derzeit Beta und nur für Kunden, die es ausdrücklich anfordern. Sie nennen es "Proxy-Authentifizierung".
Was passiert ist, dass der Content-Delivery-Server eine HEAD-Anfrage an einen Server stellt, der in den Einstellungen Ihres (des Kunden) angegeben ist und die Benutzeranfrage imitiert. Daher wird derselbe GET-Pfad und IP-Adresse (als x_forwarder) übergeben. Sie antworten mit einem HTTP-Statuscode, der dem Server mitteilt, ob er mit der Inhaltsübermittlung einverstanden ist oder nicht.
Sie können auch einen sicheren Token-Prozess in diesen einführen, und Sie können auch weitere Einschränkungen vornehmen. Wie lassen Sie eine URL nur 10-mal oder so angefordert werden.
Es ist offensichtlich mit viel Aufwand verbunden, weil zusätzliche Anfragen und Berechnungen stattfinden, aber ich denke, es ist vernünftig und ich sehe keine Vorbehalte. Hast du?
Sie könnten Ihre Frage im Grunde neu formulieren zu: Wie lange ein geheimer Token benötigt wird, um sicher zu sein.
Um dies zu beantworten, berücksichtigen Sie die Anzahl der möglichen Zeichen (alphanumerisch + Großbuchstaben ist bereits 62 Optionen pro Zeichen). Zweitens stellen Sie sicher, dass das geheime Token zufällig ist, und nicht in einem Wörterbuch oder etwas. Wenn Sie zum Beispiel ein geheimes Token von 10 Zeichen Länge nehmen würden, würde es 62 ^ 10 (= 839.299.365.868.340.224) Versuche zur Bruteforce (Worst Case; der durchschnittliche Fall wäre die Hälfte davon natürlich) dauern. Ich hätte keine Angst davor, aber wenn du es bist, könntest du immer sicherstellen, dass das geheime Token mindestens 100 Zeichen lang ist, in diesem Fall braucht es 62 ^ 100 Versuche, Bruteforce zu erreichen (was eine Anzahl von drei Zeilen in mein Terminal).
Zusammenfassend: Nehmen Sie einfach ein Token groß genug, und es sollte ausreichen.
Natürlich bietet die Proxy-Authentifizierung Ihren Kunden zusätzliche Kontrolle, da sie viel direkter steuern können, wer schauen kann und nicht, und dies würde zum Beispiel auch das E-Mail-Nicken verhindern. Aber ich denke nicht, dass das Bruteforcing bei einem Token, der lange genug ist, ein Problem sein muss.
Es heißt MAC , soweit ich das verstanden habe.
Ich verstehe nicht, was mit Hashes falsch ist. Einfache Berechnungen zeigen, dass ein SHA-1 Hash, 160 Bits, uns sehr gut schützt. Z.B. Wenn Sie eine super-duper Wolke haben, die 1 Milliarde Milliarden Versuche pro Sekunde macht, brauchen Sie ~ 3000 Milliarden Milliarden Jahre, um sie brutal zu erzwingen.
Sie haben viele Möglichkeiten, ein Token zu sichern: