Ungesichertes Login

[juwi]

Hallo!

Mein Browser meldet gerade, das Login erfolge nicht über https gesichert. Eine solche Selbstverständlichkeit sollte doch eigentlich gewährleistet sein, wenn man einen solche Seite betreibt, oder?

[Leseesel]

Vor allem da es immer mehr unverschlüsselte öffentliche WLANs gibt und man seine Logindaten auf keinen Fall weiter geben darf, sehe ich das als echtes Problem an, falls es so ist.

http://www.onlinetvrecorder.com/v2/
scheint gänzlich unverschlüsselt,

https://www.onlinetvrecorder.com/v2/?go=home
ergibt:

Obwohl diese Seite verschlüsselt ist, werden die von Ihnen eingegebenen Informationen über eine unverschlüsselte Verbindung gesendet und können leicht von Dritten gelesen werden.

Sollen diese Informationen wirklich gesendet werden?

[Artemis1121]

Einigermaßen sicher wirds nur, wenn man http komplett abschaltet.

1) Zielseite der Logindaten ist nicht https: Angreifer kann Logindaten einfach lesen
2) Eingabeseite der Logindaten ist nicht https: Angreifer ändert Ziel der Logindaten auf http
3) Beliebige Seite ist nicht https: Angreifer kann Cookie mitlesen und mitnutzen

Selbst die Downloadserver müssten alles https verschlüsseln, da sonst ein mitlesen der URLs und ein erzeugen von Traffic auf Kosten des Users möglich wäre.
Die aktuellen Server hätten vermutlich keine Chance die zusätzliche Last zu bewältigen.

Einfach nur die Logindaten via https zu senden löst das Problem leider nicht!

[Leseesel]

Mit beliebig hohem Aufwand lässt sich vielleicht einmalig ein bisschen Traffic verursachen -ok! Aber was hat der Angreifer großartig davon?

Alternativ: Mit einem Sniffer lassen sich auf einfachste Art und weise durch jeden Laien automatisiert alle Logins und Passworter mitlesen. Auch Google hat diese Daten von der halben Welt (Streetview-Fahrzeuge) auf seinen Festplatten, angeblich natürlich nur versehentlich. Das hat schon eine ganz andere Dimension.

[dmjr]

Die Downloads zu verschlüsseln wäre meiner Meinung nach übertrieben. Was allerdings Sinn machen würde: Alle Zahlvorgänge, Bannerbuchung und Passwortänderugen auf einen komplett verschlüsselten Subbereich auszulagern der einen seperaten Login erfordert.

[Cineatic]

Das Problem dürften hier auch die Kosten für ein Sicherheitszertifikat sein. Denn die belaufen sich im Jahr auf mehrere hundert Euro. Wenn man es von einem vertrauenswürdigen Institut kauft, was man ja nun machen sollte.

Und was würde dies bedeuten? ;)

[Leseesel]

Das Problem dürften hier auch die Kosten für ein Sicherheitszertifikat sein. Denn die belaufen sich im Jahr auf mehrere hundert Euro. Wenn man es von einem vertrauenswürdigen Institut kauft, was man ja nun machen sollte.

Und was würde dies bedeuten? ;)

Und warum genau ist es besser, den Loginprozess völlig unverschlüsselt zu übertragen, als das bereits vorhandene Zertifikat auch dafür zu nutzen?

[Artemis1121]

Noch einmal, nur alleine das Login zu verschlüsseln bringt GAR NIX!
Die Cookies sind kritischer und damit müßten alle Seiten verschlüsselt werden..

[Leseesel]

Noch einmal, nur alleine das Login zu verschlüsseln bringt GAR NIX!
Die Cookies sind kritischer und damit müßten alle Seiten verschlüsselt werden..

Cookies müssen auch nicht zwangsläufig das Login im Klartext enthalten. Das darf ruhig auch etwas verschlüsseltes sein.
Als nächstes müsste man dafür sorgen, dass OTR den eingeloggten Nutzer nicht sein Passwort zeigt und ohne das Passwort auch keine Passwortänderung erlaubt. Ein Sicherheitsfeature, das vermutlich die aller meisten Webdienste implementiert haben.

Und wenn man schon die ganze OTR-Seite verschlüsselt anbietet, warum dann nicht auch den Login? Wo ist der besondere Mehraufwand in Bezug auf die Serverauslastung?

[Artemis1121]

Das Login funktioniert auch mit https.. man muss nur in der post-url z.B. mit Firebug aus dem http ein https machen. Wäre für OTR kein Problem, aber es würde in keinster Weise die Sicherheit erhöhen. Ob ein Angreifer nun Klartext-Passwort und -Nutzernamen hat, oder den Cookie macht keinen Unterschied.
Und damit der Cookie verschlüsselt übertragen wird, muss die komplette Seite verschlüsselt sein (und dann kann man am Cookie das Secure Attribut setzen, damit dieser nicht auf unverschlüsselten Seiten übertragen wird).

Was zumindest ärgerlich ist, ist das der Login bei der https-login-Seite nicht verschlüsselt übertragen wird. Diese Post URL sollte definitiv angepasst werden, da stimme ich auf jeden Fall zu. Schön wäre es wenn bei diesem Cookie dann auch das Secure Attribut gesetzt wird(dann würde die Seite allerdings mit diesem Cookie nicht unverschlüsselt funktionieren). So hätte man zumindest die Wahl bewusst zu verschlüsseln.

Http-Loginseite -> https-Post-logindaten -> http-Seite ist hingegen imho Schwachsinn, da der Cookie weiterhin abfangbar ist und mit diesem alle Funktionen von OTR für den Angreifer nutzbar sind!

Alle Seiten für alle User zu verschlüsseln - was die beste Lösung des Problems wäre - bedeutet deutlich höhere Serverlast, da alle übertragenen Daten ver- bzw. entschlüsselt werden müssen. Und das meinte ich damit. Nen verschlüsselter Login kostet nicht viel, bringt aber auch nix. Alle Seiten verschlüsseln kostet viel Rechenleistung!


---

EDIT: das mit der http-post-url auf der https-seite poste ich mal einfach in die Fehlerliste!

[juwi]

Das mit dem unverschlüsselten Cookie ist ein guter Hinweis, und in der Tat sollte dieser nicht das Passwort im Klartext enthalten.
Vielleicht sollte man hier auch das Prinzip von Heise erwähnen, nach eine verschlüsselten Login den weiteren unverschlüsselten Verkehr nur an eine IP-Adresse zu senden. Das könnte bei den großen Übertragungen von OTR viel Prozessorleistung einsparen.

[Artemis1121]

Unter anderem wird bei jedem Seitenaufruf übertragen:
- Emailadresse im Klartext
- OTRID im Klartext
- Passwort gehasht (und höchstwahrscheinlich auch gesalzen)

Mit diesen Daten kann ein Angreifer einen Account problemlos nutzen und die einzige Möglichkeit dies zu ändern wäre alle Seiten SSL zu verschlüsseln.

Dies wäre optional zumindest schon möglich, wenn der https-login auch die Logindaten nach https posten würde, aber um alle User zu schützen müsste die Seite auf http komplett abgestellt werden und dafür würde die Rechenleistung der aktuellen Server die jetzt ja schon manchmal in die Knie gehn wahrscheinlich nicht ausreichen, aber das kann nur ein Admin beantworten..

[Leseesel]

Ich wäre dafür, dass man die https-Seite repariert und es wahlweise macht. Also normal gehen alle über die normale Seite, aber diejenigen, die den dringenden Bedarf verspüren, weil sie z.B. gerade im Krankenhaus sind und dort nur das WLAN nutzen können, können auch https nutzen. Irgendwo dann vielleicht noch der Hinweis, dass dies möglich ist.

[The-Dude]

Das Problem dürften hier auch die Kosten für ein Sicherheitszertifikat sein. Denn die belaufen sich im Jahr auf mehrere hundert Euro. Wenn man es von einem vertrauenswürdigen Institut kauft, was man ja nun machen sollte.

Und was würde dies bedeuten? ;)

Moin,

das stimmt so nicht ganz. Ich kann SSL Zertifikate von vertrauenswürdigen Ausstellern wie z.B. Thawte über unsere Firma (Provider ;-) ab 59 EUR/Jahr inkl. MwST. anbieten. Wildcard Zertifikate oder spezielle wie z.B. EV Zertifikate bewegen sich natürlich im XXX Bereich. Bei Interesse kann OTR gerne auf mich zukommen um das passende Zertifikat zu einem günstigen Preis zu finden und zu beraten. In diesem Fall bitte kurze PM an mich.

Als Hinweis, selbst ausgestellte und/oder kostenlos generierte Zertifikate bereiten evtl. Probleme mit der Vertrauenswürdigkeit sowie mit der Browserkompatibilität.

Viele Grüße

Dude

[Artemis1121]

Das existierende Zertifikat sieht doch gut aus, abgesehen davon, das es in 18 Tagen abläuft! :)

http://www.ssltest.net/onlinetvrecorder.com

[juwi]

Jetzt sieht es so aus, daß auch das Login über https gesichert ist, jedenfalls beschwert sich mein Browser nicht mehr.

[Artemis1121]

Ja, der Login wird verschlüsselt übertragen(auf verschlüsselter und unverschlüsselter Login-Seite), danach wird man allerdings auf http umgeleitet, so dass der Cookie direkt unverschlüsselt übertragen wird.

[Ralgert]

Alternative: https://www.cacert.org/