#61
|
||||
|
||||
Solange RTMPE als Kopierschutz angesehen wird, ist daran wohl nichts zu machen. Aber darum soll es ja hier jetzt gar nicht gehen.
Passwort hashen: Das machen viele Webseiten und Dienste so. Ich hoffe es zumindest. Bei uns hat das aber auch einen anderen Grund: Wir leiden aus dem Passwort des Nutzers über das hinzufügen von Salts und Co , und das anschließende Hashen quasi verschiedene passwörter ab. Das eine wird zum Server geschickt, und für die Authentifzierung sowie die Verschlüsselung der Daten zwischen Server und Webinterface genutzt. z.B. Wenn sich das Webinterface Kontoinformationen holt. Also für Daten WI->MYJD oder MYJD->WI Das andere wird gar nicht verschickt, sondern für die Kommunikation JD <--> WI genutzt. Wüsste der MYJD Server nun dein Passwort, könnte er damit die Schlüssel für JD <--> WI errechnen nund theoretisch mithören. Das betrifft auch alle anderen "Men in the Middle" (Grüße an Prism und co ;-P) Das vom Benutzer gewählte Passwort und die daraus abgeleiteten Schlüssel für die JD<->WI Kommunikation gehen NIEMALS über die Leitung. Selbst beim registrieren nicht. Nur das WI und der JD zu Hause kennen die. Die größte Schwachstelle sind vermutlich die statischen Webinterface Inhalte von my.jdownloader.org. Weil die NOCH nicht über eine https Verbindung laufen.
__________________
|
#62
|
|||
|
|||
Quote:
Quote:
Mein Hauptkritikpunkt bleibt jedoch weiterhin, dass der sogenannte Komfort eines (evtl. auch mal nicht erreichbaren) Service einfach unnötig ist. Ich will ein remote paar Links zum Download eintragen können, dazu hab ich in Pyload ein Webinterface. Könnte man den Zugriff dann nicht auch über ein Webinterface realisieren? Ich hab vom Programmieren null Ahnung, aber ich wunder mich, dass der Zugriff auf diese API durch ein Webinterface (das es für den alten JD ja schon mal gab) so ein Mehraufwand sein soll. Wenn vom offiziellen Team keiner Lust hat, könnte man ja vielleicht an nen Coder spenden, der so ein Webinterface zusammenbaut. Denn selbst mit Interface hätte der myjdownloader doch noch genug Zusatzfeatures, die zur Differenzierung als Premim-Service ausreichen. |
#63
|
||||
|
||||
OVH scheint gerade Probleme zu haben. Deswegen geht der Link nicht.
Quote:
Deinen Kritikpunkt "Der Komfort sei unnötig" kann ich so auch nicht stehen lassen. Für dich ist er unnötig. Für tausende andere ist er nötig, weil sie ohne diesen "Komfort" gar kein Webinterface nutzen könnten. Denk mal drüber nach, das die meisten Menschen da draussen, keine Ahnung von VPNs, Routern, Dyndns Diensten und Co haben. Die wissen in der Regel mit sehr viel Glück gerade mal was eine IP ist! Und all diese Leute, sind sehr dankbar für diesen "unnötigen" Komfort. Du bist mit deinem Know How Teil einer Minderheit die sich mit all dem Zeug auskennt. Die meisten Nutzer tun das leider nicht. Und trotzdem erwartest du von uns, dass wir alles nach deinen Wünschen umstellen, oder gar extra ein zweites Webinterface bauen? @karlheinz2013 Quote:
Etwas Java schadet nicht, die gängisten Webdeveloper Skills sollten aber natürlich da sein. Codeserver, Bugtracker usw stellen wir natürlich, und stehen auch mir Rat (und wenig Tat) gerne zur Seite.
__________________
|
#64
|
||||
|
||||
Quote:
Und ob z.B. auf my.jdownloader.org bereits im Browser (z.B. per JavaScript) bei der Anmeldung vorgehasht wird, so das auch dieses Passwort niemals bekannt wäre. Daher auch in meinem vorherigen Posting die Frage nach einer stärkeren Verschlüsselung und nicht erst wenn es absolut nötig wird. Unabhängig davon ob einige User nun die Implentierung verstehen oder nicht. Sicherheit ist ein schwieriges Thema und fortlaufende Arbeit. Siehe **External links are only visible to Support Staff** **External links are only visible to Support Staff** und leider auch **External links are only visible to Support Staff** **External links are only visible to Support Staff** Grundsätzlich bin ich dafür auch die Anmeldung mit OpenID zu ergänzen um möglichst Anonym zu sein. Gibt ja auch recht sichere anonyme Zahlungsarten für spätere Premiumdienste für beide Seiten.
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. |
#65
|
|||
|
|||
Quote:
Quote:
Quote:
|
#66
|
|||
|
|||
Quote:
Quote:
Das ist schon jetzt der Fall! Ich hatte das zuerst auch nicht kapiert, aber das ist bereits implementiert - siehe eines meiner obigen Postings (keine Sorge, ich hätte meine eigenen Postings auch nicht gelesen, die sind mir einfach zu lang geraten ). Hab' das inzwischen auch mal mit Firebug überprüft. Was da an Daten übertragen wird, sieht zumindest sehr nach "gehasht" aus. Ich muss wirklich zugeben, dass mir dieses Feature imponiert hat. Ich habe das bisher noch nirgends anderswo gesehen. Nicht bei Google, nicht bei Facebook. Keine Ahnung, ob sowas überhaupt irgendwo anders bereits angewandt wird. Quote:
In dem Zusammenhang übrigens auch sehr interessant "Perfect Forward Secrecy". Das könnte man dann ja bei der Gelegenheit (https) auch gleich noch aktivieren, wenn man sowieso schon dabei ist. heise.de/security/artikel/Zukunftssicher-Verschluesseln-mit-Perfect-Forward-Secrecy-1923800.html http://de.wikipedia.org/wiki/Diffie-...Csselaustausch Sehr faszinierend, dass es tatsächlich möglich ist, über einen öffentlichen Kanal, wo jeder mitlesen kann, einen Schlüssel auszutauschen, und trotzdem kann keiner der Mitlesenden den Schlüssel herausfinden. Für mich wirkt das immer noch wie Zauberei. Naja, aber ich schweife schon wieder vom eigentlichen Thema ab... Last edited by karlheinz2013; 02.08.2013 at 07:20. |
#67
|
|||
|
|||
Quote:
Quote:
Von dir erwarte ich gar nichts, nicht einmal vernünftigen Umgang mit konstruktiver Kritik oder die Einsicht, dass man sich durchaus über aus Vorversionen verschwundene Features ärgern kann. |
#68
|
|||||
|
|||||
Quote:
Quote:
Unser Server kann laut Doku TLS 1.2 (Nginx in aktueller Version). Deine Links lesen sich allerdings so als ob die meisten Browser damit noch Probleme hätten. Du scheinst dich da ja auszukennen. Wie machst du das bei 9kw? OpenID hat für mich jetzt echt nichts mit Sicherheit zu tun. Da kann ich den MyJD Account doch gleich mit Facebook koppeln ;-P So nebenbei: Der NUtzer ist nicht an my.jdownloader.org gebunden. Das zeug kann auch Lokal gestartet werden, oder vom JD verteilt werden, oder es findet sich ein Drittanbieter, der ein super Webinterface hinstellt, und das dann per Werbung oder so finanziert. (Vertrauen?) Theoretisch könntest du das webinterface auch auf **External links are only visible to Support Staff****External links are only visible to Support Staff** stellen. Quote:
Quote:
Quote:
@Titus: Dir zu antworten ist mir langsam zu doof. Man kann mir denke ich nicht vorwerfen dass ich mich hier nicht der Kritik stellen würde. Jeder hier schafft es den richtigen Ton zu treffen - trotz Kritik. Nur von deinen Beiträgen fühle ich mich doch arg "angefeindet". Liegt das an mir? In meinen Augen ist auch kein Feature "weg". Das neue WI kann deutlich mehr als das alte. Es ist auch num ein vielfaches sicherer als das alte. Du willst es wieder so wie früher. Da wirst du drauf hoffen müssen, dass sich jemand findet der coden kann, und das auch will.
__________________
|
#69
|
||||
|
||||
Quote:
Quote:
Prüfen des Servers kann man es mit einem einzigen Befehl: openssl s_client -connect my.jdownloader.org:443 Laut dem Check wird TLS v1.2 vom Webserver auch tatsächlich unterstützt. Grundsätzlich geht es mit der letzten nightly von Firefox und dürfte innerhalb von so 12-18 Wochen in der Stable landen (Version 25?) und auch Erweiterungen/Einstellungen um TLS 1.2 zu erzwingen, wenn der Webserver es mitmacht. Einzige was man machen könnte wäre ein Hinweis welche Methode der Webserver/Browser gerade nutzt, falls es technisch möglich ist. Meines Wissens ist nur TLS 1.2 als sicher genug anzusehen aber lieber eine niedrige Version/Methode von SSL/TLS als gar nichts. Man müsste auch mal schauen welche Lib/Methode JD2 da intern unterstützt. Hinzu kommt dann noch oft das Thema Zertifikate und viele kümmern sich um die Sicherheit beim Download eher wenig. Bisher leider eine unschöne Lösung bei den Browsern für mehr Sicherheit. Auch einige Libs können es bisher nicht oder nur eingeschränkt. Obwohl TLS 1.2 schon fast 5 Jahre alt ist. Denke das viele andere Clients wie Android es auch noch nicht können. Finde es tragisch das die bekannten Browser mit Thema Sicherheit oft werben und selbst nicht alles unterstützen bisher. Quote:
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. Last edited by thecoder2012; 19.10.2013 at 10:34. Reason: TLS check (befehl) hinzugefügt. |
#70
|
|||
|
|||
Hallo hightower 5,
ich wollte die nächsten Tage eine neue Version veröffentlichen. Kannst du mich mal wegen den Ladezeiten kontaktieren? 40 - 60 Sekunden bei Dir ist wirklich viel. PM oder Mail an info@pixelvalley.de |
#71
|
|||
|
|||
Quote:
Quote:
Dann lass es, die Standpunkte sind ja geklärt. Wir werden sehen, wie gut ihr bei einer Klientel, die OCHs ausgiebig nutzt, mit Premium-Funktionen punkten könnt. Die headless-Funktion ohne myjdownloader ist mir Geld wert, entweder geht das dann an euch oder denjenigen, den ihr es implementieren lasst (sollte sie wegen des Abstands zur Premium nicht allzusehr eingeschränkt sein). |
#72
|
||||
|
||||
Quote:
1. Theorie TLS und SSL SSL ist der Vorgänger bis Version 3 immer noch ein üblicher alter Standard. TLS gibt sich teilweise als SSL 3.1, 3.2 bzw. 3.3 aus und ist der Nachfolger von SSL als Standard so gesehen. Inzwischen in der verbesserten Version 1.2 wie in der RFC5246 (=> tools.ietf.org/html/rfc5246) aus dem Jahr 2008 zu finden. Version 1.0 ist bereits aus dem Jahre 1999 und unter RFC2246 zu finden. 2. Prüfen ob der Server TLS v1.2 unterstützt. Befehl: openssl s_client -connect my.jdownloader.org:443 Ausgabe enthält min. 2 Zeilen: SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Wir sehen das der Webserver es schonmal beherrscht und können damit die Dokumentation von Nginx bestätigen. Genutzt wird dabei AES mit 256-Bit und dem Hashalsgo SHA384. Anmerkung auch Lighttpd (z.B. 1.4.x oder höher mit ssl) als Beispiel beherrscht es. Der Cipher kann abweichend sein und wird in der Regel zwischen Client und Server ausgehandelt. 2. Browser und TLS v1.2 Die meisten Browser können inzwischen TLS v1.0 und v1.1 Bei v1.2 trifft dies bisher nur eingeschränkt zu. Bei 1.2 ist der Algo/Hash für den Geheimschlüssel flexibler bzw. stärker und kann nicht wie bisher mit MD5/SHA1 eine einfache Schwachstelle darstellen. 2a. Firefox / SeaMonkey Bis Version 24 muss es explizit aktiviert werden. (SeaMonkey 2.21) Über about:config unter dem Wert security.tls.version.max auf 3 setzen. Um TLS v1.2 zu erzwingen den Wert security.tls.version.min auf 3 setzen. Ab Version 25/26 sollte es per Default aktiv sein und auch _**External links are only visible to Support Staff** Quote:
2b. Chrome In aktueller Version 29/30 sollte TLS v1.2 vollständig aktiviert und unterstützt sein. Ältere Versionen sollten aus Gründen der Sicherheit sowieso nicht mehr eingesetzt werden. 2c. Internet Explorer In Version 11 sollte TLS v1.2 funktionieren und aktiviert sein. Ggf. muss es in 10 noch aktiviert werden. Empfehlenswert ist Internet Explorer 11 wegen enorm erhöhter Geschwindigkeit bei der Verarbeitung. TLS v1.0/1.1 deaktivieren im Internet Explorer => Internetoptionen => Erweitert => Nur das Kontrollkästchen TLS 1.2 aktivieren und 1.0/1.1 deaktivieren. 2d. Opera In Version 10-12 muss es in jedenfall explizit aktiviert werden. Bei der aktuellsten Version 17 ist es aktiviert und kann explizit auf TLS v1.2 eingestellt werden. Extras => Einstellungen => Erweitert => Sicherheit => Sicherheitsprotokolle 2e. Safari In der aktuellsten Version sollte es aktiviert und unterstützt sein. Allgemein sollte der Support seit Version 6 oder höher bestehen. Siehe auch: kuketz-blog.de/nsa-abhoersichere-ssl-verschluesselung-fuer-apache-und-nginx/ Anmerkung: Es ist möglich das sowohl Browser als auch Server in Einzelfälle noch Probleme mit TLS v1.2 haben und daher man v1.2 nicht unbedingt erzwingen sollte. Bei Problemen würde sonst die Verbindung abgebrochen und damit die Funktion "gestört". Immerhin hat man dann die größte Sicherheit bei dem Thema. Tja meine Bank hat schonmal kein TLS v1.2 im Webserver, nichtmal v1.1 sondern nur v1.0. :(
__________________
Join 9kw.eu Captcha Service now and let your JD continue downloads while you sleep. Last edited by thecoder2012; 18.01.2020 at 01:01. |
#73
|
|||
|
|||
wie siehts aus?
Hey Ho!
myjdownloader is nicht schlecht für die meisten recht gut aber was ist wenn ich eine userverwaltung benötige? mit dem alten webinterface konnte ich mir da etwas zusammenbasteln aber jetzt geht das nicht mehr. habt ihr da ne lösung für mich parat? |
#74
|
||||
|
||||
phispo:
Also grundsätzlich ist die my.jdownloader API ja auch offen, und kann erweitert werden. Was für eine Userverwaltung stellst du dir denn da vor?
__________________
|
Thread Tools | |
Display Modes | |
|
|