Also bei diensten wie Dropbox wird bei Linkfreigaben schlicht gar kein Passwort angefordert und man wird auch darauf hingewiesen, dass jeder der diesen Link hat die Datei ansehen kann.
Da ist dann also völlig klar was Sache ist, während einem hier wirklich nur eine falsche Sicherheit sugeriert wird, die nicht vorhanden ist.
Diskutieren wir noch über eure vermeintliche SSL- Sicherheitslücke oder mittlerweile über Unzulänglichkeiten in den Beschreibungen/Tutorials/Anleitungen?
Ich denke, ich habe alles aufgeschrieben was zum Verständnis der Funktion beitragen kann. Auch zum Passwort. Du drehst dich mittlerweile nur weiter im Kreis, denn ich müsste dich fragen "Was meinst du mit falscher Sicherheit?" und du würdest mir wieder dein Uni-Beispiel schildern, wo du vergessen hast den Browsercache zu löschen. Und ich würde sagen, du bist da doch das vergessliche Sicherheitsrisiko. Und du würdest entgegen, wenn die Linkfunktion aber so wäre wie ich sie mir vorstelle dürfte ich vergesslich sein...
Und hier können wir bequem aus dem Kreis ausbrechen. Die Funktion ist nicht so wie du sie dir vorstellt. Jetzt weiß du es. Wenn du vergesslich bist, dann nutze sie nicht. Greife das nächste Mal per Benutzeranmeldung auf deine Nas zu, wenn du an der Uni bist.
Und ja: Unwissenheit schützt nicht vor Schaden.
Have fun! 
Gruß Dirk
Nein ich würde dir damit antworten, denn er hat es ganz gut beantwortet, denn genau das ist der Punkt.
Wenn ich aber dem User eine gewisse Sicherheit vermittele, in dem ich eine Passworteingabe erfordere, darf der User hoffen, dass das sicher ist.
Und es macht einfach keinen Sinn den Transportweg zu sichern, anschließend aber die Tür offen stehen zu lassen.
Wenn man auf den unverschlüsselten Link klickt, müsste man auf die Passwortabfrage verwiesen werden. Das wäre auch rein vom Aufwand kein großer Aufwand in der Umsetzung gewesen. Immerhin kommt zwischen dem von QNAP generierten Link noch eine Seite wo man dann auf den unverschlüsselten Link klicken kann. Bis dahin wird man auch wieder auf die Passwortabfrage verwiesen. Aber bei dem eigentlichen Link dann nicht mehr. Das ist einfach unlogisch und hätte sicher mit wenig Aufwand umgesetzt werden können.
Bitte? Was der frosch da geschrieben hat ist ohne jeden Zusammenhang zum Inhalt, außer dass auch er irgendeine Beschreibung kritisiert, die er auf englisch gefunden hat.
Wenn man auf den unverschlüsselten Link klickt, müsste man auf die Passwortabfrage verwiesen werden.
Nein, genau das will ich als Nutzer von Freigabelinks eben nicht. Dafür gibt es keinen Grund. Wenn du eine wiederholende Passwortabfrage brauchst, dann nutze eine Benutzeranmeldung + Passwortabfrage! Da ist alles so wie du es möchtest.
Keine Sorge, ich habe diese Freigabelinks noch nie wirklich genutzt und werde das ganz sicher auch zukünftig nicht, weil das zeug absolut Nutzlos ist.
Und ich gebs auf, denn wir kommen hier auf keinen gemeinsamen Nenner.
Etwas zu verschlüsseln, was am Ende doch frei zugänglich ist, macht für mich einfach keinen Sinn. Und einen richtigen Nutzen konnte mir bisher dafür auch keiner nennen.
Und ich gebs auf, denn wir kommen hier auf keinen gemeinsamen Nenner.
So ist es. Es liegt halt daran, dass wir unterschiedliche Erwartungshaltungen an die Funktion Freigabelinks haben.
Ich finde es ebenso, wenn ein Freigabelink mit Passwort geschützt ist, müssen alle Aktionen (Download, Ordner wechseln) in dieser Session geschützt sein
und durch schließen des Browserfensters bzw. verlassen der Seite die Session terminiert werden. Mit JavaScript ist dies möglich.
Da braucht man dann keine Cookies oder das Löschen des Browsercaches nicht.
Durch den ungeschützten Downloadadresse macht für mich das Passwort zu Beginn keinen Sinn.
Entweder man vergibt einem Freigabelink ein Passwort oder nicht, aber das muß dann auch konsequent bis zum Download bleiben.
Mit JavaScript ist dies möglich.
Ok?! Du vergisst offensichtlich, dass angelluck und Laribum hier eine Sicherheitsdiskussion führen wollen. Jetzt mit JavaScript zu argumentieren, würde so manchem Programmierer übelst aufstoßen. Aber bitte, nicht auch noch über Javascript diskutieren.
Noch einmal, das Passwort spielt bei den ganzen Freigabelinks eine untergeordnete Rolle. Es gibt keine Abhängigkeiten zu SSL. Ihr versucht hier einen Zusammenhang herbeizudiskutieren den QNAP nicht bietet. Es wird niemand zu einem Passwort gezwungen , es ist lediglich eine Option. Wenn du sie als nutzlos erachtest, dann nutze sie nicht.
Mir ist klar, dass dieses Thema mit SSL kaum noch etwas zu tun hat.
würde so manchem Programmierer übelst aufstoßen. Aber bitte, nicht auch noch über Javascript diskutieren.
AJAX baut auf JavaScript bzw. Java auf und dieses ist nach meiner Ansicht eine aktuelle Technik, um Webseiten dynamisch darzustellen.
Mir ist ebenso klar, das schlechte JavaScript-Programmierung auch Sicherheitslöcher öffnet.
Jedoch macht eine Passwortabfrage keinen Sinn, wenn der Download der Datei nicht Passwortgeschützt ist.
Ihr versucht hier einen Zusammenhang herbeizudiskutieren den QNAP nicht bietet.
Eben das ist das Problem, QNAP gibt den schwarzen Peter an den Benutzer weiter.
das Passwort spielt bei den ganzen Freigabelinks eine untergeordnete Rolle.
Dann hätte QNAP die Möglichkeit der Passwortabfrage gleich weglassen können.
Ich habe jetzt über einige Posts hinweg versucht darzustellen, wie QNAP sich die Freigabelinks gedacht hat. Lassen wir das Passwort noch ein paar Sätze lang aus dem Spiel:
Freigabelinks bieten einen direkten Zugriff auf Daten. Der Linkersteller als auch der Linkanwender müssen sensibel mit dem Link umgehen. Das Risiko, dass ein Dritter auf die Daten zugreifen kann, siehe Uni-Beispiel, ist gegeben. Es liegt aber in der Verantwortung des Link-Anwenders. Das Risiko muss der Linkersteller halt abwägen: Vereinfachte Abfrage gegen die Schusseligkeit seines Anwenders. Du möchtest das Risiko minimieren? Dann gib die Daten über Benutzerkennung und Passwort frei und du kannst den Zugriff sogar über die Systemprotokolle überwachen. Du willst noch mehr Sicherheit? Dann nimm doch noch die 2-Stufen-Verifizierung hinzu und sei glücklich! Jetzt kann der Dösbaddel namens Anwender sogar seinen Passwortzettel in der Uni vergessen!
Wozu aber braucht man dann noch einen Freigabelink mit Passwortfunktion wie ihr es euch vorstellt? Wozu bitteschön? <-- Achtung, rheorische Frage! Ich erwarte keine Antwort, nur die Stirn in Falten legen und nachdenken. 
Dann hätte QNAP die Möglichkeit der Passwortabfrage gleich weglassen können.
Nöö, der Freigabelink muss ja irgendwie zum Anwender kommen. Der Weg durchs Internet kann mitunter unsicher sein. Hier hat QNAP den Profis wie Dropbox und Co mit dem Linkpasswort eine gute Option voraus.
Puh, habe jetzt lange genug die 
Meinung vertreten. Versucht es zu verstehen oder weiter zu ignorieren. Ist mir wirklich Schnuppe. 
Gruß Dirk
Ok, ich versuch es noch ein letztes Mal und versuch auch deine Beschreibung @phoneo etwas besser zu integrieren.
Da ein Link eher den Weg zu etwas darstellt, ersetz ich jetzt diesen Link durch eine Schatzkarte.
Die Schatzkarte pack ich jetzt in eine Box und verschließ sie, damit der Briefträger nicht ran kommt und schick Sie dem Empfänger.
Der Empfänger weiß jetzt wo der Schatz vergraben liegt und kann dort hinspazieren. Der Briefträger könnte es auch, weiß aber nicht wo er hin muss, weil er die Schatzkarte nicht hat.
D.h. was QNAP hier deiner Meinung nach zu verbergen versucht ist, der Ort wo etwas Gespeichert ist, und nicht die Sache die Gespeichert ist?
Trifft es das deiner Meinung nach eher? @phoneo
Ja, das trifft meine Vermutung genau, @angelluck. Habe das aber auch mehrmals schon beschrieben:
Ich sehe den verschlüsselten Link (in meiner vielleicht naiven Sichtweise) als einen "Tresor" für den unverschlüsselten Link an. Dieser Tresor hat mit der SSL-Übertragung selbst (mit meiner Sichtweise) nichts gemein.
Ich dagegen gehe davon aus, dass der passwortgeschützte Link lediglich als ahhörsicherer Transportschutz dient und QNAP nie etwas anderen geplant hat.
Wir brauchen aber keine weitere Diskussion über das Thema "Sicherheit" führen. QNAP nutzt diesen Begriff inflationär in verschiedensten Bereichen. Nehmen wir nur die Beschreibungen zu Speicherpools und Raids. Auch dort wird dem Nutzer eine Sicherheit in Anleitungen/Beschreibungen suggeriert, die nicht zu vertreten ist.
Ja ich hatte, das gelesen, aber wenn ich einen Schlüssel in die Box lege um eine Tür aufzuschließen, die anschließend offen sthet, ist das nun mal etwas anderes als wenn du eine Schatzkarte in eine Box legst um damit irgendwo einen Schatz zu finden.
Bei dir geht es darum etwas zuverstecken, bei mir geht darum etwas sicher aufzubewahren.
Wenn niemand einen Schatz findet, ist der Schatz auch sicher, aber jeder der ihn ohne Karte findet kann trotzdem darauf zugreifen.
Wohnhingegen eben jeder durch eine offene Tür spazieren kann ob er dafür nun einen Schlüssel hat oder nicht. Was es eben von Grund auf unsinnig macht, einen Schlüssel zum aufschließen einer offene Tür, zu verschicken macht.
Aber es gibt keine offene Tür!
Versucht es zu verstehen oder weiter zu ignorieren. Ist mir wirklich Schnuppe.
Schön, dass du in der Lage bist dich selbst zu zitieren.
In deinem Kopf gibt es wahrscheinlich nicht mal ein Haus für die Tür.
Mach doch einfach die Tür wieder zu (Browsercache löschen) und gut ist. 
Mach doch einfach die Tür wieder zu (Browsercache löschen) und gut ist.
Danke Michael! Ich denke, jetzt solltest wir es geschafft haben. Tür ist zu, gut is...
Ich habe mich jetzt durch die letzten drei Seiten gekämpft und es hat sich der Eindruck gefestigt, dass Dirk vor dem gleichen Problem steht, vor dem ich auch zu Anfang stand.
Er hat schlicht das Problem nicht verstanden.
Es hilft ungemein, wenn man sich das einfach einmal nachbaut.
Er hat schlicht das Problem nicht verstanden.
Du irrst.
Noch ein konstruierter Fall zum Nachbauen. Uni Geschichten sind beliebt, bleiben wir dabei:
Fritz Treuherzig sitzt an einem Uni-Rechner und meldet sich bei seiner Bank an, um den trostlosen Zustand seines Bankkontos abzufragen. Susi Liebreizend, die er schon immer heimlich verehrte, verwickelt ihn in ein Gespräch und die beiden gehen auf einen gemeinsamen Becher Kaffee in die Mensa. Das Browserfenster hat Fritz auf die Schnelle nur zugeklickt, schließlich wollte er bei Susi nicht sofort einen schlechten Eindruck erwecken. Während die beiden flirtend den Raum verlassen, nimmt Rudi Schlitzohr auf dem noch warmen Stuhl Platz. Als Fritz am nächsten Tag wieder zur Uni erscheint, erntet er von seinen Kommilitonen mitleidige Blicke und Getuschel. Das Warum wird im bald klar, als er eine Kopie seines Kontoauszugs am Schwarzen Brett findet . (Susi ist er übrigens los. Wie man sich erzählt, soll sie Rudi geheiratet haben.)
Und was lernen wir aus der Geschicht' : Den Browsercache vergisst man nicht!
Have fun! Dirk
