Passwörter

Von Karim Geiger — unter Ideas, Internet am 30.05.2016

Cover

Wer kennt sie nicht? Passwörter wie “123456”, “password” und “qwerty”. Dass das unsicher ist, muss man keinem sagen. Trotzdem werden sie so häufig verwendet, wie sonst keine.

Wieso? Ganz einfach. Weil den meisten Leuten Passwörter egal sind. Der Aufwand, sich ein komplexes Passwort zu merken, ist zu hoch, und die Daten, die sie schützen, sind es – ihrer Meinung nach – nicht wert geschützt zu werden. Ergo werden unsichere Passwörter verwendet, meist sogar eines für alle Dienste, bei denen man sich registriert.

Ein weiteres Problem bei den Passwörtern ist, dass Maschinen einfach viel zu gut im Raten sind. Früher war ein Schloss mit ein paar Zahlenkombinationen recht sicher, weil es Monate dauern würde jede Kombination auszuprobieren, und man dafür im Besitz des Gegenstands sein musste. Aber Computer sind dabei selbstverständlich schneller. In ein paar Minuten haben aktuelle Systeme einige Passwörter entschlüsselt. Und damit ist das Konzept des Passwortes meiner Meinung nach veraltet. Etwas Neues muss her.

Deswegen gibt es Two-Factor-Auth. Selbstverständlich bietet dieser Mechanismus einen weiteren Sicherheits-Layer, da nicht nur ein Passwort benötigt ist, sondern auch noch ein Einmalpasswort, welches meist per E-Mail oder SMS zugesandt wird. Toll! Zwei Passwörter, die man eingeben muss! Somit wird Two-Factor-Auth auch, sofern nicht Pflicht, nur von den Leuten verwendet, die sowieso schon ein sicheres Passwort vergeben. Gewonnen hat man dadurch also nicht wirklich viel, außer eine zusätzlich verschwendete Minute bei jedem Login.

Die Zeit ließe sich etwas verkürzen, wenn das Ganze per Push realisiert würde. Etwas, das für mich selbstverständlich ist. Ich verstehe einfach nicht, wieso Twitter die einzige Firma ist, die eine entsprechende Funktion implementiert hat. Während alle anderen Firmen einen meist sechsstelligen Code versenden, den man dann umständlich in die Login-Maske eintippen muss, sendet Twitter ganz einfach eine Benachrichtigung an das Smartphone mit der Meldung “xyz versucht, sich in Ihren Account einzuloggen. Zulassen? [Ja] [Nein]”. Klickt man auf Ja, wird die Login-Seite aktualisiert und man ist eingeloggt. Ein Wunder? Nein. Technik. Das Ganze ließe sich sogar per SMS in Verbindung mit einem Einmallink realisieren. Wieso also nicht? Ich verstehe es nicht.

Und dieser Punkt bringt mich einen Schritt weiter: Lasst das Passwort ganz weg. “OMG! IST DAS NICHT TOTAL UNSICH…” Nein. Lasst uns folgendes Szenario durchspielen: Ich habe ein unglaublich sicheres Passwort für meinen E-Mail-Account. Trotzdem wurde dieser gehackt und der Angreifer hat Zugriff darauf. Jetzt möchte er sich bei Service X anmelden. Das Passwort ist nicht das gleiche, und Two-Factor-Auth ist deaktiviert. Er drückt auf “Passwort zurücksetzen” und bekommt prompt eine Mail, mit der er das Passwort ganz einfach zurücksetzen kann. Der Angreifer kann sich nun bei Service X anmelden.

Jetzt dasselbe Szenario ohne Passwort, dafür aber mit Bestätigung des Logins via E-Mail: Der Angreifer, welcher Zugang zum E-Mail-Konto hat, gibt den Benutzernamen bei Service X ein, und bekommt einen Einmal-Link per E-Mail zugesandt, wodurch er sich nun einloggen kann. Im Endeffekt ist der Ablauf also genau gleich, nur muss der Angreifer nicht vorher noch ein neues Passwort vergeben. Sicherer wird es, wenn wir den Login-Request auf das Smartphone auslagern. Eine universelle App – ähnlich dem Google Authenticator – bekommt von Service X bei jedem Login-Request eine Push-Benachrichtigung, um den User zu fragen. Über das Interface der App kann man nun – nachdem man sich per Fingerprint authentifiziert hat – den Login bestätigen oder ablehnen. So muss der Angreifer Zugriff auf das Smartphone haben, und auch das gekaperte E-Mail-Postfach hilft hierbei nichts.

Die Vorteile:

  • Brute-Force-Angriffe auf Accounts können nicht mehr stattfinden
  • Gehackte Services können keine (gehashten) Passwörter mehr leaken
  • Social Engineering funktioniert nicht mehr
  • Der Nutzer kann keine unsicheren Passwörter mehr vergeben

Und wenn nicht jeder sein eigenes Süppchen kocht und es eine zentrale App dafür gibt:

  • Verliert man das Smartphone, könnte man sofort alle Zugriffe revoken.
  • Alle aktiven Logins können zentral in einer App eingesehen werden.

Die Nachteile:

  • (Smartphone benötigt/ließe sich aber auch per E-Mail oder SMS realisieren)
  • Wenn das Smartphone gehackt wird, und man es nicht merkt, ist es halt kacke
  • Obligatorische German Angst
  • Single Point of Failure

Anmerkung:

Ja, dieses Konzept ist nicht mit Two-Factor-Auth gleichzusetzen, da ein (gutes) Passwort selbstverständlich zusätzliche Sicherheit bietet. Allerdings wird Otto Normalverbraucher im Durchschnitt wesentlich seltener angegriffen werden können, da die Komponente des unsicheren Passworts einfach wegfällt. Selbstverständlich wäre es möglich, das Konzept entsprechend zu erweitern, um OPTIONAL noch ein Passwort pro Service zu fordern. Damit wäre man dann wieder bei Two-Factor-Auth, jedoch mit dem Passwort als optionalem Parameter. Das würde dann einen gewissen Basisschutz für alle bieten mit einer Option zur zusätzlichen Sicherheit für die Paranoiden unter euch.

Co-Anmerkung:

Dadurch würde auch die Anzahl der Promi-Leaks deutlich sinken, da diese meist nur durch Brute-Force-Angriffe oder Social Engineering stattfinden. Und selbstverständlich wären Hacker-Angriffe auf einzelne Services weniger dramatisch.

Bildquelle: Mr Wallpaper

E-POST – Security made in Germany

Von Karim Geiger — unter Deutschland, Internet am 06.05.2015

E-POST ist ein Service der Deutschen Post. Er sorgt dafür, dass wir Bürger nun endlich auch online Briefe verschicken können, welche rechtlich gesehen als Briefe anerkannt werden. Das bedeutet, wir können zum Beispiel Mietverträge oder Kündigungen online verschicken.

Zwar kostet ein Brief, welcher digital versandt wird, 62 Cent, aber hey, was tut man nicht alles für Sicherheit im Netz? Selbstverständlich können E-POST-Mails nur innerhalb des E-POST-Netzwerkes versandt werden. Versucht man eine unsichere, normale Mail an eine E-POST-Adresse zu senden, bekommt man folgende Meldung:

Screenshot from 2015-05-06 15:16:48

Mails können ausschließlich über die sichere Website der Post versandt werden. Unter https://portal.epost.de ist dieses zu finden. Überprüft man das ganze dann mal mit einem SSL-Server-Test, stellt man jedoch erschreckendes fest. Die ach so sichere Website verwendet RC4 als Verschlüsselungstechnik, welche seit Februar ganz offiziell als knackbar gilt, da sie schlicht veraltet ist. Im RFC wird sogar ausdrücklich verboten, diese für gesicherte Verbindungen über TLS zu verwenden.

Natürlich habe ich daraufhin die Post per Mail kontaktiert, um sie darauf hinzuweisen. Folgenden Text habe ich versendet:

Sehr geehrte Damen und Herren,
während der Verwendung Ihres E-Post-Dienstes stellte ich fest, dass die Übertragung zwischen portal.epost.de und mir über ein veraltetes, mittlerweile unsicheres Verschlüsselungssystem erfolgt.
Im Februar diesen Jahres wurde das von Ihnen verwendete RC4 offiziell durch RFC 7465 ( https://tools.ietf.org/html/rfc7465 ) als unsicher erklärt und die Verwendung im Zusammenspiel mit TLS verboten.
Ich würde mich über eine Stellungnahme zu dem Thema von einem Ihrer Sicherheitsbeauftragten sehr freuen.
Mit freundlichen Grüßen
Karim Geiger
Die Antwort der E-POST kam dann am Folgetag:
Sehr geehrter Herr Geiger,
vielen Dank für Ihre Nachricht. Sie haben Fragen zum Verschlüsselungssystem von E-POST.
Transport Layer Security (kurz TLS) bietet nach dem aktuellen Stand der Technik ein Höchstmaß an Sicherheit. Damit entspricht es den hohen technischen Anforderungen der Deutschen Post an ein Kommunikationsportal.
Renommierte Sicherheitsexperten haben die TLS-Spezifikation entwickelt. Sie gilt derzeit als Standard für sichere Kommunikation im Internet. Auch Onlinebanking-Transaktionen werden gewöhnlich mit TLS geschützt, denn es ist das einzige Verfahren, das von allen marktüblichen Web-Browsern unterstützt wird.
Sie haben gehört, dass TLS-Verbindungen mithilfe von gefälschten Zertifikaten von Dritten mitgelesen werden können? Das ist nur ein Gerücht! Es ist bis heute kein einziger konkreter Fall bekannt.
Wir freuen uns, wenn Ihnen diese Informationen weiterhelfen.
Mit freundlichen Grüßen

Ich lass das jetzt mal unkommentiert so stehen.

Update 8. Mai 2015: Ich habe noch einmal nachgefragt und erneut betont, dass man die Frage doch an einen zuständigen Mitarbeiter weiterleiten solle, was man dann auch tat. Daraufhin kam folgende Antwort zurück. Immerhin haben sie mein Anliegen verstanden… naja.

Im Bezug auf Ihre Anfrage haben wir weitergehende Informationen von unserem IT-Sicherheitsbeauftragten erhalten:
Der geschilderte Sachverhalt ist zutreffend: Das E-POST Portal ermöglicht derzeit noch Verbindungen auf Basis von RC4. Dies dient der Unterstützung von Browsern, die noch kein TLS 1.2 nutzen. Um gegen BEAST-Angriffe zu schützen haben unsere Experten die Verwendung von RC4 für TLS 1.0 und 1.1 ausgewählt. RC4 bietet gegenüber der Verwendung von Block-Ciphern im CBC-Modus (TLS 1.0 und 1.1 unterstützen keine anderen Modi) einen besseren Schutz.
Der Browser gibt beim Verbindungsaufbau die TLS-Version vor. Aktuelle Browser verwenden automatisch TLS 1.2. Ein TLS-Downgrading wird serverseitig verhindert. Somit ist sichergestellt, dass immer das höchstmögliche Sicherheitsniveau für HTTPS-Verbindungen genutzt wird.
Wir führen kontinuierliche Auswertungen über die eingesetzten Ciphersuites durch und passen unsere serverseitige Ciphersuite-Konfiguration entsprechend an. Das Nutzerverhalten im Bezug auf die eingesetzten Browser muss für die Umsetzung des RFC 7465 aber berücksichtigt werden.

HTTPS – Overhyped since 2014

Von Karim Geiger — unter Internet am 27.01.2015

Cover

Seit Google im August beschlossen hat (man achte bitte darauf, dass Blogspot kein HTTPS verwendet) HTTPS als Ranking-Kriterium mit einzuberechnen, läuft das halbe Internet amok.

Jeder noch so kleine Blog stellt plötzlich auf HTTPS um (*hust*), jeder wird zum Sicherheitsexperten und alle denken sie hätten ihre Website endlich final gegen Hacker, MITM, DDoS und was nicht noch alles gesichert, nur weil man nun ein s mehr in der URL hat. Da dementsprechend oft das Thema aufkommt und mich mittlerweile schon einige Leute gefragt haben, was ich davon halte, gibt es nun meine Antwort dazu:

Kommt mal runter. Nein, HTTPS ist nicht das Penicillin des Webs, es ist keine Wunderwaffe, die einen plötzlich immun gegen alles und jeden macht. Ganz im Gegenteil sogar. Doch ja, HTTPS hat ganz klar eine Daseinsberechtigung: Der Inhalt einer Seite kann nur zwischen den zwei Parteien gesehen werden und die Herkunft der Seite ist gesichert, was oftmals und bei vielen Websites ein absolutes Must-Have ist. Doch eben nicht immer.

Verwendet man diese Technologie also auf seiner Website, ist man zumindest theoretisch sehr gut gegen sogenannte Man-in-the-Middle-Angriffe geschützt. Es ist also nicht einfach möglich sich als Angreifer zwischen den Client und den Server zu hängen und den Inhalt der Website auszulesen oder zu verändern. Das hat enorme Vorteile, da man so gerade in öffentlichen Netzen vor Schadsoftware und Sessiondiebstahl gut geschützt ist.

Allerdings nur theoretisch. Besucht man eine Website beispielsweise das erste mal, sieht das im Browser folgendermaßen aus: Man tippt facebook.com ein und wird auf http://facebook.com weitergeleitet. Der Server gibt nun zurück, dass man doch bitte HTTPS verwenden solle und verweist auf https://facebook.com. Der Browser lädt die Seite und die sichere Verbindung wird aufgebaut. Erst ab hier kann die Verbindung normalerweise nicht mehr durch einen Angreifer in der Mitte abgeschnorchelt werden. Doch das reicht oft schon aus. Denn gibt der Angreifer an http://facebook.com zu sein – was, da dort kein HTTPS verwendet wird, ganz einfach möglich ist, so kann er wieder ganz entspannt den Datenverkehr mitschneiden und manipulieren.

Klar, es gibt Add-Ons, welche den Nutzer automatisch auf die sichere Seite weiterleiten, sofern diese existiert. Es gibt aber auch alternative und bessere Möglichkeiten um sich in öffentlichen Netzen vor entsprechenden Angriffen zu schützen, ganz ohne HTTPS. Die Rede ist von VPNs oder dem Tor-Netzwerk.

Nur am Rande: Ein weiteres Missverständnis beim Thema HTTPS ist, dass man nicht zurückverfolgen kann, wann welche Seite besucht wurde. Das ist quatsch, da der Verbindungsaufbau genau wie bei HTTP vom ISP protokolliert wird. Gegen eine eventuelle Vorratsdatenspeicherung hilft das also auch nicht.

Und was ist so schlimm daran HTTPS zu verwenden? Schließlich gibt es doch keine Nachteile.
Doch, die gibt es. Die Verbindung ist gerade bei langsamen Anbindungen wie z.B. EDGE träger, da das Austauschen des Schlüssels eine gewisse Zeit in Anspruch nimmt und die verschlüsselten Inhalte (minimal) größer sind. Auch bedeutet es für den Server sowie für den Client einen Mehraufwand, da jede Datei ver- und danach wieder entschlüsselt werden muss.

Außerdem kosten Zertifikate in der Regel Geld. Zwar bekommt man bei einigen Anbietern ein kostenloses Zertifikat für die TLD (z.B. karim-geiger.de) sowie eine Subdomain (z.B. www.karim-geiger.de), hat man nun aber mehrere Subdomains um z.B. Traffic auszulagern, weitere Dienste anzubieten oder warum auch immer, kommt man um einen Aufpreis nicht herum. Ganz abgesehen davon verlangen einige Webspaces einen Aufpreis für die Konfiguration, welche nebenbei bemerkt gerade bei komplexeren Strukturen mit Proxys und co. einen erheblichen Mehraufwand bedeutet.

Auch gibt es technische Einschränkungen, welche natürlich durchaus Sinn machen, für Blogs* oder ähnliche Websites aber sehr nervig sind: Werden Nicht-HTTPS-Inhalte auf einer verschlüsselten Seite eingebunden, so werden sie ignoriert. Das hat zur Folge, dass viele Blogs, welche Bilder/Videos/CSS/JavaScript von Dritten einbinden, nicht mehr ordnungsgemäß funktionieren.

Wann macht HTTPS also Sinn?
HTTPS macht immer dann Sinn, wenn kritische Nutzerdaten übertragen werden, darunter Benutzernamen, Passwörter, E-Mail-Adressen, etc. Da viele Websites dies allerdings so gut wie nie anbieten (Blogs*, Portfolios, Imageboards, …), ist es in meinen Augen nur bedingt sinnvoll. Die Entscheidung Googles ist daher in meinen Augen nicht ganz nachvollziehbar, da man so den Nutzer in Sicherheit wägt, es aber keinesfalls vor schlechter Programmierung schützt.

 

* Ich seh’s schon kommen, daher hier die Erklärung: Ja, Blogs haben ein Management-Backend, bei dem man sich einloggen muss und ja, Blogs bieten oft an Kommentare zu hinterlassen. Man kann also durchaus das Backend per HTTPS absichern. Deswegen aber den gesamten Blog mit HTTPS zu versehen, halte ich für oversized. Bezüglich der Kommentare halte ich es meistens nicht für sinnvoll. Nur die wenigsten bieten eigene Nutzeraccounts an, die meisten verwenden – wie ich – Tools von dritten, da sich niemand wegen einem Kommentar einen Account erstellt. Die Kommentarsysteme selbst sollten dann allerdings für eine sichere Übertragung sorgen.

Bildquelle